Auto-Proceed-Plan Workflow

Systematic, autonomous plan execution workflow modeled on auto-fix. Ingests the active conversation's implementation plan, freezes it into a dedicated immutable plan artifact (auto_proceed_plan.md), verifies the pre-flight baseline, executes phase-by-phase applying ponytail minimal diffs, performs lightweight post-execution verification, conducts a plan compliance audit, and atomically commits & pushes via git-commit-push.

---

0. Invocation Guard

Check the initiating user prompt:

• If this turn was NOT explicitly initiated by /auto-proceed-plan (e.g. /auto-proceed-plan), ABORT this workflow immediately and proceed with normal conversational or coding behavior without applying auto-proceed-plan constraints.
• Do NOT auto-trigger for general planning, coding, or when words like "proceed", "plan", or "execute" appear in casual conversation.
• Do NOT persist across subsequent turns unless the user explicitly invokes /auto-proceed-plan again.

---

Core Invariant: Run Necessary Tests Only

Across ALL testing and verification stages:

• Never run full-workspace or monolithic test suites. Blind execution of entire project test suites wastes time and catches unrelated flakiness.
• Target only the specific file or pattern: Execute only the isolated reproduction test or affected module tests (e.g. npm test -- path/to/target.test.mjs, pytest tests/test_module.py::test_case, go test ./pkg/... -run TestName).

---

Stage 1: Resolve Active Conversation Plan Artifact

1. Locate Plan Artifact:
   • Inspect the active <Artifact Directory> for the current conversation's implementation plan artifact (e.g. *plan*.md).
   • The workflow strictly targets the active conversation plan generated by /plan.
2. Missing Plan Guard:
   • If no plan artifact exists in <Artifact Directory>, HALT immediately and inform the user:

     ❌ No active conversation plan artifact found in `<Artifact Directory>`.
     Please formulate an implementation plan first using `/plan`.
     

3. Context & Scope Inspection:
   • Read the plan artifact using read_file.
   • Inspect all target files and functions referenced in the plan to verify current workspace state.

---

Stage 2: Plan Freeze & Dedicated Artifact Creation

Before touching any codebase files:

1. CREATE DEDICATED FROZEN PLAN ARTIFACT (MANDATORY):
   • Snapshot the active conversation plan into a new, dedicated artifact file at <Artifact Directory>/auto_proceed_plan.md using write_file with ArtifactMetadata:
     • Summary: "Frozen implementation plan for auto-proceed-plan"
     • UserFacing: true
     • RequestFeedback: false
   • Prepend the lock banner to the snapshot:

     > [!IMPORTANT]
     > ### 🔒 PLAN FROZEN & IMMUTABLE
     > Auto-proceed execution active. Stages 3 through 7 must strictly execute against this frozen plan specification.
     

   • Preserve the original conversation plan artifact intact.
2. Visible Chat Notification:
   • Emit a clickable link to the frozen plan artifact in chat:

     ### 📋 Stage 2: Frozen Implementation Plan (🔒 LOCKED)
     👉 [auto_proceed_plan.md](file:///<absolute-path-to-artifact>)
     - **Status**: 🔒 Frozen & Locked in dedicated artifact.
     - **Execution Mode**: Autonomous auto-proceed (Stages 3–7).
     

3. PLAN FREEZE: Once written to the artifact, this plan is strictly locked and immutable. Stages 3 through 7 must execute strictly against this artifact.

---

Stage 3: Pre-Flight Baseline Verification

1. Before modifying any code, execute the targeted baseline test or build command identified in the plan:

   # Run only the necessary baseline verification command
   <baseline-test-or-build-command>
   

2. Verify that existing tests pass (or confirm known baseline state).
3. If pre-flight baseline fails unexpectedly on unrelated code:
   • Alert the user before proceeding to avoid diagnosing pre-existing breakage as new regressions.

---

Stage 4: Autonomous Plan Execution (Applying ponytail)

Immediately auto-proceed through all planned phases without conversational pauses between steps, adhering to ponytail principles:

1. The Ponytail Ladder:
   • Reuse existing codebase helpers > Standard Library > Native platform features > Minimum lines.
   • Zero boilerplate, zero unrequested abstractions, zero speculative generality.
   • Shortest working diff wins.
2. Apply surgical modifications to target files using edit_file or write_file.
3. Run the targeted verification command after each phase (running only necessary tests).
4. Auto-proceed continuously from phase to phase.

Controlled Plan Invalidation & Revision Protocol

If a planned phase fails verification or hits an unexpected technical roadblock:

• Zero Silent Deviation: Never quietly edit unrelated files or expand scope without logging.
• Case A: Minor Tactical Amendment (e.g. missing import, null guard, or type adjustment):
  1. Append an amendment entry to <Artifact Directory>/auto_proceed_plan.md:

     ### 📝 Amendment #1: <brief description>
     - **Reason**: <why adjustment was necessary to pass test>
     - **Adjusted Diff**: <new minimal replacement snippet>
     

  2. Note in chat: > ℹ️ Plan Amendment #1: [brief reason]
  3. Apply amendment and re-verify.
• Case B: Major Strategic Invalidation (approach is fundamentally unviable):
  1. Halt immediately. Do not touch further files.
  2. Explain the fundamental roadblock clearly.
  3. Call ask_question with options:
     • Pivot to Alternative Strategy (describe approach)
     • Abort plan execution
  4. If user approves pivot, update <Artifact Directory>/auto_proceed_plan.md with the amended approach and resume Stage 4. If user aborts, preserve state and halt.

---

Stage 5: Lightweight Post-Execution Verification

Execute two independent verification checks:

1. Acceptance Verification

Run the plan's designated verification commands and confirm all targeted test cases or build checks pass cleanly (running only necessary tests).

2. Ponytail Simplicity / YAGNI Audit

Evaluate the final diff against Ponytail rules:

• Were any unnecessary abstractions, helper wrappers, or unused parameters added?
• Could the implementation be safely expressed in fewer lines?
• Confirm zero over-engineering.

---

Stage 6: Consolidated Status Report & Plan Compliance Audit

Present a clear, structured report to the user:

1. Executive Summary: What was executed and verified.
2. Verification Proof: Targeted test output confirming clean pass.
3. Simplicity Rating: Confirmation of minimal diff and zero over-engineering.
4. Plan vs. Reality Audit:
   • Compare the final code changes delivered against the frozen artifact: auto_proceed_plan.md and logged amendments.
   • Include a plan compliance checklist:
     • Target files matched artifact plan? (Yes / No)
     • Diff scope matched artifact plan + logged amendments without extra modifications? (Yes / No)
     • Any amendments logged and justified? (Yes / None needed / Unlogged divergence)
     • Verification test commands matched artifact plan? (Yes / No)
   • Explicitly certify whether the implementation complied 100% with the frozen plan, or detail any deviations made and the reasons why.

---

Stage 7: Automated Git Commit & Push (Applying git-commit-push)

Upon completing the Stage 6 report, automatically commit and push the verified changes following the git-commit-push skill protocol:

1. Git Worktree Verification:

   • Check if inside a git worktree (git rev-parse --is-inside-work-tree). If not a git repository, skip this stage cleanly.

2. Pre-Flight Fast Leak & Size Scan:

   • Ensure no secrets or sensitive files (.env*, *.key, *.pem, token.txt, credentials.json) are untracked or modified.
   • Ensure no large files (> 5MB) were added.

3. Surgical Staging:

   • Stage ONLY the files modified by the plan, tests, and documentation:

     git add <modified_files> <test_files>
     

   • Do NOT run blind git add . to avoid staging unrelated workspace changes.

4. Conventional Commit Message:

   • Synthesize a Conventional Commit message from the implemented plan:

     feat(<scope>): <imperative summary under 72 chars>
     
     - Scope: <concise summary of changes>
     - Verification: targeted acceptance checks and ponytail simplicity audit passed
     

5. Atomic Commit & Push:

   • Execute commit and push in one compound command with upstream fallback:
     • PowerShell:

       git commit -m "<message>"; if ($LASTEXITCODE -eq 0) { git push; if ($LASTEXITCODE -ne 0) { git push -u origin (git rev-parse --abbrev-ref HEAD) } }
       

     • Bash / POSIX:

       git commit -m "<message>" && (git push || git push -u origin $(git rev-parse --abbrev-ref HEAD))
       

6. Summary Output:

   • Output the concise 3-line commit summary:
     • Commit: <hash> — <message title>
     • Branch: <branch> (pushed to remote)
     • Files: List of committed files