codymaster 4.8.0 → 7.0.0

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-guardian-runtime/SKILL.md

@@ -1,3 +1,7 @@
+---
+name: cm-guardian-runtime
+description: "Use when you need to check if a destructive command is blocked or run guardian freeze checks."
+---
 # cm-guardian-runtime — destructive command & freeze checks
 
 ## Commands
@@ -19,4 +23,4 @@ When using **cm-debugging** or root-cause work, treat **freeze roots** as mandat
 
 ## Config
 
-See `.cm/config.example.yaml` → `guardian:`.
+See `.cm/config.example.yaml` → `guardian:`. Hook patterns (Cursor / Codex): [docs/workflows/guardian-hooks.md](../../docs/workflows/guardian-hooks.md) (repo root).

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-mcp-engineering/SKILL.md

@@ -1,3 +1,7 @@
+---
+name: cm-mcp-engineering
+description: "Use when you need to interact with the MCP engineering bridge tools (cm_plan, cm_review, cm_qa, cm_deploy, cm_search)."
+---
 # cm-mcp-engineering — MCP tools on context server
 
 The same binary as memory MCP (`dist/mcp-context-server.js`) now exposes **engineering bridge** tools:

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.**

package/skills/cm-post-deploy-canary/SKILL.archive.md

@@ -0,0 +1,22 @@
+---
+name: cm-post-deploy-canary
+description: "Use after deployment to run smoke tests and post-deploy canary checks via the browse daemon."
+---
+# cm-post-deploy-canary — smoke + browse tail
+
+## CLI
+
+```bash
+cm canary --url https://app.example.com
+cm canary --url https://app.example.com --browse-port 17395 --token "$CM_BROWSE_TOKEN"
+```
+
+## Flow
+
+1. **HTTP GET** the URL (status < 400).
+2. Optionally pull **browse daemon** `/console` for recent browser errors after deploy.
+
+## Next
+
+- Wire into **cm-safe-deploy** as a final step.
+- Add programmatic CWV (Lighthouse) when you need baselines per PR.

package/skills/cm-post-deploy-canary/SKILL.md

@@ -1,18 +1,26 @@
-# cm-post-deploy-canary — smoke + browse tail
+---
+name: cm-post-deploy-canary
+description: "[Deprecated] quality gate now covers tests + canary. Use `cm-quality-gate` instead."
+deprecated: true
+merged_into: cm-quality-gate
+---
 
-## CLI
+# cm-post-deploy-canary — Deprecated
 
-```bash
-cm canary --url https://app.example.com
-cm canary --url https://app.example.com --browse-port 17395 --token "$CM_BROWSE_TOKEN"
-```
+> ⚠️ This skill is deprecated as of CodyMaster v6.0.0 and will be removed in v6.1.0.
+>
+> **Use `cm-quality-gate` instead.** quality gate now covers tests + canary.
+>
+> See [docs/migration-v2.md](../../docs/migration-v2.md) for the full mapping.
 
-## Flow
+The original content is preserved at [SKILL.archive.md](SKILL.archive.md) for reference.
 
-1. **HTTP GET** the URL (status < 400).
-2. Optionally pull **browse daemon** `/console` for recent browser errors after deploy.
+## Migration
 
-## Next
+```bash
+# Old:           cm <use this skill>
+# New (v6.0+):   cm quality-gate <equivalent action>
+```
 
-- Wire into **cm-safe-deploy** as a final step.
-- Add programmatic CWV (Lighthouse) when you need baselines per PR.
+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-project-bootstrap/SKILL.md

@@ -1318,6 +1318,16 @@ Add this line to the AGENTS.md "Important Rules" section:
 
 ```markdown
 - Read `.cm/CONTINUITY.md` at the start of every session for context
+- Rely on `.cm/project-skills.md` for skill discovery rather than external indexes
+```
+
+### Step 5: Build Local Project Skills Index
+
+Run the CodyMaster CLI indexer to detect the tech stack deterministically and pre-compile the needed community skills without wasting LLM tokens.
+
+```bash
+# This scans package.json/go.mod/etc and outputs to .cm/project-skills.md
+npx cm index skills
 ```
 
 ### Why This Saves Tokens
@@ -1373,4 +1383,5 @@ After bootstrap, the project MUST have:
 ✅ production branch          — Production deploys
 ✅ First commit               — "chore: bootstrap with cm-project-bootstrap v2.0"
 ✅ .cm/CONTINUITY.md           — Working memory for AI context persistence
+✅ .cm/project-skills.md       — Localized token-efficient skill discovery index
 ```

package/skills/cm-qa-visual-cli/SKILL.archive.md

@@ -0,0 +1,22 @@
+---
+name: cm-qa-visual-cli
+description: "Use when you need to take screenshots or run visual QA via the browse daemon CLI."
+---
+# cm-qa-visual-cli — screenshot via browse daemon
+
+## Prerequisites
+
+`cm browse start` running with the same `CM_BROWSE_TOKEN`.
+
+## CLI
+
+```bash
+cm qa-visual --url http://localhost:5173 --port 17395
+```
+
+Writes `cm-qa-visual.png` in the current working directory.
+
+## Next
+
+- Diff against golden images for visual regression.
+- Map `git diff` → affected routes (project-specific heuristics).