feat(skills): add Batch Execution, SDD, and Writing Plans skills

templates/skills/batch-execution/SKILL.md

@@ -0,0 +1,121 @@
+---
+name: batch-execution
+description: Use when a task can be decomposed into 5-30 independent units — spawns parallel agents in isolated git worktrees, each producing its own PR
+context: fork
+---
+
+# Batch Execution
+
+Parallel work multiplies throughput. Sequential execution of independent tasks wastes time.
+
+**If the tasks are independent, they should run in parallel.**
+
+## The Iron Law
+
+<HARD-GATE>
+INDEPENDENT TASKS MUST RUN IN PARALLEL.
+If you have identified 5+ independent work units, you CANNOT execute them sequentially.
+"One at a time is simpler" is waste, not caution.
+Violating this rule is a violation — not a preference.
+</HARD-GATE>
+
+## The Gate Function
+
+### 1. DECOMPOSE — Break Work Into Independent Units
+
+- Analyze the task for independent, self-contained units
+- Each unit must: modify different files, be mergeable alone, not depend on sibling units
+- Target 5-30 units depending on scope (few files → 5, many files → 30)
+- Units should be roughly uniform in size
+
+### 2. VERIFY INDEPENDENCE — Check for Conflicts
+
+- No two units modify the same file (or the same section of a shared file)
+- No unit depends on another unit's output to start
+- Each unit can be tested in isolation
+- Merge order does not matter
+
+### 3. SPAWN — Create Isolated Workers
+
+- Each worker gets its own git worktree (isolated copy of the repo)
+- Each worker receives: the overall goal, its specific unit task, codebase conventions, verification recipe
+- All workers launch simultaneously in a single message
+- Workers run in background — do not block on individual completion
+
+### 4. MONITOR — Track Progress
+
+Maintain a status table:
+
+| # | Unit | Status | PR |
+|---|------|--------|----|
+| 1 | <title> | running / done / failed | <url> |
+
+- Update as workers report completion
+- Track failures separately with brief error notes
+
+### 5. VERIFY — Check Each Worker's Output
+
+- Each worker must: run tests, verify build, commit, push, create PR
+- Failed workers are retried once with the error context
+- If a worker fails twice, mark as failed and note the reason
+
+### 6. AGGREGATE — Merge Results
+
+- All PRs should pass CI independently
+- Merge in any order (independence guarantee)
+- Produce a final summary: X/Y units completed as PRs
+
+## Common Rationalizations — REJECT THESE
+
+| Excuse | Why It Violates the Rule |
+|--------|--------------------------|
+| "Sequential is simpler" | Simpler for you, slower for the user. Parallel is the job. |
+| "What if they conflict?" | Verify independence first (step 2). If they conflict, they are not independent — re-decompose. |
+| "Too many agents" | The threshold is 5 units. Below 5, sequential is acceptable. Above 5, parallelize. |
+| "I'll batch the small ones" | Small units are the easiest to parallelize. Do not combine them. |
+| "Worktrees are complex" | Worktree creation is automated. Your job is decomposition and monitoring. |
+
+## Red Flags — STOP If You Catch Yourself:
+
+- Running independent tasks one at a time
+- Creating units that modify the same file
+- Launching workers without independence verification
+- Not monitoring worker progress
+- Merging without checking each PR passes CI
+
+**If any red flag triggers: STOP. Re-decompose or verify independence before proceeding.**
+
+## Verification Checklist
+
+Before claiming batch execution is complete:
+
+- [ ] All work units were independent (no shared file modifications)
+- [ ] All workers ran in isolated git worktrees
+- [ ] All workers were launched simultaneously (not sequentially)
+- [ ] Progress was tracked via status table
+- [ ] Each completed worker produced a PR
+- [ ] Failed workers were retried once or documented
+- [ ] Final summary shows completion rate
+
+## Integration with MAXSIM
+
+### Context Loading
+
+```bash
+node ~/.claude/maxsim/bin/maxsim-tools.cjs skill-context batch-execution
+```
+
+### In Plan Execution
+
+Batch execution applies when a plan has multiple independent tasks in the same wave:
+- The orchestrator identifies independent tasks within a wave
+- Each task is assigned to a worker in an isolated worktree
+- Workers follow the full task protocol (implement → simplify → verify → commit)
+- The orchestrator aggregates results and updates the phase status
+
+### STATE.md Hooks
+
+- Record batch execution start with unit count
+- Track completion rate as workers finish
+- Record final aggregate result (X/Y succeeded)
+- Failed units become blockers for follow-up

templates/skills/subagent-driven-development/SKILL.md

@@ -0,0 +1,126 @@
+---
+name: subagent-driven-development
+description: Use when executing multi-task plans — spawns a fresh subagent per task with 2-stage review between tasks to prevent context rot
+context: fork
+---
+
+# Subagent-Driven Development (SDD)
+
+Context rots. Fresh agents make fewer mistakes than tired ones.
+
+**If your context is deep, your next task deserves a fresh agent.**
+
+## The Iron Law
+
+<HARD-GATE>
+ONE TASK PER SUBAGENT.
+Each task in a plan gets a fresh subagent with clean context.
+"I'll just keep going" produces context-rotted code.
+Violating this rule is a violation — not efficiency.
+</HARD-GATE>
+
+## The Gate Function
+
+### 1. PREPARE — Assemble Task Context
+
+For each task in the plan:
+- Extract ONLY the files and sections relevant to this specific task
+- Include: task description, verify block, done criteria, relevant code files
+- Exclude: other tasks' context, completed task details, unrelated code
+- Context should be minimal and focused — less is more
+
+### 2. SPAWN — Fresh Agent Per Task
+
+- Create a new subagent with ONLY the task-specific context
+- The subagent receives: task spec, relevant files, codebase conventions, verification recipe
+- The subagent does NOT receive: other tasks, full plan, accumulated session context
+- Each subagent starts with maximum available context window
+
+### 3. EXECUTE — Task Implementation
+
+The subagent follows the standard task protocol:
+1. Read and understand the task requirements
+2. Implement using TDD (if applicable)
+3. Run verification commands
+4. Produce evidence block
+5. Commit with task-specific message
+
+### 4. REVIEW — 2-Stage Review Between Tasks
+
+After each task completes, before starting the next:
+
+**Stage 1 (Spec Review):** Does the implementation match the task's `<done>` criteria exactly?
+**Stage 2 (Code Review):** Does the code meet quality standards?
+
+If either stage fails: the task is not complete. Fix issues before proceeding.
+
+### 5. HANDOFF — Transfer Context to Next Task
+
+- Record what was done (files changed, decisions made)
+- DO NOT carry forward the full implementation context
+- The next subagent starts fresh — it reads the committed code, not the session history
+- Checkpoint the progress in STATE.md
+
+### 6. REPEAT — Next task, fresh agent
+
+## Common Rationalizations — REJECT THESE
+
+| Excuse | Why It Violates the Rule |
+|--------|--------------------------|
+| "I have context from the last task" | That context is rotting. Fresh agent, fresh perspective. |
+| "Spawning agents is overhead" | Context rot costs more than spawn time. The math is clear. |
+| "I can do multiple tasks efficiently" | Efficiency without accuracy is waste. One task, one agent. |
+| "The tasks are related" | Related tasks still get separate agents. Share via committed code, not session state. |
+| "Review between tasks slows things down" | Review catches what rot misses. The slowdown is an investment. |
+
+## Red Flags — STOP If You Catch Yourself:
+
+- Executing multiple tasks in the same agent context
+- Carrying forward accumulated context to the next task
+- Skipping the 2-stage review between tasks
+- Loading the entire plan into a single agent
+- Not checkpointing progress between tasks
+
+**If any red flag triggers: STOP. Checkpoint, spawn fresh agent, continue.**
+
+## Verification Checklist
+
+Before claiming SDD execution is complete:
+
+- [ ] Each task was executed by a separate, fresh subagent
+- [ ] Each subagent received only task-relevant context
+- [ ] 2-stage review ran between every pair of tasks
+- [ ] All review issues were resolved before proceeding
+- [ ] Progress was checkpointed in STATE.md between tasks
+- [ ] No accumulated context was carried forward
+
+## Integration with MAXSIM
+
+### Context Loading
+
+```bash
+node ~/.claude/maxsim/bin/maxsim-tools.cjs skill-context subagent-driven-development
+```
+
+### Task-Based Context Loading (EXEC-03)
+
+The key innovation of SDD is task-based context loading:
+- Each subagent receives only the files/sections relevant to its assignment
+- The orchestrator determines relevant files from the task's file list in the plan
+- Additional context is loaded on-demand if the subagent needs it
+- This prevents context bloat and maximizes each agent's effective context window
+
+### STATE.md Hooks
+
+- Record task start/complete with subagent assignment
+- Checkpoint after each task for resume capability
+- Track inter-task review results
+- Record any deviations from the plan
+
+### In Plan Execution
+
+SDD is the default execution model for MAXSIM plans:
+- The orchestrator reads the plan's task list
+- For each task (or wave of parallel tasks), fresh subagents are spawned
+- Between tasks/waves, 2-stage review runs
+- The orchestrator never executes tasks itself — it only coordinates