Auto

Auto

Auto is the front door when the user wants the repository to keep choosing and executing the next safe owner without repeated prompting.

Core Take

Auto is a supervisor, not a larger implementation skill. It compiles the run, records durable state, selects the next checkpoint from evidence, invokes the real owner, verifies the result, and continues until the auditable stop condition is true.

Before the first file mutation, capture a walkthrough diff baseline when UI or rendered output may change. Use .agents/skills/walkthrough/scripts/diff-baseline.mjs and record its path.

The loop is:

request -> run profile -> vision/source intake -> readiness
-> candidate owner -> execute -> proof -> state update -> next candidate
-> review -> repository gate -> GitHub delivery -> final audit

Do not score the entire run up front. Score only when more than one valid next checkpoint exists.

Modes

A bare feature plus full may use an existing local PRD when useful. If no PRD is required to make coherent decisions, Auto writes the decisions and packets in its goal plan instead of creating planning ceremony.

Front-Door Routing

Use orchestrator only when the user explicitly requests parallel child thread/branch work. Auto never invents parallel delegation or worktrees.

Run Profile Compiler

Before work, compile and record this profile in the goal plan:

Reject impossible combinations instead of silently weakening one. full cannot become planning-only because a PRD was created. clean cannot expand into a new feature. A timed run cannot spend its closeout reserve on new scope.

Goal Plan Contract

Use autogoal before durable Auto work. Create or resume a plan from the auto template with the agent-native pack and any relevant browser, design, docs, package-api, release, or to-prd pack.

The plan must contain:

• run profile and source inventory;
• completion threshold and explicit exclusions;
• state capsule;
• decision, assumption, claim, error-attempt, and packet ledgers;
• readiness and proof matrices;
• source/generated owner map;
• review, repository-check, and delivery gates;
• phase states and completion audit.

Checkpoints are receipts. Update the plan after meaningful execution, not only at the end.

Before full closeout, run both plan validators:

node .agents/rules/auto/scripts/check-plan-placeholders.mjs <plan-path>
node .agents/skills/autogoal/scripts/check-complete.mjs <plan-path>

The placeholder audit fails unresolved TODO/TBD text, bare pending cells, and unchecked items. The autogoal checker proves the resolved goal-plan structure.

State Capsule

Keep this compact capsule current so work can resume without rereading the world:

mode:
target:
active source:
active packet:
current owner:
last proven fact:
latest changed files:
next proof:
open blocker:
decision debt:
time remaining / reserve:

Update after source changes, failed proof, owner changes, and packet closeout. Never claim a state that is only planned.

Source Intake

Read only what can change the next decision:

1. VISION.md, docs/README.md, and the named local source.
2. The active plan/PRD/milestone and unresolved decisions.
3. Exact public exports, runtime entries, package manifests, and call sites.
4. Tests/fixtures/scenarios that define the current behavior.
5. CLI/template/generated owners when scaffold output is involved.
6. Matching docs and packages/kitcn/skills/kitcn/** when user guidance moves.
7. Local OSS clones for unfamiliar or parity-sensitive API design.

Build a source-backed case matrix rather than reading broad directories without a question.

Full Mode Contract

auto full is terminal only when every applicable lane is proven:

1. Resolve the named source or the latest relevant unfinished local PRD.
2. Repair bounded contradictions, placeholders, missing owner decisions, and weak proof contracts in that source.
3. If the source is fundamentally missing, route once to to-prd; then return to the same full run.
4. Decompose directly into local task packets in the PRD or active Auto plan.
5. Execute each packet with task, major-task, architecture-cleanup, hard-cut, design, or tdd as its true owner.
6. Run package build, changeset, fixture, scenario, docs/package-skill, browser, and generated-output gates required by the changed surface.
7. Run final cleanup and reviews.
8. Run bun lint:fix and bun check.
9. Commit, push, and open/update the GitHub PR when the run includes verified code-changing delivery.
10. Audit the complete goal plan and close the durable goal.

Local PRDs and task packets own decomposition; the GitHub PR owns delivery and review.

Task Packet Ledger

Every implementation packet gets one row:

Mode is one of:

• blocking: must close before dependent packets;
• parallel-join: may overlap only when explicit parallel work is authorized, but joins before its claim is consumed;
• detached: useful but cannot change the requested completion claim.

Consolidate test-only, docs-only, guard-only, and refactor-only fragments into the behavior packet they support unless ownership and acceptance are truly independent.

Claim Receipts

Any important final claim must have a receipt:

Allowed evidence includes source lines, test output, generated diffs, runtime observations, Browser proof, benchmark results, package exports, build artifacts, and authoritative external docs. A plan checkbox or command exit code without relevant assertions is not enough.

For evidence-backed claims:

• high: direct fresh evidence covers the exact claim and boundary;
• medium: direct evidence plus a bounded inference;
• low: unverified inference, stale evidence, or incomplete boundary.

Completion claims require high confidence. Rewrite, narrow, or keep working when confidence is lower.

Hard Confidence Thresholds

These block progress regardless of candidate score:

Decision Debt Cap

Decision debt is an unresolved choice that can change public behavior, owner boundaries, security, data lifecycle, or proof. Keep at most three active items and none on the critical path to the active packet.

If the cap is exceeded, stop implementation and resolve the highest-impact decision. Cosmetic preferences do not count.

Assumption Ledger

Validate high-impact assumptions before code. Low-impact reversible assumptions may proceed if they are explicit and tested before closeout.

Readiness Ownership

One owner signs each readiness lane:

Do not let multiple scorecards create fake rigor. Use readiness ownership to answer who must act next.