codymaster 5.2.0 → 7.0.0

package/skills/cm-execution/SKILL.md

@@ -1,14 +1,38 @@
 ---
 name: cm-execution
 description: "Use when executing implementation plans — choose mode: batch execution with checkpoints, subagent-per-task, or parallel dispatch for independent problems."
+token_budget: 1800
+compressed: true
+deprecated: false
 ---
 
 # Execution — Execute Plans at Scale
 
+## TL;DR
+- **Use when** running an approved plan from cm-planning
+- **Modes**: A=batch, B=subagent-per-task, C=parallel, D=RARV, E=TRIZ-parallel
+- **Reads**: handoff/plan.json — **Writes**: handoff/exec.json
+- **Always**: tests pass before reporting done
+- **Next**: cm-code-review
+
 > **Role: Lead Developer** — You execute implementation plans systematically with quality gates at every checkpoint.
 
 > **Three modes, one skill.** Choose based on task structure.
 
+## Persona Dispatch (Phase 2)
+
+In Mode B (subagent-per-task) and Mode E (TRIZ-parallel), dispatch the right persona from `agents/` based on the task type:
+
+| Task signal | Persona | File |
+|-------------|---------|------|
+| "design", "architecture", "trade-off" | architect | `agents/architect.md` |
+| "implement", "fix", "refactor" | engineer | `agents/engineer.md` |
+| "review", "audit", "verify" | reviewer | `agents/reviewer.md` |
+| "secret", "auth", "input validation", "deploy" | security | `agents/security.md` |
+| "scope", "intent", "user story" | pm | `agents/pm.md` |
+
+When dispatching a subagent, pass `subagent_type: <persona>` (Claude Code agents) or load the persona file as the system prompt for the inner call.
+
 ## Step 0: Load Working Memory (MANDATORY)
 
 Per `_shared/helpers.md#Load-Working-Memory`
@@ -55,6 +79,7 @@ Have a plan with independent tasks?
 | **B: Subagent** | Plan with independent tasks, same session | Fresh subagent per task + 2-stage review |
 | **C: Parallel** | 2+ independent problems | One agent per problem domain |
 | **E: TRIZ-Parallel** ⚡ | 3+ independent tasks, need speed + quality | Dependency-aware parallel dispatch with per-agent quality gates |
+| **F: Party** | One non-trivial task, want multi-perspective without subagent cost | Single agent rotates Architect → Engineer → Reviewer (→ Security), append-only `.cm/handoff/party.json` |
 
 ---
 
@@ -252,6 +277,69 @@ After EVERY phase, you MUST:
 
 ---
 
+## Mode F: Party (Persona Rotation, single agent)
+
+> **One agent, three voices.** Cheaper than Mode B, deeper than Mode A.
+
+### When
+- Task is non-trivial but small enough for one session
+- You want multi-perspective scrutiny without paying for N subagents
+- Quality matters more than raw speed
+
+### Process
+
+```
+1. ARCHITECT  → Load agents/architect.md as voice → propose design / approach
+                → Append round to .cm/handoff/party.json
+2. ENGINEER   → Load agents/engineer.md as voice → implement against the design
+                → Append round
+3. REVIEWER   → Load agents/reviewer.md as voice → critique implementation
+                → verdict: "pass" | "revise" | "block"
+                → Append round
+4. (optional) SECURITY → Load agents/security.md when task touches auth/files/subprocess
+                → Append round
+5. SYNTHESIZE → Write `final` summary; mark handoff emitted_at
+```
+
+### Stop Conditions
+- Reviewer verdict `pass` → done, write `final`
+- Reviewer verdict `revise` → loop back to ENGINEER (max 2 revisions)
+- Reviewer verdict `block` or 3rd revision → escalate to user, do not ship
+
+### Output Contract
+
+Writes to `.cm/handoff/party.json` matching `PartyHandoff` from `src/handoff/contracts.ts`:
+
+```json
+{
+  "schema": "party@1",
+  "emitted_at": "<ISO>",
+  "emitted_by": "cm-execution",
+  "data": {
+    "topic": "<task title>",
+    "rounds": [
+      {"persona":"architect","output":"...","ts":"<ISO>"},
+      {"persona":"engineer","output":"...","ts":"<ISO>"},
+      {"persona":"reviewer","output":"...","verdict":"pass","ts":"<ISO>"}
+    ],
+    "final": "<one-paragraph synthesis>"
+  }
+}
+```
+
+### Rules
+- **Never skip the reviewer round** — that defeats the point of party mode
+- **Never edit a previous round** — append-only, like a journal
+- **One agent the whole way** — do NOT dispatch subagents inside party mode (use Mode B for that)
+- **Persona files are the source of truth** — load them as system context, don't paraphrase
+
+### Common Mistakes
+- ❌ Running architect + engineer in same voice → missed trade-offs
+- ❌ Skipping security persona on auth/file-touching tasks → see Security Rules below
+- ❌ Letting reviewer revise > 2× → that's a planning problem, escalate
+
+---
+
 ## Security Rules (Learned: March 2026)
 
 > **Code that touches files, subprocesses, or the DOM MUST follow these rules. No exceptions.**
@@ -308,6 +396,16 @@ After EVERY phase, you MUST:
 | `/cm-status` | Quick terminal progress summary |
 | `/cm-dashboard` | Open browser dashboard |
 
+## Karpathy Discipline — Surgical Changes
+
+Every executor (single agent or subagent fleet) must follow:
+- **Touch only what the task requires.** No "while I'm here" formatting, renames, or refactors.
+- **Match existing style** even if you'd write it differently. Consistency > taste.
+- **Notice unrelated dead code? Mention it, don't delete.** Out-of-scope cleanup → spawn a separate task.
+- **Clean only your own orphans.** If your edit makes an import/var unused, remove it. Pre-existing dead code stays unless explicitly asked.
+
+**Diff test:** Every changed line should trace to the task. If a reviewer asks "why this line?", you must point at the task — not "felt cleaner".
+
 ## The Bottom Line
 
 **Choose your mode. Execute systematically. Review at every checkpoint.**

package/skills/cm-git-worktrees/SKILL.archive.md

@@ -0,0 +1,157 @@
+---
+name: cm-git-worktrees
+description: Use when starting feature work that needs isolation from current workspace or before executing implementation plans - creates isolated git worktrees with smart directory selection and safety verification
+---
+
+# Using Git Worktrees
+
+## Overview
+
+Git worktrees create isolated workspaces sharing the same repository, allowing work on multiple branches simultaneously without switching.
+
+**Core principle:** Systematic directory selection + safety verification = reliable isolation.
+
+**Announce at start:** "I'm using the cm-git-worktrees skill to set up an isolated workspace."
+
+## Directory Selection Process
+
+Follow this priority order:
+
+### 1. Check Existing Directories
+
+```bash
+# Check in priority order
+ls -d .worktrees 2>/dev/null     # Preferred (hidden)
+ls -d worktrees 2>/dev/null      # Alternative
+```
+
+**If found:** Use that directory. If both exist, `.worktrees` wins.
+
+### 2. Check CLAUDE.md
+
+```bash
+grep -i "worktree.*director" CLAUDE.md 2>/dev/null
+```
+
+**If preference specified:** Use it without asking.
+
+### 3. Ask User
+
+If no directory exists and no CLAUDE.md preference:
+Ask where to create worktrees.
+
+## Safety Verification
+
+### For Project-Local Directories (.worktrees or worktrees)
+
+**MUST verify directory is ignored before creating worktree:**
+
+```bash
+# Check if directory is ignored (respects local, global, and system gitignore)
+git check-ignore -q .worktrees 2>/dev/null || git check-ignore -q worktrees 2>/dev/null
+```
+
+**If NOT ignored:**
+
+Per Jesse's rule "Fix broken things immediately":
+1. Add appropriate line to .gitignore
+2. Commit the change
+3. Proceed with worktree creation
+
+**Why critical:** Prevents accidentally committing worktree contents to repository.
+
+### For Global Directory (~/.config/superpowers/worktrees)
+
+No .gitignore verification needed - outside project entirely.
+
+## Creation Steps
+
+### 1. Detect Project Name
+
+```bash
+project=$(basename "$(git rev-parse --show-toplevel)")
+```
+
+### 2. Create Worktree
+
+```bash
+# Determine full path
+case $LOCATION in
+  .worktrees|worktrees)
+    path="$LOCATION/$BRANCH_NAME"
+    ;;
+  ~/.config/superpowers/worktrees/*)
+    path="~/.config/superpowers/worktrees/$project/$BRANCH_NAME"
+    ;;
+esac
+
+# Create worktree with new branch
+git worktree add "$path" -b "$BRANCH_NAME"
+cd "$path"
+```
+
+### 3. Run Project Setup
+
+Auto-detect and run appropriate setup:
+
+```bash
+# Node.js
+if [ -f package.json ]; then npm install; fi
+# Rust
+if [ -f Cargo.toml ]; then cargo build; fi
+```
+
+### 4. Verify Clean Baseline
+
+Run tests to ensure worktree starts clean (via `cm-quality-gate` conventions).
+
+## Quick Reference
+
+| Situation | Action |
+|-----------|--------|
+| `.worktrees/` exists | Use it (verify ignored) |
+| `worktrees/` exists | Use it (verify ignored) |
+| Both exist | Use `.worktrees/` |
+| Neither exists | Check CLAUDE.md → Ask user |
+| Directory not ignored | Add to .gitignore + commit |
+| Tests fail during baseline | Report failures + ask |
+
+## Common Mistakes
+
+### Skipping ignore verification
+
+- **Problem:** Worktree contents get tracked, pollute git status
+- **Fix:** Always use `git check-ignore` before creating project-local worktree
+
+### Assuming directory location
+
+- **Problem:** Creates inconsistency, violates project conventions
+- **Fix:** Follow priority: existing > CLAUDE.md > ask
+
+### Proceeding with failing tests
+
+- **Problem:** Can't distinguish new bugs from pre-existing issues
+- **Fix:** Report failures, get explicit permission to proceed
+
+## Red Flags
+
+**Never:**
+- Create worktree without verifying it's ignored (project-local)
+- Skip baseline test verification
+- Proceed with failing tests without asking
+- Assume directory location when ambiguous
+
+**Always:**
+- Follow directory priority: existing > CLAUDE.md > ask
+- Verify directory is ignored for project-local
+- Auto-detect and run project setup
+- Verify clean test baseline
+
+## Integration
+
+**Called by:**
+- **cm-planning** - REQUIRED when design is approved and implementation follows
+- **cm-execution** - REQUIRED before executing any tasks
+
+**Pairs with:**
+- **cm-code-review** - For cleanup after work complete

package/skills/cm-git-worktrees/SKILL.md

@@ -1,157 +1,26 @@
 ---
 name: cm-git-worktrees
-description: Use when starting feature work that needs isolation from current workspace or before executing implementation plans - creates isolated git worktrees with smart directory selection and safety verification
+description: "[Deprecated] worktree management is part of execution. Use `cm-execution` instead."
+deprecated: true
+merged_into: cm-execution
 ---
 
-# Using Git Worktrees
+# cm-git-worktrees — Deprecated
 
-## Overview
+> ⚠️ This skill is deprecated as of CodyMaster v6.0.0 and will be removed in v6.1.0.
+>
+> **Use `cm-execution` instead.** worktree management is part of execution.
+>
+> See [docs/migration-v2.md](../../docs/migration-v2.md) for the full mapping.
 
-Git worktrees create isolated workspaces sharing the same repository, allowing work on multiple branches simultaneously without switching.
+The original content is preserved at [SKILL.archive.md](SKILL.archive.md) for reference.
 
-**Core principle:** Systematic directory selection + safety verification = reliable isolation.
-
-**Announce at start:** "I'm using the cm-git-worktrees skill to set up an isolated workspace."
-
-## Directory Selection Process
-
-Follow this priority order:
-
-### 1. Check Existing Directories
-
-```bash
-# Check in priority order
-ls -d .worktrees 2>/dev/null     # Preferred (hidden)
-ls -d worktrees 2>/dev/null      # Alternative
-```
-
-**If found:** Use that directory. If both exist, `.worktrees` wins.
-
-### 2. Check CLAUDE.md
-
-```bash
-grep -i "worktree.*director" CLAUDE.md 2>/dev/null
-```
-
-**If preference specified:** Use it without asking.
-
-### 3. Ask User
-
-If no directory exists and no CLAUDE.md preference:
-Ask where to create worktrees.
-
-## Safety Verification
-
-### For Project-Local Directories (.worktrees or worktrees)
-
-**MUST verify directory is ignored before creating worktree:**
-
-```bash
-# Check if directory is ignored (respects local, global, and system gitignore)
-git check-ignore -q .worktrees 2>/dev/null || git check-ignore -q worktrees 2>/dev/null
-```
-
-**If NOT ignored:**
-
-Per Jesse's rule "Fix broken things immediately":
-1. Add appropriate line to .gitignore
-2. Commit the change
-3. Proceed with worktree creation
-
-**Why critical:** Prevents accidentally committing worktree contents to repository.
-
-### For Global Directory (~/.config/superpowers/worktrees)
-
-No .gitignore verification needed - outside project entirely.
-
-## Creation Steps
-
-### 1. Detect Project Name
-
-```bash
-project=$(basename "$(git rev-parse --show-toplevel)")
-```
-
-### 2. Create Worktree
-
-```bash
-# Determine full path
-case $LOCATION in
-  .worktrees|worktrees)
-    path="$LOCATION/$BRANCH_NAME"
-    ;;
-  ~/.config/superpowers/worktrees/*)
-    path="~/.config/superpowers/worktrees/$project/$BRANCH_NAME"
-    ;;
-esac
-
-# Create worktree with new branch
-git worktree add "$path" -b "$BRANCH_NAME"
-cd "$path"
-```
-
-### 3. Run Project Setup
-
-Auto-detect and run appropriate setup:
+## Migration
 
 ```bash
-# Node.js
-if [ -f package.json ]; then npm install; fi
-# Rust
-if [ -f Cargo.toml ]; then cargo build; fi
+# Old:           cm <use this skill>
+# New (v6.0+):   cm execution <equivalent action>
 ```
 
-### 4. Verify Clean Baseline
-
-Run tests to ensure worktree starts clean (via `cm-quality-gate` conventions).
-
-## Quick Reference
-
-| Situation | Action |
-|-----------|--------|
-| `.worktrees/` exists | Use it (verify ignored) |
-| `worktrees/` exists | Use it (verify ignored) |
-| Both exist | Use `.worktrees/` |
-| Neither exists | Check CLAUDE.md → Ask user |
-| Directory not ignored | Add to .gitignore + commit |
-| Tests fail during baseline | Report failures + ask |
-
-## Common Mistakes
-
-### Skipping ignore verification
-
-- **Problem:** Worktree contents get tracked, pollute git status
-- **Fix:** Always use `git check-ignore` before creating project-local worktree
-
-### Assuming directory location
-
-- **Problem:** Creates inconsistency, violates project conventions
-- **Fix:** Follow priority: existing > CLAUDE.md > ask
-
-### Proceeding with failing tests
-
-- **Problem:** Can't distinguish new bugs from pre-existing issues
-- **Fix:** Report failures, get explicit permission to proceed
-
-## Red Flags
-
-**Never:**
-- Create worktree without verifying it's ignored (project-local)
-- Skip baseline test verification
-- Proceed with failing tests without asking
-- Assume directory location when ambiguous
-
-**Always:**
-- Follow directory priority: existing > CLAUDE.md > ask
-- Verify directory is ignored for project-local
-- Auto-detect and run project setup
-- Verify clean test baseline
-
-## Integration
-
-**Called by:**
-- **cm-planning** - REQUIRED when design is approved and implementation follows
-- **cm-execution** - REQUIRED before executing any tasks
-
-**Pairs with:**
-- **cm-code-review** - For cleanup after work complete
+If you depend on a capability that didn't carry over, please file an issue:
+https://github.com/tody-agent/codymaster/issues

package/skills/cm-identity-guard/SKILL.md

@@ -1,10 +1,18 @@
 ---
 name: cm-identity-guard
 description: Verify and lock project identity before ANY git push, Cloudflare deploy, or Supabase operation. Essential when working with multiple GitHub accounts (personal + work), multiple Cloudflare accounts, or multiple Supabase/Neon projects. Prevents wrong-account deploys, cross-project secret leaks, and git history contamination.
+token_budget: 800
+compressed: true
+deprecated: false
 ---
 
 # Identity Guard — Multi-Account Safety Protocol
 
+## TL;DR
+- **Use before** any git push, Cloudflare deploy, or Supabase op
+- **Verifies**: GitHub account, CF account, Supabase project match expected
+- **Prevents**: wrong-account deploys, cross-project secret leaks
+
 ## Overview
 
 Working across multiple projects, clients, and platforms means one wrong `git push` or `wrangler deploy` can publish work to the wrong account. This skill establishes a mandatory identity check before any operation that touches external services.

package/skills/cm-planning/SKILL.md

@@ -1,134 +1,105 @@
 ---
 name: cm-planning
 description: "You MUST use this before any creative work or multi-step task. Explores intent, requirements, and design before implementation. Then documents the plan before coding."
+token_budget: 1500
+compressed: true
+deprecated: false
 ---
 
 # Planning — Brainstorm + Write Plans
 
-> **Two phases, one skill:** Explore WHAT to build, then document HOW.
+## TL;DR
+- **Use before** any feature, behavior change, or 3+ step task
+- **Phase A (Brainstorm)**: clarify intent → 2-3 options → recommend → scope
+- **Phase B (Write)**: emit `openspec/changes/<name>/{design.md,tasks.md}`
+- **Handoff out**: `.cm/handoff/plan.json` (goal, decisions, first 3 tasks)
+- **Next**: `cm-tdd` or `cm-execution`
 
 ## When to Use
-
-**ALWAYS before:**
 - Creating features, components, or functionality
-- Modifying behavior
-- Multi-step tasks
-- Any work that changes user-facing behavior
-
-## Phase A: Brainstorm (Explore Intent)
-
-### The Process
-
-1. **Understand Intent** — What does the user ACTUALLY want?
-   - Ask clarifying questions
-   - Don't assume scope
-   - Identify hidden requirements
-
-2. **Explore Options** — What are the approaches?
-   - List 2-3 possible approaches
-   - Pros/cons of each
-   - Recommend one with reasoning
-
-3. **Define Scope** — What's in and what's out?
-   - Must-haves vs nice-to-haves
-   - Edge cases to handle
-   - Edge cases to explicitly NOT handle
-   - **Output to:** `openspec/changes/[initiative-name]/specs/`
+- Modifying behavior; multi-step tasks; user-visible change
+- Skip only for trivial single-line edits or pure questions
 
-4. **Design** — How should it work?
-   - Data flow
-   - Component boundaries
-   - API contracts (if applicable)
-   - **If building UI:** Use `cm-ui-preview` to preview on Google Stitch before coding
+## Full Protocol
 
-### Red Flags — STOP
+### Phase A: Brainstorm
 
-- Starting code before brainstorming
-- Assuming you know what the user wants
-- Skipping scope definition
-- "It's simple, no need to plan"
+1. **Intent** — Ask clarifying questions. Don't assume scope. Surface hidden requirements.
+2. **Options** — List 2-3 approaches with pros/cons. Recommend one with reasoning.
+3. **Scope** — Must-have vs nice-to-have; edges to handle vs explicitly skip.
+4. **Design** — Data flow, component boundaries, API contracts. UI work → `cm-ui-preview`.
 
-## Phase B: Write Implementation Plan (OpenSpec Format)
+**Red flags (STOP)**: code before brainstorm; assuming intent; skipping scope; "it's simple."
 
-> **Standard:** Fission-AI OpenSpec (`https://github.com/Fission-AI/OpenSpec/`)
-> Output artifacts exactly to `openspec/changes/[initiative-name]/` to ensure human/AI alignment.
+### Phase B: Write Plan (OpenSpec format)
 
-### When to Write a Plan
+Write to `openspec/changes/<initiative-name>/`:
 
-- Task has 3+ steps
-- Multiple files involved
-- Changes affect other components
-- User explicitly asks for a plan
-
-### OpenSpec Artifacts to Generate
-
-**1. `openspec/changes/[initiative-name]/design.md`**
+`design.md`
 ```markdown
 # Design: [Goal]
-
 ## Context & Technical Approach
-Why this approach and how it works.
-
 ## Proposed Changes
 ### [Component/File]
-- What changes
-- Why this approach
-
 ## Verification
-How to verify it works.
 ```
 
-**2. `openspec/changes/[initiative-name]/tasks.md`**
+`tasks.md`
 ```markdown
 # Implementation Checklist
-- [ ] 1.1 First component setup
-- [ ] 1.2 First component logic
-- [ ] 2.1 Next component integration
+- [ ] 1.1 ...
+- [ ] 1.2 ...
 - [ ] Verification testing
 ```
 
-### Plan Rules
+**Plan rules**: small testable steps (15-30 min each), order by dependency, verification per step. No vague steps.
 
-```
-✅ DO:
-- Break into small, testable steps
-- Order by dependency (foundations first)
-- Include verification for each step
-- Keep steps bite-sized (15-30 min each)
-
-❌ DON'T:
-- Write vague steps ("refactor the code")
-- Skip verification steps
-- Plan more than needed
-- Over-engineer the plan itself
-```
-
-### Step FINAL: Update Working Memory
+### Step FINAL: Emit Handoff + Update Continuity
 
-After writing an implementation plan, ALWAYS update `.cm/CONTINUITY.md`:
-
-```
-- Active Goal:    → Set to the plan's #Goal
-- Next Actions:   → Set to first 3 tasks from the plan
-- Current Phase:  → Set to "planning"
-- Working Context: → Key architecture decisions from the plan
+Write `.cm/handoff/plan.json`:
+```json
+{
+  "schema": "plan@1",
+  "goal": "...",
+  "decisions": ["..."],
+  "first_tasks": ["1.1", "1.2", "1.3"],
+  "openspec_path": "openspec/changes/<name>/"
+}
 ```
 
-> **Token savings:** Next session picks up from CONTINUITY.md (~200 tokens)
-> instead of re-reading the full plan (2,000+ tokens).
+Update `.cm/CONTINUITY.md`:
+- Active Goal → plan goal
+- Next Actions → first 3 tasks
+- Current Phase → "planning"
+- Working Context → key decisions
 
----
+> Token win: next session reads CONTINUITY (~200 tok) instead of full plan (2000+).
 
 ## Integration
 
 | After planning... | Use skill |
-|-------------------|-----------|
-| Complex initiative/enhancement? | `cm-brainstorm-idea` (run BEFORE planning) |
+|---|---|
+| Complex initiative | `cm-brainstorm-idea` (run BEFORE) |
 | Need isolated workspace | `cm-git-worktrees` |
-| Execute the plan (same session) | `cm-execution` |
-| Write tests first | `cm-tdd` |
-| Building UI/frontend | `cm-ui-preview` |
+| Execute the plan | `cm-execution` |
+| Tests first | `cm-tdd` |
+| UI/frontend | `cm-ui-preview` |
 
-## The Bottom Line
+## Karpathy Discipline — Think Before Coding
+
+Before writing the plan, surface what's uncertain instead of guessing:
+- **State assumptions explicitly.** List them in the plan; mark each as "verified" or "needs confirmation".
+- **Multiple interpretations?** Present them side-by-side with tradeoffs. Don't pick silently.
+- **Simpler path exists?** Say so. Push back on over-scoped requests.
+- **Confused?** Stop. Name the confusion. Ask. Cheaper than building the wrong thing.
+
+**Self-test:** "Could a reviewer point to anything in this plan I'm guessing about?" If yes, mark it.
 
-**Think before you build. Document before you code. No exceptions.**
+## Anti-Patterns
+- ❌ Coding before plan exists
+- ❌ Skipping handoff JSON (downstream skills lose context)
+- ❌ Vague tasks ("refactor the code")
+- ❌ Hidden assumptions — pick one interpretation without telling the user
+
+## The Bottom Line
+**Think before you build. Document before you code. Emit handoff so the next skill picks up cold.**