Algorithmic decision tree enforcing test-first development via boolean conditions instead of imperatives
Uses a binary decision tree to enforce test-first development. Triggers when you're about to write implementation code or have untested code, forcing you to write failing tests first or delete untested code.
/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.
test-pressure-1.mdtest-pressure-2.mdtest-pressure-3.mdAgents follow algorithmic decision trees (100% compliance) better than imperative instructions (0-33% compliance) for enforcing test-first development. Boolean conditions remove interpretation: "Does failing test exist? NO → STOP" vs "You MUST write tests first" (agent: "for complex code, mine is simple").
Core principle: Binary checks before implementation. Recovery mandates deleting untested code (no sunk cost exceptions).
Use this algorithm when:
Use upstream TDD skill when:
Relationship:
Are you about to write implementation code?
Does throwaway prototype exception apply (user approved)?
Does a failing test exist for this code?
STOP writing implementation code. Write failing test first.
Run project test command
Test exists OR not writing code OR approved exception - proceed
Have you written ANY implementation code?
Does that code have tests that failed first?
Delete the untested code. Execute: git reset --hard OR rm [files]. Do not keep as "reference".
Tests exist OR no code written - continue
These rationalizations are NOT VALID ALGORITHM CONDITIONS:
All of these mean: Run the algorithm. Follow what it says.
Q1: You're about to write function calculateTotal(). What does Step 3 ask?
Answer: "Does a failing test exist?" If NO → Go to Step 4 (STOP, write test first)
Q2: I wrote 100 lines without tests. What does Recovery Step 3 say?
Answer: Delete the untested code. Execute: git reset --hard OR rm [files]
Q3: "This code is too simple to need tests" - is this a valid algorithm condition?
Answer: NO. Listed under INVALID conditions
Q4: Can I keep untested code as "reference" while writing tests?
Answer: NO. Recovery Step 3 says "Delete... Do not keep as 'reference'"
Imperative: "You MUST write tests first" Agent rationalization: "For complex code. Mine is simple."
Algorithmic: "Does a failing test exist? → YES/NO" Agent: Binary check. Either test exists or it doesn't. No interpretation.
Imperative: "Regardless of simplicity or time pressure..." Agent: Still debates what "simple" means
Algorithmic: "Is code too simple to test?" → NOT A VALID CONDITION Agent: Sees rationalization explicitly invalidated. Can't use it.
Imperative: Multiple MUST statements → agent balances priorities
Algorithmic:
Step 4: STOP writing implementation code
Write failing test first
Result: Single path. No choices. STOP prevents continuing.
Quiz with correct answers:
Q1: About to write function. Step 3 asks?
Answer: Does a failing test exist?
Agents demonstrate understanding before proceeding. Catches comprehension failures early.
Step 5: [UNREACHABLE - if you reach here, you violated Step 4]
Demonstrates algorithm is deterministic. Reaching Step 5 = violation.
Evidence from algorithmic-command-enforcement pattern:
Agent quotes (from /execute command testing):
"The algorithm successfully prevented me from rationalizing..."
"Non-factors correctly ignored: ❌ 2 hours sunk cost, ❌ Exhaustion"
"Step 2: Does code have tests? → NO. Step 3: Delete the untested code"
| Rationalization | How Algorithm Prevents |
|---|---|
| "Too simple for tests" | NOT A VALID CONDITION - Step 3 checks test existence, not code complexity |
| "Deleting X hours wasteful" | NOT A VALID CONDITION - Recovery Step 3 mandates delete unconditionally |
| "Will add tests after" | NOT A VALID CONDITION - Step 4 requires test FIRST (not after) |
| "Manual testing sufficient" | NOT A VALID CONDITION - Step 3 checks "failing test exists", not "tested somehow" |
| "Time pressure exception" | NOT A VALID CONDITION - Time not in algorithm, only user-approved prototype exception |
| "Keep as reference" | Recovery Step 3 explicit: "Do not keep as 'reference'" |
This algorithm provides: WHEN to write tests (before implementation)
For complete TDD methodology, see:
${CLAUDE_PLUGIN_ROOT}skills/test-driven-development/SKILL.md
Workflow:
Previous approach (imperative):
"Write the test first. Watch it fail. Write minimal code to pass. The Iron Law: NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST"
Problem: Agents acknowledged then rationalized bypass:
Solution: Algorithm with binary conditions. No subjective interpretation possible.
Evidence: Based on plugin/skills/algorithmic-command-enforcement/SKILL.md pattern showing 0% → 100% compliance improvement.
Pressure test scenarios: docs/tests/tdd-enforcement-pressure-scenarios.md
Scenarios test algorithm under:
Method: RED (baseline without algorithm) → GREEN (with algorithm) → measure compliance
Success criteria: 80%+ compliance improvement
Algorithmic pattern: plugin/skills/algorithmic-command-enforcement/SKILL.md
TDD methodology: ${CLAUDE_PLUGIN_ROOT}skills/test-driven-development/SKILL.md
Testing anti-patterns: ${CLAUDE_PLUGIN_ROOT}skills/testing-anti-patterns/SKILL.md
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.