Algorithmic decision tree for when to follow plan exactly vs when to report BLOCKED - prevents scope creep and unauthorized deviations
Uses an algorithmic decision tree to determine when to follow plans exactly versus reporting BLOCKED, preventing unauthorized deviations and scope creep during execution. Triggers when encountering plan contradictions, syntax errors, or when considering alternative approaches.
/plugin marketplace add cipherstash/cipherpowers/plugin install cipherpowers@cipherpowersThis skill inherits all available tools. When active, it can use any tool Claude has access to.
README.mdtest-pressure-1.mdtest-pressure-2.mdtest-pressure-3.mdThis 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 BLOCKED.
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: BLOCKED with reason
└─ NO → Follow plan exactly, STATUS: OK
Allowed without BLOCKED:
Requires BLOCKED:
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: BLOCKED
Continue to Step 3
NO → Continue to Step 4
Example: STATUS: BLOCKED 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: BLOCKED
Use when plan approach won't work:
STATUS: BLOCKED 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 BLOCKED. |
| "The plan way seems harder than necessary" | Plan reflects design decisions you don't have context for. Follow plan or report BLOCKED. |
| "I can just use library X instead" | Library choice is architectural decision. Report BLOCKED. |
| "This is a minor architectural change" | All architecture changes require approval. Report BLOCKED. |
| "The tests would pass if I just..." | Making tests pass ≠ meeting requirements. Follow plan or report BLOCKED. |
| "I'll note the deviation in my summary" | Deviations require explicit approval BEFORE implementation. Report BLOCKED. |
**All of these mean: STOP. Report STATUS: BLOCKED.**
## What Counts as "Following Plan Exactly"
**Allowed without BLOCKED:**
- 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 BLOCKED:**
- 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 BLOCKED Status: BLOCKED 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 BLOCKED Status: BLOCKED 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 BLOCKED Status: BLOCKED 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: BLOCKED, don't implement
**Mistake:** "This is a minor architectural change"
- **Why wrong:** All architecture changes require approval
- **Fix:** Report STATUS: BLOCKED 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: BLOCKED 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: BLOCKED, 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: BLOCKED
## Remember
- **Syntax fixes**: Allowed (note in completion)
- **Approach changes**: Report BLOCKED
- **Architecture changes**: Report BLOCKED
- **Plan errors**: Report BLOCKED
- **Always provide STATUS**: OK or BLOCKED
- **When in doubt**: Report BLOCKED
**Better to report BLOCKED unnecessarily than to deviate from plan without approval.**
This skill should be used when the user asks to "create a slash command", "add a command", "write a custom command", "define command arguments", "use command frontmatter", "organize commands", "create command with file references", "interactive command", "use AskUserQuestion in command", or needs guidance on slash command structure, YAML frontmatter fields, dynamic arguments, bash execution in commands, user interaction patterns, or command development best practices for Claude Code.
This skill should be used when the user asks to "create an agent", "add an agent", "write a subagent", "agent frontmatter", "when to use description", "agent examples", "agent tools", "agent colors", "autonomous agent", or needs guidance on agent structure, system prompts, triggering conditions, or agent development best practices for Claude Code plugins.
This skill should be used when the user asks to "create a hook", "add a PreToolUse/PostToolUse/Stop hook", "validate tool use", "implement prompt-based hooks", "use ${CLAUDE_PLUGIN_ROOT}", "set up event-driven automation", "block dangerous commands", or mentions hook events (PreToolUse, PostToolUse, Stop, SubagentStop, SessionStart, SessionEnd, UserPromptSubmit, PreCompact, Notification). Provides comprehensive guidance for creating and implementing Claude Code plugin hooks with focus on advanced prompt-based hooks API.