| name | auto-plan |
| description | Create a structured, verification-ready implementation plan without executing it. Use when the user asks for /autoplan, auto-plan, a development roadmap, or a plan with bounded slices, mechanical acceptance criteria, security boundaries, rollback, risk-tiered QA, and regression controls. |
Auto Plan
Create a plan artifact only. Do not implement, deploy, spend, change accounts, or perform irreversible work unless the user separately asks to execute.
Artifact
Write the plan to a .md file under ~/.auto-master/artifacts/<project>/, using a source-labeled subfolder when useful. Write into a repo plan folder only when the user explicitly requests a repo-owned plan. Name artifacts by product, topic, and date; never by model/provider.
Planning Loop
- Capture objective, scope, constraints, roadmap context, source evidence, assumptions, blockers, and authority boundaries.
- Split execution into the smallest useful ordered slices. Classify each as Micro, Small, or Full using
auto-manage's verification kernel; escalate uncertain slices.
- For every slice define owned surfaces, explicit do-not-touch boundaries, dependencies, rollback/stop gate, and mechanically checkable acceptance criteria.
- For behavior-changing code, plan a test or reproducible check that is expected to fail before implementation (RED) and pass afterward (GREEN). For docs/copy/non-behavioral config, plan a deterministic before/after check without manufacturing RED.
- Separate subjective judgment (visual quality, tone, taste, product fit) from mechanical acceptance. Give it a named human/model judgment gate; never make it a hard mechanical verifier criterion.
- Define a
BASELINE_BLOCK, required EXECUTION_RECEIPT fields, and the final REGRESSION_DELTA for each slice.
- Cover security across trust boundaries, auth/authz, secrets, privacy, abuse/rate limits, data/migrations, deployment, observability, rollback, and launch gates where relevant.
- Self-review once, score 1-10, and repair concrete gaps. Allow at most two self-review repair passes.
- Trigger one fresh-context independent review only for Full-tier security/auth/privacy, data/migration, execution/sandbox, shared-contract, release, broad-refactor, or similarly high-blast-radius plans. Skip it for Micro work and ordinary Small work; record the reason and residual risk.
- Evaluate review findings against evidence, repair valid gaps once, and finalize the readiness call.
Verification Contract
Each acceptance criterion must specify a file/state/observable outcome or a command with an expected exit/result. Examples: file exists, schema contains a field, request returns a status, N elements render, command exits 0. Put subjective criteria in a separate judgment table.
Each planned receipt must capture exact command or manual flow, timestamp, exit/pass/fail/blocked result, concise relevant evidence, and material environment/profile. Each regression delta compares baseline failures or metrics with the final state and names every new failure.
Review Economy
- Do not spawn reviewers during self-review.
- Reuse a reviewer only when repo and objective match; otherwise use at most one fresh-context reviewer at a qualifying risk boundary.
- Batch the contract, sanitized evidence, and questions. Never send secrets or unrelated private context.
- If independent review is unavailable or intentionally skipped, state why; do not imply it occurred.
Required Sections
- Objective, authority, assumptions, and evidence
- Ordered slices with tier, ownership, dependencies, and do-not-touch boundaries
- Mechanical acceptance criteria and separate judgment gates
- Baseline, RED/GREEN or deterministic proof, receipt, and regression-delta plan
- Security, rollback, and launch gates
- Circuit-breaker and checkpoint strategy
- Initial self-score and repairs
- Independent review status, score/findings when used, accepted changes
- Rejected/deferred feedback and blockers
- Readiness decision
