maxsimcli 4.0.1 → 4.0.2

package/dist/assets/templates/skills/simplify/SKILL.md

@@ -1,185 +1,142 @@
 ---
 name: simplify
-description: Use after implementation and before commit — requires reviewing changed code for reuse opportunities, quality issues, and unnecessary complexity
+description: >-
+  Reviews changed code for reuse opportunities, unnecessary complexity, and
+  dead weight using three parallel review agents. Use when reviewing code
+  before committing, cleaning up implementations, or preparing changes for
+  review.
 ---
 
 # Simplify
 
-Every line of code is a liability. Less code that does the same thing is always better.
+Every line of code is a liability. Remove what does not earn its place.
 
-**If you have not looked for ways to simplify, you are shipping the first draft.**
+**HARD GATE**: No code ships without a simplification pass. If you have not checked for duplication, dead code, and unnecessary complexity, the change is not ready. "It works" is the starting point, not the finish line.
 
-## The Iron Law
+## When to Use
 
-<HARD-GATE>
-NO COMMIT WITHOUT REVIEWING FOR SIMPLIFICATION.
-If you have not checked for duplication, dead code, and unnecessary complexity, you CANNOT commit.
-"It works" is the starting point, not the finish line.
-Violating this rule is a violation — not a preference.
-</HARD-GATE>
+- After implementing a feature or fix, before committing
+- When preparing changes for code review
+- When cleaning up code that has grown organically over multiple iterations
+- When onboarding to a file and noticing accumulated complexity
 
-## The Gate Function
+Do NOT use this skill when:
+- Making a hotfix where speed matters more than polish (file a follow-up instead)
+- The changes are purely mechanical (renames, formatting, dependency bumps)
 
-After implementation is complete and tests pass, BEFORE committing:
+## Process
 
-### 1. DIFF — Review What Changed
+### 1. DIFF — Identify What Changed
 
-- Run `git diff --staged` (or `git diff` for unstaged changes)
-- Read every line you are about to commit
-- Flag anything that feels "off" — trust that instinct
+- Collect the set of modified and added files
+- Read each file in full, not just the changed hunks
+- Note files that interact with the changes (callers, consumers, shared modules)
 
-```bash
-# Review staged changes
-git diff --staged
-# Or all uncommitted changes
-git diff
-```
+### 2. DUPLICATION — Eliminate Repeated Logic
 
-### 2. DUPLICATION — Find Reuse Opportunities
+- Are there patterns repeated across files that should be a shared helper?
+- Does new code duplicate existing utilities or library functions?
+- Could two similar implementations be merged behind a single interface?
+- Is there copy-paste that should be refactored?
 
-- Does any new code duplicate existing logic in the codebase?
-- Are there two or more blocks that do similar things and could share a helper?
-- Could an existing utility, library function, or helper replace new code?
-- Is there copy-paste from another file that should be extracted?
+**Rule of three**: If the same pattern appears three times, extract it.
 
-**Rule of three:** If the same pattern appears three times, extract it. Two occurrences are acceptable.
+### 3. DEAD CODE — Remove What Is Not Called
 
-### 3. DEAD CODE — Remove What Is Not Used
-
-- Are there unused imports, variables, or functions?
-- Are there commented-out code blocks? (Delete them — git has history)
-- Are there unreachable branches or impossible conditions?
-- Are there parameters that are always passed the same value?
-
-**If it is not called, it does not belong. Delete it.**
+- Delete unused imports, variables, functions, and parameters
+- Remove commented-out code blocks (version control is the archive)
+- Strip unreachable branches and impossible conditions
+- Drop feature flags and configuration for features that no longer exist
 
 ### 4. COMPLEXITY — Question Every Abstraction
 
-- Is there a wrapper that adds no value beyond indirection?
-- Is there a generic solution where a specific one would be simpler?
-- Are there feature flags, configuration options, or extension points for hypothetical future needs?
-- Could a 3-line inline block replace a 20-line abstraction?
+- Does every wrapper, adapter, or indirection layer justify its existence?
+- Are there generics or parametrization that serve only one concrete case?
+- Could a 20-line class be replaced by a 3-line function?
+- Is there defensive programming that guards against conditions that cannot occur?
 
-**The right amount of abstraction is the minimum needed for the current requirements.**
+**If removing it does not break anything, it should not be there.**
 
-### 5. CLARITY — Improve Readability
+### 5. CLARITY — Tighten Naming and Structure
 
-- Are variable and function names self-explanatory?
-- Could a confusing block be rewritten more clearly without comments?
-- Are there nested conditions that could be flattened with early returns?
-- Is the control flow straightforward or unnecessarily clever?
+- Are names self-documenting? Rename anything that needs a comment to explain.
+- Could nested logic be flattened with early returns?
+- Is control flow straightforward, or does it require tracing to understand?
+- Are there layers of indirection that obscure the data path?
 
-### 6. EFFICIENCY — Check for Obvious Issues
+### 6. REVIEW — Final Sanity Check
 
-- Are there O(n^2) operations where O(n) is straightforward?
-- Are there repeated computations that could be cached or hoisted?
-- Are there unnecessary allocations in hot paths?
-- Is data being transformed multiple times when once would suffice?
+- Re-read the simplified code end to end
+- Confirm all tests still pass
+- Verify no behavioral changes were introduced (simplify, do not alter)
 
-**Only fix efficiency issues that are obvious. Do not optimize without evidence of a problem.**
+## Parallel 3-Reviewer Pattern
 
-## Review Checklist
+When invoked as part of the execute-phase cycle, simplification runs as three parallel review agents, each focused on one dimension.
 
-| Category | Question | Action if Yes |
-|----------|----------|---------------|
-| Duplication | Same logic exists elsewhere? | Extract shared helper or reuse existing |
-| Duplication | Copy-paste from another file? | Extract to shared module |
-| Dead code | Unused imports or variables? | Delete them |
-| Dead code | Commented-out code? | Delete it (git has history) |
-| Complexity | Abstraction for one call site? | Inline it |
-| Complexity | Generic where specific suffices? | Simplify to specific |
-| Complexity | Config for hypothetical needs? | Remove until needed |
-| Clarity | Confusing variable name? | Rename to describe purpose |
-| Clarity | Deep nesting? | Flatten with early returns |
-| Efficiency | O(n^2) with obvious O(n) fix? | Fix it now |
-| Efficiency | Same computation in a loop? | Hoist outside the loop |
+### Reviewer 1: Code Reuse
 
-## Common Rationalizations — REJECT THESE
+- Scan all changed files for duplicated patterns
+- Cross-reference against existing shared utilities and helpers
+- Flag any logic that appears three or more times without extraction
+- **Output**: List of reuse opportunities with file paths and line ranges
 
-| Excuse | Why It Violates the Rule |
-|--------|--------------------------|
-| "It works, don't touch it" | Working is the minimum bar. Simplify before it becomes legacy. |
-| "We might need the flexibility later" | YAGNI. Add flexibility when you need it, not before. |
-| "Refactoring is risky" | Small simplifications with passing tests are safe. Large refactors are a separate task. |
-| "The duplication is minor" | Minor duplication compounds. Three occurrences is the threshold, not six. |
-| "I'll clean it up in a follow-up" | Follow-ups rarely happen. Simplify now while context is fresh. |
-| "It's just a few extra lines" | Every unnecessary line is maintenance cost. Delete it. |
+### Reviewer 2: Code Quality
 
-## Red Flags — STOP If You Catch Yourself:
+- Check for dead code: unused imports, unreachable branches, commented blocks
+- Verify naming consistency with codebase conventions
+- Flag unnecessary abstractions, wrappers, and indirection
+- **Output**: List of quality issues categorized by severity
 
-- Committing without reading your own diff
-- Keeping dead code "just in case"
-- Adding a utility class for a single use case
-- Building configuration for features no one has requested
-- Writing a comment to explain code that could be rewritten to be self-evident
-- Skipping simplification because "it's good enough"
+### Reviewer 3: Efficiency
 
-**If any red flag triggers: STOP. Review the diff again. Simplify before committing.**
+- Identify over-engineered solutions (parametrization serving one case, generic interfaces with one implementor)
+- Flag defensive programming that guards impossible conditions
+- Check for configuration and feature flags that serve no current purpose
+- **Output**: List of efficiency issues with suggested removals
 
-## Verification Checklist
+### Consolidation
 
-Before committing, confirm:
+After all three reviewers complete:
+1. Merge findings into a deduplicated list
+2. Apply fixes for all actionable items (BLOCKER and HIGH priority first)
+3. Re-run tests to confirm nothing broke
+4. Report status: CLEAN (nothing found), FIXED (issues resolved), or BLOCKED (cannot simplify without architectural changes)
 
-- [ ] All staged changes have been reviewed line by line
-- [ ] No duplication with existing codebase logic (or duplication is below threshold)
-- [ ] No dead code: unused imports, variables, unreachable branches, commented code
-- [ ] No unnecessary abstractions, wrappers, or premature generalizations
-- [ ] Naming is clear and consistent with codebase conventions
-- [ ] No obvious efficiency issues (unnecessary O(n^2), repeated computations)
-- [ ] Tests still pass after simplification changes
+## Common Rationalizations — REJECT THESE
 
-## In MAXSIM Plan Execution
+| Excuse | Why It Violates the Rule |
+|--------|--------------------------|
+| "It might be needed later" | Delete it. Re-adding is cheaper than maintaining unused code. |
+| "The abstraction makes it extensible" | Extensibility that serves no current requirement is dead weight. |
+| "Refactoring is risky" | Small, tested simplifications reduce risk. Accumulated complexity increases it. |
+| "I'll clean it up later" | Later never comes. Simplify now while context is fresh. |
 
-Simplification applies at the task level, after implementation and before commit:
-- After task implementation is complete and tests pass, run this review
-- Make simplification changes as part of the same commit (not a separate task)
-- If simplification reveals a larger refactoring opportunity, file a todo — do not scope-creep
-- Track significant simplifications in the task's commit message (e.g., "extracted shared helper for X")
+## Red Flags — STOP If You Catch Yourself:
 
-## Parallel 3-Reviewer Pattern (Execution Pipeline)
+- Skipping the simplification pass because the diff is small
+- Keeping dead code "just in case"
+- Adding complexity during a simplification pass
+- Merging without having read the full file (not just changed lines)
 
-When invoked as part of the Execute-Review-Simplify-Review cycle in `execute-plan.md`, simplification runs as 3 parallel review agents. Each reviewer focuses on one dimension:
+**If any red flag triggers: STOP. Complete the simplification cycle before proceeding.**
 
-### Reviewer 1: Code Reuse
-- Find duplicated logic across the codebase (not just within changed files)
-- Identify copy-paste from other files that should be extracted to shared modules
-- Suggest shared helpers for patterns appearing 3+ times (Rule of Three)
-- Check if existing utility functions, library methods, or helpers could replace new code
-- **Output:** List of reuse opportunities with file paths and line ranges
+## Verification Checklist
 
-### Reviewer 2: Code Quality
-- Check naming consistency with codebase conventions (read CLAUDE.md first)
-- Verify error handling covers all external calls and edge cases
-- Look for dead code: unused imports, variables, unreachable branches, commented-out code
-- Check for unnecessary abstractions, wrappers, or premature generalizations
-- Verify security: no hardcoded secrets, no unsanitized inputs, no data exposure
-- **Output:** List of quality issues categorized by severity (BLOCKER, HIGH, MEDIUM)
+Before reporting completion, confirm:
 
-### Reviewer 3: Efficiency
-- Find O(n^2) operations where O(n) is straightforward
-- Identify repeated computations that could be cached or hoisted out of loops
-- Check for unnecessary allocations in hot paths
-- Look for redundant data transformations (data processed multiple times when once suffices)
-- Only flag obvious issues — do not optimize without evidence of a problem
-- **Output:** List of efficiency issues with suggested fixes
+- [ ] All changed files were reviewed in full (not just diffs)
+- [ ] No duplicated logic remains that appears three or more times
+- [ ] No dead code: unused imports, commented blocks, unreachable branches
+- [ ] No unnecessary abstractions, wrappers, or indirection layers
+- [ ] All tests pass after simplification
+- [ ] No behavioral changes were introduced (simplify only, do not alter)
 
-### Consolidation
+## MAXSIM Integration
 
-After all 3 reviewers report, the orchestrating agent:
-1. Merges findings into a single deduplicated list
-2. Prioritizes: BLOCKER > HIGH > MEDIUM > informational
-3. Applies fixes for all actionable items (BLOCKER and HIGH)
-4. Files MEDIUM issues as todos if they require larger refactoring
-5. Runs tests to confirm fixes do not break anything
-6. Reports final status: CLEAN (nothing found), FIXED (issues found and resolved), or BLOCKED (cannot fix without architectural change)
-
-### Spawning Pattern
-
-Each reviewer is spawned as a parallel agent via the Agent tool:
-```
-# All 3 run in parallel
-Task(prompt="Reviewer 1: Code Reuse — {files_to_review} ...", subagent_type="maxsim-executor")
-Task(prompt="Reviewer 2: Code Quality — {files_to_review} ...", subagent_type="maxsim-executor")
-Task(prompt="Reviewer 3: Efficiency — {files_to_review} ...", subagent_type="maxsim-executor")
-# Wait for all 3 to complete, then consolidate
-```
+When a plan specifies `skill: "simplify"`:
+- The orchestrator collects changed files from the implementation step
+- Three parallel reviewers (Reuse, Quality, Efficiency) are spawned
+- Findings are consolidated and fixes applied
+- Progress is tracked in STATE.md via decision entries
+- Final results are recorded in SUMMARY.md

package/dist/assets/templates/skills/systematic-debugging/SKILL.md

@@ -1,104 +1,71 @@
 ---
 name: systematic-debugging
-description: Use when encountering any bug, test failure, or unexpected behavior — requires root cause investigation before attempting any fix
+description: >-
+  Investigates bugs through systematic root-cause analysis: reproduce, hypothesize,
+  isolate, verify, fix, confirm. Use when encountering any bug, test failure,
+  unexpected behavior, or error message.
 ---
 
 # Systematic Debugging
 
-Random fixes waste time and create new bugs. Find the root cause first.
+Find the root cause first. Random fixes waste time and create new bugs.
 
-**If you have not identified the root cause, you are guessing — not debugging.**
+**HARD GATE -- No fix attempts without understanding root cause. If you have not completed the REPRODUCE and HYPOTHESIZE steps, you cannot propose a fix.**
 
-## The Iron Law
+## Process
 
-<HARD-GATE>
-NO FIX ATTEMPTS WITHOUT UNDERSTANDING ROOT CAUSE.
-If you have not completed the REPRODUCE and HYPOTHESIZE steps, you CANNOT propose a fix.
-"Let me just try this" is guessing, not debugging.
-Violating this rule is a violation — not a time-saving shortcut.
-</HARD-GATE>
-
-## The Gate Function
-
-Follow these steps IN ORDER for every bug, test failure, or unexpected behavior.
-
-### 1. REPRODUCE — Confirm the Problem
+### 1. REPRODUCE -- Confirm the Problem
 
 - Run the failing command or test. Capture the EXACT error output.
 - Can you trigger it reliably? What are the exact steps?
-- If not reproducible: gather more data — do not guess.
-
-```bash
-# Example: reproduce a test failure
-npx vitest run path/to/failing.test.ts
-```
+- If not reproducible: gather more data -- do not guess.
 
-### 2. HYPOTHESIZE — Form a Theory
+### 2. HYPOTHESIZE -- Form a Theory
 
-- Read the error message COMPLETELY (stack trace, line numbers, exit codes)
-- Check recent changes: `git diff`, recent commits, new dependencies
+- Read the error message completely (stack trace, line numbers, exit codes).
+- Check recent changes: `git diff`, recent commits, new dependencies.
 - Trace data flow: where does the bad value originate?
-- State your hypothesis clearly: "I think X is the root cause because Y"
+- State your hypothesis clearly: "I think X is the root cause because Y."
 
-### 3. ISOLATE — Narrow the Scope
+### 3. ISOLATE -- Narrow the Scope
 
-- Find the SMALLEST reproduction case
-- In multi-component systems, add diagnostic logging at each boundary
-- Identify which SPECIFIC layer or component is failing
-- Compare against working examples in the codebase
+- Find the smallest reproduction case.
+- In multi-component systems, add diagnostic logging at each boundary.
+- Identify which specific layer or component is failing.
+- Compare against working examples in the codebase.
 
-### 4. VERIFY — Test Your Hypothesis
+### 4. VERIFY -- Test Your Hypothesis
 
-- Make the SMALLEST possible change to test your hypothesis
-- Change ONE variable at a time — never multiple things simultaneously
-- If hypothesis is wrong: form a NEW hypothesis, do not stack fixes
+- Make the smallest possible change to test your hypothesis.
+- Change one variable at a time -- never multiple things simultaneously.
+- If hypothesis is wrong: form a new hypothesis, do not stack fixes.
 
-### 5. FIX — Address the Root Cause
+### 5. FIX -- Address the Root Cause
 
-- Write a failing test that reproduces the bug (see TDD skill)
-- Implement a SINGLE fix that addresses the root cause
-- No "while I'm here" improvements — fix only the identified issue
+- Write a failing test that reproduces the bug.
+- Implement a single fix that addresses the root cause.
+- No "while I'm here" improvements -- fix only the identified issue.
 
-### 6. CONFIRM — Verify the Fix
+### 6. CONFIRM -- Verify the Fix
 
-- Run the original failing test: it must now pass
-- Run the full test suite: no regressions
-- Verify the original error no longer occurs
+- Run the original failing test: it must now pass.
+- Run the full test suite: no regressions.
+- Verify the original error no longer occurs.
 
-```bash
-# Confirm the specific fix
-npx vitest run path/to/fixed.test.ts
-# Confirm no regressions
-npx vitest run
-```
+## Common Pitfalls
 
-## Common Rationalizations — REJECT THESE
-
-| Excuse | Why It Violates the Rule |
-|--------|--------------------------|
-| "I think I know what it is" | Thinking is not evidence. Reproduce first, then hypothesize. |
-| "Let me just try this fix" | "Just try" = guessing. You have skipped REPRODUCE and HYPOTHESIZE. |
-| "Quick patch for now, investigate later" | "Later" never comes. Patches mask the real problem. |
+| Excuse | Reality |
+|--------|---------|
+| "I think I know what it is" | Thinking is not evidence. Reproduce first. |
+| "Let me just try this fix" | That is guessing. Complete REPRODUCE and HYPOTHESIZE first. |
 | "Multiple changes at once saves time" | You cannot isolate what worked. You will create new bugs. |
-| "The issue is simple, I don't need the process" | Simple bugs have root causes too. The process is fast for simple bugs. |
-| "I'm under time pressure" | Systematic debugging IS faster than guess-and-check thrashing. |
-| "The reference is too long, I'll skim it" | Partial understanding guarantees partial fixes. Read it completely. |
-
-## Red Flags — STOP If You Catch Yourself:
-
-- Changing code before reproducing the error
-- Proposing a fix before reading the full error message and stack trace
-- Trying random fixes hoping one will work
-- Changing multiple things simultaneously
-- Saying "it's probably X" without evidence
-- Applying a fix that did not work, then adding another fix on top
-- On your 3rd failed fix attempt (this signals an architectural problem — escalate)
+| "The issue is simple" | Simple bugs have root causes too. The process is fast for simple bugs. |
 
-**If any red flag triggers: STOP. Return to step 1 (REPRODUCE).**
+Stop immediately if you catch yourself changing code before reproducing, proposing a fix before reading the full error, trying random fixes, or changing multiple things at once. If any of these triggers, return to step 1.
 
-**If 3+ fix attempts have failed:** The issue is likely architectural, not a simple bug. Document what you have tried and escalate to the user for a design decision.
+If 3+ fix attempts have failed, the issue is likely architectural. Document what you have tried and escalate to the user.
 
-## Verification Checklist
+## Verification
 
 Before claiming a bug is fixed, confirm:
 
@@ -110,9 +77,9 @@ Before claiming a bug is fixed, confirm:
 - [ ] The full test suite passes (no regressions)
 - [ ] The original error no longer occurs when running the original steps
 
-## Debugging in MAXSIM Context
+## MAXSIM Integration
 
 When debugging during plan execution, MAXSIM deviation rules apply:
 - **Rule 1 (Auto-fix bugs):** You may auto-fix bugs found during execution, but you must still follow this debugging process.
-- **Rule 4 (Architectural changes):** If 3+ fix attempts fail, STOP and return a checkpoint — this is an architectural decision for the user.
+- **Rule 4 (Architectural changes):** If 3+ fix attempts fail, STOP and return a checkpoint -- this is an architectural decision for the user.
 - Track all debugging deviations for SUMMARY.md documentation.

package/dist/assets/templates/skills/tdd/SKILL.md

@@ -1,93 +1,70 @@
 ---
 name: tdd
-description: Use when implementing any feature or bug fix — requires writing a failing test before any implementation code
+description: >-
+  Enforces test-driven development with the Red-Green-Refactor cycle: write a
+  failing test first, implement minimal code to pass, then refactor. Use when
+  implementing features, fixing bugs, or adding new behavior.
 ---
 
 # Test-Driven Development (TDD)
 
 Write the test first. Watch it fail. Write minimal code to pass. Clean up.
 
-**If you did not watch the test fail, you do not know if it tests the right thing.**
+**HARD GATE: No implementation code without a failing test first. If you wrote production code before the test, delete it and start over. No exceptions.**
 
-## The Iron Law
+## Process
 
-<HARD-GATE>
-NO IMPLEMENTATION CODE WITHOUT A FAILING TEST FIRST.
-If you wrote production code before the test, DELETE IT. Start over.
-No exceptions. No "I'll add tests after." No "keep as reference."
-Violating this rule is a violation — not a judgment call.
-</HARD-GATE>
+### 1. RED -- Write One Failing Test
 
-## The Gate Function
-
-Follow this cycle for every behavior change, feature addition, or bug fix.
-
-### 1. RED — Write Failing Test
-
-- Write ONE minimal test that describes the desired behavior
+- Write ONE minimal test describing the desired behavior
 - Test name describes what SHOULD happen, not implementation details
-- Use real code paths — mocks only when unavoidable (external APIs, databases)
+- Use real code paths -- mocks only when unavoidable (external APIs, databases)
 
-### 2. VERIFY RED — Run the Test
+### 2. VERIFY RED -- Run the Test
 
-```bash
-# Run the test suite for this file
-npx vitest run path/to/test.test.ts
-```
-
-- Test MUST fail (not error — fail with an assertion)
+- Test MUST fail with an assertion (not error out from syntax or imports)
 - Failure message must match the missing behavior
-- If test passes immediately: you are testing existing behavior — rewrite it
+- If the test passes immediately, you are testing existing behavior -- rewrite it
 
-### 3. GREEN — Write Minimal Code
+### 3. GREEN -- Write Minimal Code
 
 - Write the SIMPLEST code that makes the test pass
 - Do NOT add features the test does not require
-- Do NOT refactor yet — that comes next
-
-### 4. VERIFY GREEN — Run All Tests
+- Do NOT refactor yet
 
-```bash
-npx vitest run
-```
+### 4. VERIFY GREEN -- Run All Tests
 
 - The new test MUST pass
 - ALL existing tests MUST still pass
-- If any test fails: fix code, not tests
+- If any test fails, fix code -- not tests
 
-### 5. REFACTOR — Clean Up (Tests Still Green)
+### 5. REFACTOR -- Clean Up (Tests Still Green)
 
 - Remove duplication, improve names, extract helpers
-- Run tests after every change — they must stay green
+- Run tests after every change
 - Do NOT add new behavior during refactor
 
-### 6. REPEAT — Next failing test for next behavior
+### 6. REPEAT -- Next failing test for next behavior
 
-## Common Rationalizations — REJECT THESE
+## Common Pitfalls
 
-| Excuse | Why It Violates the Rule |
-|--------|--------------------------|
-| "Too simple to test" | Simple code breaks. The test takes 30 seconds to write. |
-| "I'll add tests after" | Tests written after pass immediately — they prove nothing. |
-| "The test framework isn't set up yet" | Set it up. That is part of the task, not a reason to skip. |
+| Excuse | Why it fails |
+|--------|-------------|
+| "Too simple to test" | Simple code breaks. The test takes 30 seconds. |
+| "I'll add tests after" | Tests written after pass immediately -- they prove nothing. |
 | "I know the code works" | Knowledge is not evidence. A passing test is evidence. |
-| "TDD is slower for this task" | TDD is faster than debugging. Every "quick skip" creates debt. |
+| "TDD is slower" | TDD is faster than debugging. Every skip creates debt. |
 | "Let me keep the code as reference" | You will adapt it instead of writing test-first. Delete means delete. |
-| "I need to explore the design first" | Explore, then throw it away. Start implementation with TDD. |
 
-## Red Flags — STOP If You Catch Yourself:
+Stop immediately if you catch yourself:
 
 - Writing implementation code before writing a test
-- Writing a test that passes on the first run (you are testing existing behavior)
-- Skipping the VERIFY RED step ("I know it will fail")
+- Writing a test that passes on the first run
+- Skipping the VERIFY RED step
 - Adding features beyond what the current test requires
-- Skipping the REFACTOR step to save time
-- Rationalizing "just this once" or "this is different"
-- Keeping pre-TDD code "as reference" while writing tests
+- Keeping pre-TDD code "as reference"
 
-**If any red flag triggers: STOP. Delete the implementation. Write the test first.**
-
-## Verification Checklist
+## Verification
 
 Before claiming TDD compliance, confirm:
 
@@ -99,20 +76,10 @@ Before claiming TDD compliance, confirm:
 - [ ] All tests pass after implementation
 - [ ] Refactoring (if any) did not break any tests
 
-Cannot check all boxes? You skipped TDD. Start over.
-
-## When Stuck
-
-| Problem | Solution |
-|---------|----------|
-| Don't know how to test it | Write the assertion first. What should the output be? |
-| Test setup is too complex | The design is too complex. Simplify the interface. |
-| Must mock everything | Code is too coupled. Use dependency injection. |
-| Existing code has no tests | Add tests for the code you are changing. Start the cycle now. |
-
-## Integration with MAXSIM
+## MAXSIM Integration
 
 In MAXSIM plan execution, tasks marked `tdd="true"` follow this cycle with per-step commits:
+
 - **RED commit:** `test({phase}-{plan}): add failing test for [feature]`
 - **GREEN commit:** `feat({phase}-{plan}): implement [feature]`
 - **REFACTOR commit (if changes made):** `refactor({phase}-{plan}): clean up [feature]`