codymaster 5.2.0 → 7.0.1

package/skills/cm-engineering-meta/SKILL.archive.md

@@ -0,0 +1,73 @@
+---
+name: cm-engineering-meta
+description: "Use when looking up quick wins, access patterns, or voice map for the engineering meta layer."
+---
+# cm-engineering-meta — quick wins + access + voice map
+
+## Search before building
+
+Before adding infrastructure, search in three layers:
+
+1. **Tried-and-true** — patterns already in this repo / sibling services.
+2. **New-and-popular** — current docs for your stack version.
+3. **First-principles** — only when 1–2 don’t apply.
+
+## AskUserQuestion format
+
+When asking the human to choose:
+
+- Short **context** (what you already know).
+- Clear **question**.
+- **RECOMMENDATION** (one option you’d pick and why).
+- Lettered options **A / B / C** (not vague yes/no).
+
+## Review readiness dashboard (ASCII)
+
+Before ship, print a table:
+
+```
+| Gate        | Status | Notes |
+|-------------|--------|-------|
+| Tests       | ?      |       |
+| Lint/Type   | ?      |       |
+| Secrets     | ?      |       |
+| Manual QA   | ?      |       |
+```
+
+## Completeness gap (code review)
+
+Flag when an **80% solution** is chosen but the **100%** path costs **< 30 minutes** (tests, edge case, docs).
+
+## Investigate Iron Law
+
+- Do **not** patch without a **root cause** hypothesis.
+- After **three** failed fix attempts, stop and question architecture or gather more data.
+
+## Access controls (Goose-style)
+
+- Maintain lists: **autonomous_ok** vs **confirm_required** skill groups (see `.cm/config.example.yaml`).
+- Respect “stop suggesting skill X” in session notes.
+
+## Provider abstraction
+
+Prefer interfaces for LLM calls so **cm-second-opinion** can swap `OPENAI_API_KEY` / future providers without rewriting skills.
+
+## Proactive skill suggestion
+
+Infer stage from files touched and git state:
+
+- Many `test/` edits → suggest **cm-test-gate**.
+- `Dockerfile` / deploy scripts → **cm-safe-deploy** + **cm canary**.
+- `rm` / migration scripts → **cm-guardian** + **cm-secret-shield**.
+
+## Voice-friendly triggers (examples)
+
+| Phrase (approx.) | Skill / command |
+|------------------|-----------------|
+| “Run a security check” | cm-secret-shield / cm-security-gate |
+| “Test the website” | cm browse + cm qa-visual |
+| “Code review this” | cm-code-review |
+| “Deploy safely” | cm-safe-deploy |
+| “Log what went wrong” | `cm retro --note "…"` |
+
+Use Whisper / AquaVoice → paste transcript; map keywords to the table above.

package/skills/cm-engineering-meta/SKILL.md

@@ -1,73 +1,26 @@
 ---
 name: cm-engineering-meta
-description: "Use when looking up quick wins, access patterns, or voice map for the engineering meta layer."
+description: "[Deprecated] engineering bridge merged. Use `cm-mcp-engineering` instead."
+deprecated: true
+merged_into: cm-mcp-engineering
 ---
-# cm-engineering-meta — quick wins + access + voice map
 
-## Search before building
+# cm-engineering-meta — Deprecated
 
-Before adding infrastructure, search in three layers:
+> ⚠️ This skill is deprecated as of CodyMaster v6.0.0 and will be removed in v6.1.0.
+>
+> **Use `cm-mcp-engineering` instead.** engineering bridge merged.
+>
+> See [docs/migration-v2.md](../../docs/migration-v2.md) for the full mapping.
 
-1. **Tried-and-true** — patterns already in this repo / sibling services.
-2. **New-and-popular** — current docs for your stack version.
-3. **First-principles** — only when 1–2 don’t apply.
+The original content is preserved at [SKILL.archive.md](SKILL.archive.md) for reference.
 
-## AskUserQuestion format
+## Migration
 
-When asking the human to choose:
-
-- Short **context** (what you already know).
-- Clear **question**.
-- **RECOMMENDATION** (one option you’d pick and why).
-- Lettered options **A / B / C** (not vague yes/no).
-
-## Review readiness dashboard (ASCII)
-
-Before ship, print a table:
-
-```
-| Gate        | Status | Notes |
-|-------------|--------|-------|
-| Tests       | ?      |       |
-| Lint/Type   | ?      |       |
-| Secrets     | ?      |       |
-| Manual QA   | ?      |       |
+```bash
+# Old:           cm <use this skill>
+# New (v6.0+):   cm mcp-engineering <equivalent action>
 ```
 
-## Completeness gap (code review)
-
-Flag when an **80% solution** is chosen but the **100%** path costs **< 30 minutes** (tests, edge case, docs).
-
-## Investigate Iron Law
-
-- Do **not** patch without a **root cause** hypothesis.
-- After **three** failed fix attempts, stop and question architecture or gather more data.
-
-## Access controls (Goose-style)
-
-- Maintain lists: **autonomous_ok** vs **confirm_required** skill groups (see `.cm/config.example.yaml`).
-- Respect “stop suggesting skill X” in session notes.
-
-## Provider abstraction
-
-Prefer interfaces for LLM calls so **cm-second-opinion** can swap `OPENAI_API_KEY` / future providers without rewriting skills.
-
-## Proactive skill suggestion
-
-Infer stage from files touched and git state:
-
-- Many `test/` edits → suggest **cm-test-gate**.
-- `Dockerfile` / deploy scripts → **cm-safe-deploy** + **cm canary**.
-- `rm` / migration scripts → **cm-guardian** + **cm-secret-shield**.
-
-## Voice-friendly triggers (examples)
-
-| Phrase (approx.) | Skill / command |
-|------------------|-----------------|
-| “Run a security check” | cm-secret-shield / cm-security-gate |
-| “Test the website” | cm browse + cm qa-visual |
-| “Code review this” | cm-code-review |
-| “Deploy safely” | cm-safe-deploy |
-| “Log what went wrong” | `cm retro --note "…"` |
-
-Use Whisper / AquaVoice → paste transcript; map keywords to the table above.
+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-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.