auto-phase

Auto-Phase: Autonomous Multi-Stage Execution

Reads a phase plan and executes stages autonomously. Each stage gets focused evidence. One owner validates the integrated source fingerprint.

Requires the ship and session-critique skills (plus validate, which ship also depends on). If they are not installed, stop and say so rather than improvising the gates.

When to Use

• You have a PHASE-PLAN.md (or similar) with numbered stages 1-N
• Each stage is self-contained and can be validated independently
• You want autonomous execution with human oversight only on failures

When NOT to Use

• Single-stage work -> use /ship
• No written phase plan exists -> write one first (use brainstorming + writing-plans)
• Exploratory or uncertain work -> plan first, then auto-phase

Prerequisites

1. A phase plan file exists (default: PHASE-PLAN.md in project root)
2. Each stage in the plan specifies: what to implement, expected output, done criteria
3. The project has /validate and /session-critique available

Procedure

Step 1: Read and parse the phase plan

PLAN_FILE="${ARGUMENTS:-PHASE-PLAN.md}"
[ -f "$PLAN_FILE" ] && echo "Plan found: $PLAN_FILE" || echo "ERROR: $PLAN_FILE not found"

Parse the plan to identify:

• Total number of stages
• Each stage's scope, files, and done criteria
• Dependencies between stages (if any)

Present the parsed stage list to the user for confirmation before starting.

Step 2: Execute stages autonomously

For each stage (1 through N):

2a. Announce stage start

=== STAGE K/N: [Stage Title] ===
Status: STARTING

2b. Implement the stage's changes

Follow the stage's instructions from the plan. Make the code changes, create files, modify configurations, whatever the stage specifies.

2c. Run focused stage checks

Run only the checks that cover this stage's changed behavior. Record the exact command, exit code, and summary in TASKS.md. Do not run the full project gate here unless this is the final integrated stage.

If a focused check fails:

• First failure: Fix the issue and re-run the focused check.
• Second failure on same stage: HALT. Report the failure and ask the user.

=== STAGE K/N: VALIDATION FAILED (attempt 2/2) ===
Failure: [description]
Action: Halting for user input. The stage contract may need revision.

2d. Record review risk

Record whether the stage affects security, a trust boundary, architecture, or several subsystems. Do not run a per-stage generic critique when the final aggregate reviewer will inspect the same work.

2e. Commit with clean scope

Commit inline with git. The commit must contain ONLY this stage's changes. Never bundle changes from other stages.

git status --short
git add <this stage's paths>
git commit -m "<type>: <stage K subject>"
git rev-parse --short HEAD

Before commit, use /validate for the exact stage fingerprint when the repository requires a validated receipt for every commit. Reuse a valid receipt. If the content changed, run validation before the commit rather than probing with a failed commit attempt.

2f. Update progress tracking

After successful commit, update TASKS.md (create if it doesn't exist):

## Auto-Phase Progress

| Stage | Status | Commit | Notes |
|-------|--------|--------|-------|
| 1 | DONE | abc1234 | [summary] |
| 2 | DONE | def5678 | [summary] |
| 3 | IN PROGRESS | - | - |

2g. Advance to next stage

=== STAGE K/N: COMPLETE ===
Commit: [hash]
Advancing to Stage K+1...

Step 3: Integrated validation and review

The validation owner invokes /validate once for the final integrated fingerprint. Reuse an existing receipt only when validation.py check accepts it.

If any stage recorded review risk, invoke /session-critique once over the fixed aggregate diff. Reuse a durable review for the same fingerprint. A fix lands as its own follow-up commit. Repeat review only after material behavior changes or for a named unresolved risk.

Step 4: Completion report

After all stages complete:

=== AUTO-PHASE COMPLETE ===
Plan: [plan file]
Stages: N/N completed
Commits: [list of hashes]
Total changes: [file count summary]

All stages passed validation; the end-of-plan critique ran.

Stopping Conditions

Condition	Action
Validation fails twice on same stage	HALT, ask user, stage contract likely needs revision
Critique finds unresolvable issue	HALT, present issue and ask user
Plan file not found	HALT, report error immediately
Stage instructions are ambiguous	HALT, ask user to clarify before implementing
All stages complete	Report summary, pipeline done

Hard Rules

1. One stage at a time. Never start stage K+1 before stage K is committed.
2. Never bundle cross-stage changes. Each commit contains exactly one stage.
3. Never skip focused checks or integrated validation. Keep one independent final review when the aggregate change meets the risk conditions in Step 3.
4. Halt on ambiguity. If a stage's instructions are unclear, ask, don't guess.
5. Track progress. Update TASKS.md after every stage so a fresh session can resume.