implementaudit

IMPLEMENTAUDIT.md

IMPLEMENTAUDIT.md names this repo and workflow: audited implementation driven by an AUDIT.md-style evidence/input artifact. The .md in the repo name is branding and lineage, not a required root behavior file.

skills/implementaudit/SKILL.md defines /implementaudit: a repo-generic method for turning audit findings, handoffs, checklists, reviews, goals, tasks, gaps, and implementation plans into bounded, verified repository changes. It plans deeply and executes repo work phase-by-phase until terminal audit closure or an explicit audited handoff.

It is for audit closure and repo hygiene: read the real repo, find the owner/source, make the smallest warranted change, prove only what the evidence supports, and close the ledger. Blocked work ends in an explicit audited handoff, not fake completion. It is not a release bot, package publisher, provenance system, or generic autonomous-build loop.

It does not assume a framework, language, CI system, release convention, package host, or optional toolchain. Its default authorization stance is:

No commit. No push. No tag. No release. No publication. No provenance.

Each action requires separate explicit authorization.

Contents

• Quick start
• Runtime at a glance
• What it is
• Quick vocabulary, not authority
• How an audit input drives a run
• How IMPLEMENTAUDIT audits
• Invocation modes
• Native planner stages
• Default behavior
• Greenfield / brownfield routing
• Operating method
• Execution gates
• Loopability, Andon, and handoff states
• Artifacts and outputs
• Skill internals / repository layout
• Version and release notes
• Child-agent review loops
• Optional tooling
• Evidence boundaries
• Usage examples
• Install notes
• Upgrade / reinstall
• Release asset notes
• Validation and release evidence
• Safety defaults
• What this does not do
• Development / maintenance notes

Quick start

1. Install the skill (see Install notes for your host). This source checkout documents the v0.3.1.0 local contract. The current release-gate verified live public release is v0.3.0.0; source changes after that release are not a release by themselves.
2. In a repo you want governed, invoke it with a bounded target: /implementaudit close the findings in AUDIT.md — or just describe the work; unbounded asks get a STOP, not a build loop.
3. What you will see: a findings ledger, Smoke A baseline evidence, bounded patches, Smoke B comparison, and transcript markers ending in AUDIT_COMPLETE + IMPLEMENTAUDIT_RUN_COMPLETE — or an explicit audited handoff with next actions. Phased runs write their plan and state under .IMPLEMENTAUDIT/runs/<task>-<id>/. The full loop structure is in Loopability, Andon, and handoff states; the shipped helper scripts are catalogued in the docs portal's Package contents / shipped scripts reference.
4. Nothing is committed, pushed, tagged, or released unless you explicitly say so.

Runtime at a glance

Input artifact -> live repo inspection -> owner/source patch -> Smoke A/B -> trace -> final audit

The small loop closes one supplied audit/handoff/checklist/review/plan. The larger package loop can synthesize a bounded /goal handoff when the user gives only an idea, gap, or incomplete target.

What it is

/implementaudit is the officer/method layer for audit closure and repo hygiene. It is an audit-governed implementation skill: it plans deeply and executes repo work phase-by-phase until terminal audit closure or an explicit audited handoff. It makes repo changes that are auditable, bounded, owner/source-grounded, reversible, and not overclaimed — routing all work through owner/source discovery, acceptance criteria, rollback/evidence planning, fixtures/checkers, and smoke-before-claim closure. Blocked work ends in an explicit audited handoff, not fake completion. It is not a generic autonomous build runner, release bot, package publisher, or provenance system.