Algorithmic decision tree for when to follow plan exactly vs when to report STOPPED - prevents scope creep and unauthorized deviations
/plugin marketplace add tobyhede/turboshovel/plugin install tobyhede-turboshovel-plugin@tobyhede/turboshovelThis skill inherits all available tools. When active, it can use any tool Claude has access to.
This skill is embedded in agent prompts during plan execution. It provides an algorithmic decision tree for determining when to follow the plan exactly vs when to report STOPPED.
Purpose: Prevent agents from rationalizing "simpler approaches" that were already considered and rejected during design.
This skill is embedded in agent prompts during plan execution. It applies when:
This skill prevents:
Is change syntax/naming only?
├─ YES → Fix it, note in completion, STATUS: OK
└─ NO → Does it change approach/architecture?
├─ YES → Report STATUS: STOPPED with reason
└─ NO → Follow plan exactly, STATUS: OK
Allowed without STOPPED:
Requires STOPPED:
When evaluating changes from plan:
| Domain | Within Boundaries (tsv pass) | Exceeds Boundaries (tsv fail) |
|---|---|---|
| Logic | syntax/naming | algorithm changes |
| Deps | calls within lib | swap library |
| Scope | edge cases | add/skip features |
| Interface | private | public APIs/schemas |
Follow this exactly. No interpretation.
Is the change you want to make limited to:
- Correcting function/variable names
- Fixing syntax errors
- Updating import paths
- Correcting typos in code
YES → Make the change
Add note to task completion: "Fixed syntax: {what you fixed}"
Continue to Step 4
NO → Continue to Step 2
Does your change alter:
- The overall approach or algorithm
- The architecture or structure
- Which libraries/frameworks to use
- The data model or API design
YES → STOP
Report STATUS: STOPPED
Continue to Step 3
NO → Continue to Step 4
Example: STATUS: STOPPED REASON: Plan specifies JWT auth but existing service uses OAuth2. Implementing JWT would require refactoring auth service. TASK: Task 3 - Implement authentication middleware
**STOP HERE. Do not proceed with implementation.**
</EXTREMELY-IMPORTANT>
### Step 4: Follow plan exactly
Implement the task exactly as specified in plan.
Report STATUS: OK when complete.
## Status Reporting (REQUIRED)
<EXTREMELY-IMPORTANT>
**Every task completion MUST include STATUS.**
</EXTREMELY-IMPORTANT>
### STATUS: OK
Use when task completed as planned:
STATUS: OK TASK: Task 3 - Implement authentication middleware SUMMARY: Implemented JWT authentication middleware per plan specification.
### STATUS: STOPPED
Use when plan approach won't work:
STATUS: STOPPED REASON: [Clear explanation] TASK: [Task identifier]
**Missing STATUS = gate will block you from proceeding.**
## Red Flags (Rationalization Defense)
If you're thinking ANY of these thoughts, you're about to violate the plan:
| Thought | Reality |
|---------|---------|
| "This simpler approach would work better" | Simpler approach was likely considered and rejected in design. Report STOPPED. |
| "The plan way seems harder than necessary" | Plan reflects design decisions you don't have context for. Follow plan or report STOPPED. |
| "I can just use library X instead" | Library choice is architectural decision. Report STOPPED. |
| "This is a minor architectural change" | All architecture changes require approval. Report STOPPED. |
| "The tests would pass if I just..." | Making tests pass ≠ meeting requirements. Follow plan or report STOPPED. |
| "I'll note the deviation in my summary" | Deviations require explicit approval BEFORE implementation. Report STOPPED. |
**All of these mean: STOP. Report STATUS: STOPPED.**
## What Counts as "Following Plan Exactly"
**Allowed without STOPPED:**
- Syntax corrections (wrong function name in plan)
- Error handling implementation details (plan says "validate input", you choose validation approach)
- Variable naming (plan says "store user data", you choose variable name)
- Code organization within a file (where to place helper functions)
- Test implementation details (plan says "add tests", you write specific test cases)
**Requires STOPPED:**
- Different algorithm or approach
- Different library/framework
- Different data structure
- Different API design
- Skipping planned functionality
- Adding unplanned functionality
- Refactoring not in plan
## Common Scenarios
### Scenario: Plan has wrong function name
Plan says: "Call getUserData()" Reality: Function is actually getUser()
Decision: Fix syntax Action: Use getUser(), note in completion Status: OK
### Scenario: Plan approach seems unnecessarily complex
Plan says: "Implement manual JWT verification" Your thought: "Library X does this better and simpler"
Decision: Architectural change Action: Report STOPPED Status: STOPPED Reason: Plan specifies manual JWT verification but library X provides simpler approach. Should we use library instead?
### Scenario: Tests fail with planned approach
Plan says: "Use synchronous file reads" Reality: Tests timeout with sync reads, async would fix
Decision: Approach change Action: Report STOPPED Status: STOPPED Reason: Synchronous file reads cause test timeouts. Need async approach or different solution.
### Scenario: Plan contradicts itself
Plan Task 3: "Use PostgreSQL" Plan Task 5: "Query MongoDB"
Decision: Plan error Action: Report STOPPED Status: STOPPED Reason: Plan specifies both PostgreSQL (Task 3) and MongoDB (Task 5). Which should be used?
## Common Mistakes
**Mistake:** "This simpler approach would work better"
- **Why wrong:** Simpler approach was likely considered and rejected in design
- **Fix:** Report STATUS: STOPPED, don't implement
**Mistake:** "This is a minor architectural change"
- **Why wrong:** All architecture changes require approval
- **Fix:** Report STATUS: STOPPED for any approach/architecture change
**Mistake:** "I'll note the deviation in my summary"
- **Why wrong:** Deviations require explicit approval BEFORE implementation
- **Fix:** Report STATUS: STOPPED before making changes
**Mistake:** "The tests would pass if I just use library X instead"
- **Why wrong:** Making tests pass ≠ meeting requirements, library choice is architectural
- **Fix:** Report STATUS: STOPPED, explain issue
**Mistake:** "Forgot to include STATUS in my completion report"
- **Why wrong:** Missing STATUS = gate will block you from proceeding
- **Fix:** Always include STATUS: OK or STATUS: STOPPED
## Remember
- **Syntax fixes**: Allowed (note in completion)
- **Approach changes**: Report STOPPED
- **Architecture changes**: Report STOPPED
- **Plan errors**: Report STOPPED
- **Always provide STATUS**: OK or STOPPED
- **When in doubt**: Report STOPPED
**Better to report STOPPED unnecessarily than to deviate from plan without approval.**