executing-plans

Overview

Load the plan, run strict initial validations, execute tasks in logical batches, report for review between batches, and use soft circuit breakers to prevent environment damage or infinite loops.

Core principle: Defensive batch execution with logical checkpoints for architect review.

Announce at start: "I'm using the executing-plans skill to implement this plan."

The Process

Step 1: Strict Plan Validation & Initialization

1. Read the plan file.
2. Review critically (Validation Checklist):
   • Are all required dependencies available in the current environment?
   • Are data structures and edge cases clearly defined?
   • Are environment variables specified if needed?
3. If ANY check fails or if you have concerns: Raise them with your human partner IMMEDIATELY before starting.
4. If no concerns: Create or update an .agent_state.md file in the root directory to track progress persistently.

Step 2: Logical Batch Execution

Default Rule: A batch is defined as reaching a stable repository state (e.g., completing a task that ends in a successful test and a commit).

For each task in the batch:

1. Update .agent_state.md to mark the task as IN PROGRESS.
2. Follow each step exactly as defined in the plan.
3. Defensive Execution: Run verifications as specified. Assume the terminal can hang: If any command (like a test or script) takes more than 60 seconds without output, treat it as a timeout failure.
4. Mark as completed in .agent_state.md once the commit is done.

Step 3: Checkpoint Report

When the logical batch is complete:

• Show what was implemented.
• Show the verification output.
• Say: "Ready for feedback or approval to continue."

Step 4: The "Soft Circuit Breaker" (When tests fail)

If a test fails, you must read the stderr/traceback. Extract the last 15-20 lines to understand the issue. Try to fix the implementation.

THE 3-STRIKE RULE: If you fail to make the test pass after 3 consecutive attempts:

1. STOP EXECUTING IMMEDIATELY.
2. DO NOT run git reset --hard or delete the work.
3. Output a structured failure report containing:
   • The exact traceback error.
   • Your hypothesis of why it is failing (e.g., dependency mismatch, logic error, typing issue).
4. Prompt the human partner: "Circuit breaker triggered. I've hit a blocker. Let's do a quick mini-brainstorm to rethink this approach before continuing."

Step 5: Complete Development

After all tasks complete and verified:

• Announce: "I'm using the finishing-a-development-branch skill to complete this work."
• REQUIRED SUB-SKILL: Use superpowers:finishing-a-development-branch
• Follow that skill to verify tests, present options, execute choice

When to Revisit Earlier Steps

Return to Review (Step 1) when:

• Partner updates the plan based on your feedback
• Fundamental approach needs rethinking

Don't force through blockers - stop, trigger the circuit breaker, and ask.

Remember

• Review plan critically first against the validation checklist.
• Follow plan steps exactly and use semantic targeting.
• Don't skip verifications and respect the 60-second timeout.
• Reference skills when plan says to.
• Between batches: just report and wait.
• Stop when blocked, don't guess.
• Never start implementation on main/master branch without explicit user consent.

Integration

Required workflow skills:

• superpowers:using-git-worktrees - REQUIRED: Set up isolated workspace before starting
• superpowers:writing-plans - Creates the plan this skill executes
• superpowers:finishing-a-development-branch - Complete development after all tasks