autoimplement

Auto-advance through a multi-phase implementation plan by chaining existing review skills at phase boundaries. Removes the y/n friction the user would always answer "yes" to anyway.

When to use

Invoke when the user asks:

• "autoimplement <plan-file>"
• "run this plan end-to-end"
• "auto-advance through the phases"

Plan path resolution

Before anything else, resolve which plan file to run on. Order of attempts:

1. Absolute path the user gave → use as-is.
2. Relative path that exists from CWD → use.
3. Filename only → look in docs/superpowers/plans/<filename>.
4. If none resolve → list available plans in docs/superpowers/plans/ and ask which.

Read the resolved file in full. From this point on, "the plan" refers to this file.

Startup checks (enforced by the shipped skill, not just documented)

Before invoking AskUserQuestion, before dispatching any subagent, run these checks in order. Each is a hard refusal — exit with the named reason and do not proceed.

Check 1: Workspace is on a feature branch with a clean tree

git_branch=$(git rev-parse --abbrev-ref HEAD 2>/dev/null || echo "")
git_status=$(git status --porcelain 2>/dev/null || echo "GIT_FAIL")

(Variable names are deliberately prefixed git_ — bare status is read-only in zsh, the default shell on macOS, which would break this snippet when the agent runs it via Bash. The git_ prefix avoids the collision and is self-documenting.)

Refuse if:

• git_branch is empty, main, master, or GIT_FAIL → "autoimplement runs only on a feature branch in a git repo. You are on '<branch>'. Create a feature branch first; suggested name: feat/<plan-slug>."
• git_status is non-empty → "working tree has uncommitted changes — autoimplement requires a clean tree (so phase commits are unambiguous). Commit or stash, then re-invoke."

Check 2: Phase count is at least 2

Apply the phase regex to the plan: ^## Phase \d+: (case-sensitive, line-anchored).

phase_count = number of regex matches

Refuse if phase_count < 2:

• 0 phases → "Plan has no ## Phase N: headers — re-author with superpowers:writing-plans first."
• 1 phase → "Plan has only 1 phase — autoimplement's value is at phase boundaries. Use superpowers:subagent-driven-development directly instead."

Check 3: Every phase has at least one commit step

For each phase body, scan for at least one occurrence of git commit (case-insensitive, across all code fences inside the phase). Refuse if any phase lacks a commit step:

"Phase <N> ('<title>') has no git commit step. autoimplement's clean-tree check between phases requires per-phase commit discipline. Either add commit steps to the plan, or use superpowers:subagent-driven-development (which prompts you per task and tolerates uncommitted phase boundaries)."

This catches the common failure mode where a plan describes work but never tells the subagent to commit it — autoimplement would then trigger the dirty-tree refusal at Step A of Phase 2 and stop pointlessly.

Assumption: This check looks for literal git commit (case-insensitive). Plans that delegate commits to a wrapper script (e.g., ./scripts/commit-phase.sh) or to another skill (e.g., /ship) will false-negative. This is acceptable given that superpowers:writing-plans produces literal git commit steps by convention. If your plan uses wrappers, either inline the commits or expect this refusal.

Check 4: No forbidden file paths or write targets

Two scans, both case-insensitive:

Scan A — Files: block paths. For each phase body, find blocks formatted as **Files:** followed by bullet lines like - Create: <path> / - Modify: <path> / - Test: <path>. Extract every <path>. Refuse if any path matches any of these regexes (anchored, not substring):

• (^|/)migrations(/|$) — migration directories
• (^|/)\.env(\..*)?$ — .env and .env.* files
• (^|[/._-])secrets?([/._-]|$) — paths containing "secret" or "secrets" as a word (e.g. app/secrets/, prod.secret.yaml); avoids matching secretary/
• (^|[/._-])credentials?([/._-]|$) — paths containing "credential" or "credentials" as a word; avoids matching credentialed-users.md
• (^|/)\.ssh/ — SSH directories

Scan B — shell command writes against forbidden paths. For each phase body, scan code fences for write-like commands targeting any forbidden path. The forbidden path regexes from Scan A apply here too — match them against the ARGUMENTS of these commands:

Write-like command patterns:

• Shell redirection: >\s*<path>, >>\s*<path>, 2>\s*<path>, &>\s*<path>
• File commands: tee\s+(-[a-z]+\s+)*<path>, cat\s+>\s*<path>, cp\s+\S+\s+<path>, mv\s+\S+\s+<path>, install\s+\S+\s+<path>
• Touch/mkdir: touch\s+<path>, mkdir\s+(-p\s+)?<path>
• Editors: vim?\s+<path>, nano\s+<path>, code\s+<path>
• Git: git\s+add\s+<path>
• Heredoc: cat\s+(>|>>|<<)\s*<path> and <<-?\s*['"]?EOF['"]? followed by writes
• Secret-shape assignments: (^|\s)(secrets?|passwords?|tokens?|api_?keys?)\s*= in export/echo/printf lines

If any write-like command targets any forbidden path (migrations / .env / secret / credential / .ssh — using the regexes from Scan A), refuse with the offending command quoted:

"Plan touches forbidden path or writes secret-shaped content: <offending match> in Phase <N>. autoimplement refuses on migrations / secrets / credentials / .env / .ssh — these need human-in-the-loop friction. Run the plan manually."

Implementation note: This scan is intentionally over-eager. False positives are acceptable; a missed forbidden write is not. If a legitimate plan trips the scan, the user can rename the file or run the plan manually.

Fallback when Files: blocks are absent in some phases: Still run Scan B on all phases. Surface a note when Scan A finds nothing because no Files: blocks exist: "Note: phase(s) <list> have no Files: blocks — only shell-command scan ran for those. Verify by hand that they don't write to forbidden paths."

Check 5: Codex CLI availability (informational, not blocking)

codex --version 2>/dev/null

If absent → set internal flag CODEX_AVAILABLE=false. Continue, but the /codex review step in the per-phase procedure will be skipped (with a logged note in the final summary).

Check 6: Plan review chain (pre-flight, active)

Autoimplement trusts the plan implicitly — it runs phases without human approval at boundaries. So the plan MUST be reviewed before automated execution starts. v2.14.0 makes this an active pre-flight chain instead of a passive history check (the previous v2.13.x behavior).

Step 6a: Skip condition — LATEST commit touching plan path is a pre-flight marker

Check the latest commit that touched the plan path (not historical anywhere — that's too lenient and would skip pre-flight even after the plan was edited post-review):

last_plan_commit_subject=$(git log -1 --format=%s -- "$plan_path" 2>/dev/null || echo "")

If the subject matches the marker regex ^(chore|fix)\(plan\):[[:space:]]*pre-flight([[:space:]]|$) (case-insensitive, anchored at line start, requires the conventional-commit prefix, requires a word boundary after pre-flight) → the plan's most recent touch was a pre-flight marker commit produced by this skill (Step 6b.4); trust it and skip:

if echo "$last_plan_commit_subject" | grep -qiE '^(chore|fix)\(plan\):[[:space:]]*pre-flight([[:space:]]|$)'; then
    skip_preflight=true
fi

(POSIX character class [[:space:]] chosen over GNU-extension \s for portability across BSD/macOS grep. The trailing ([[:space:]]|$) is a word boundary preventing matches like pre-flighting or pre-flightchecklist — caught by codex review v2.14.2 round 3.)

Plan's latest commit is a pre-flight marker ("$last_plan_commit_subject"). Skipping pre-flight chain — proceeding to policy question.

Otherwise → run the pre-flight chain below.

**Why