codymaster 5.2.0 → 7.0.1

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,22 +1,26 @@
 ---
 name: cm-post-deploy-canary
-description: "Use after deployment to run smoke tests and post-deploy canary checks via the browse daemon."
+description: "[Deprecated] quality gate now covers tests + canary. Use `cm-quality-gate` instead."
+deprecated: true
+merged_into: cm-quality-gate
 ---
-# cm-post-deploy-canary — smoke + browse tail
 
-## 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-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).

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

@@ -1,22 +1,26 @@
 ---
 name: cm-qa-visual-cli
-description: "Use when you need to take screenshots or run visual QA via the browse daemon CLI."
+description: "[Deprecated] browser daemon overlap. Use `cm-browse` instead."
+deprecated: true
+merged_into: cm-browse
 ---
-# cm-qa-visual-cli — screenshot via browse daemon
 
-## Prerequisites
+# cm-qa-visual-cli — Deprecated
 
-`cm browse start` running with the same `CM_BROWSE_TOKEN`.
+> ⚠️ This skill is deprecated as of CodyMaster v6.0.0 and will be removed in v6.1.0.
+>
+> **Use `cm-browse` instead.** browser daemon overlap.
+>
+> See [docs/migration-v2.md](../../docs/migration-v2.md) for the full mapping.
 
-## CLI
+The original content is preserved at [SKILL.archive.md](SKILL.archive.md) for reference.
+
+## Migration
 
 ```bash
-cm qa-visual --url http://localhost:5173 --port 17395
+# Old:           cm <use this skill>
+# New (v6.0+):   cm browse <equivalent action>
 ```
 
-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).
+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-quality-gate/SKILL.md

@@ -1,10 +1,20 @@
 ---
 name: cm-quality-gate
 description: "Use before any deployment or completion claim. Enforces test gates, evidence-based verification, and frontend safety checks. No deploy without passing. No claims without evidence."
+token_budget: 1800
+compressed: true
+deprecated: false
 ---
 
 # Quality Gate — Test + Verify + Ship Safe
 
+## TL;DR
+- **Use before** any deployment or completion claim
+- **Gates**: tests pass, no secrets, frontend safety, evidence logged
+- **Reads**: handoff/exec.json — **Writes**: handoff/quality.json
+- **Modes**: OFF | WARNING (default) | SOFT | FULL
+- **Vibecoding score**: 0..100 (Phase 2)
+
 > **Three checkpoints, one skill:** Pre-deploy testing, evidence verification, frontend safety.
 
 ## The Iron Laws
@@ -197,6 +207,34 @@ After ANY gate fails, **FIRST run Memory Integrity Check:**
 | Security scan passes | `snyk test && aikido-api-client scan-release ...` | ✅ For production / public releases |
 | i18n parity | Included in test:gate | ✅ If multilingual |
 
+## Vibecoding Index (Phase 2)
+
+After all gates pass, compute a 0–100 score for the change:
+
+```bash
+cm quality score --mode WARNING
+```
+
+Components (each weighted): **intent 30%, ownership 25%, context 20%, tests 15%, review 10%**.
+Inputs are derived automatically from `.cm/handoff/{plan,exec,review,quality}.json` when present, or can be overridden with `--intent <0..1>`, `--ownership <0..1>`, etc.
+
+Modes:
+- `OFF` — silent (LITE projects)
+- `WARNING` — print + advise (default; STANDARD projects)
+- `SOFT` — warn loudly under 60 (PROFESSIONAL projects)
+- `FULL` — exit 1 under 70 (ENTERPRISE projects, blocks deploy)
+
+The default mode follows the project tier from `cm tier classify`.
+
+## Karpathy Discipline — Loop Until Verified
+
+The gate is where "goal-driven execution" actually closes the loop:
+- **No claim without evidence.** "Tests pass" → paste the run. "Build green" → paste the hash. "Feature works" → paste the screenshot or HTTP response.
+- **Loop independently while verifiable.** If the success criterion is concrete (test green, status 200, screenshot diff < threshold), keep iterating without asking. If criterion is vague, stop and ask — don't burn cycles on guesses.
+- **Verify don't trust.** A subagent's summary says what it intended, not what it did. Re-run the gate yourself.
+
+**Gate principle:** weak criteria fail here, not in production. Reject "make it work" handoffs back to planning.
+
 ## The Bottom Line
 
 **Test before deploy. Scan before release. Evidence before claims. Safety before shipping. Non-negotiable.**

package/skills/cm-safe-deploy/SKILL.md

@@ -1,10 +1,19 @@
 ---
 name: cm-safe-deploy
 description: Use when setting up deployment infrastructure for any project - establishes multi-gate deploy pipeline with test gates, build verification, frontend safety checks, and rollback strategy before code reaches production
+token_budget: 1500
+compressed: true
+deprecated: false
 ---
 
 # Safe Deploy Pipeline v2
 
+## TL;DR
+- **Use before/during** deploying to staging or production
+- **Multi-gate**: secrets, build, stage, smoke, prod, rollback plan
+- **Identity**: verifies correct GitHub/Cloudflare/Supabase account
+- **Next**: cm-quality-gate (post-deploy)
+
 ## Overview
 
 A deploy without gates is a deploy with hope. Hope is not a strategy.

package/skills/cm-second-opinion-cli/SKILL.archive.md

@@ -0,0 +1,23 @@
+---
+name: cm-second-opinion-cli
+description: "Use when you need a cross-model review or second opinion on a diff or code change."
+---
+# cm-second-opinion-cli — cross-model review stub
+
+## CLI
+
+```bash
+cm second-opinion --file /tmp/my.diff
+```
+
+- With `OPENAI_API_KEY`, calls **OpenAI chat completions** (`CM_SECOND_OPINION_MODEL` optional, default `gpt-4o-mini`).
+- Without key, prints a **stub** reminder (no network).
+
+## Safety
+
+- **Never** paste secrets or production credentials into the diff file.
+- Prefer unified diffs of **application code** only.
+
+## Roadmap
+
+Add Anthropic / Google / Ollama providers via shared provider interface (see **cm-engineering-meta**).

package/skills/cm-second-opinion-cli/SKILL.md

@@ -1,23 +1,26 @@
 ---
 name: cm-second-opinion-cli
-description: "Use when you need a cross-model review or second opinion on a diff or code change."
+description: "[Deprecated] engineering bridge merged. Use `cm-mcp-engineering` instead."
+deprecated: true
+merged_into: cm-mcp-engineering
 ---
-# cm-second-opinion-cli — cross-model review stub
 
-## CLI
+# cm-second-opinion-cli — Deprecated
 
-```bash
-cm second-opinion --file /tmp/my.diff
-```
-
-- With `OPENAI_API_KEY`, calls **OpenAI chat completions** (`CM_SECOND_OPINION_MODEL` optional, default `gpt-4o-mini`).
-- Without key, prints a **stub** reminder (no network).
+> ⚠️ 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.
 
-## Safety
+The original content is preserved at [SKILL.archive.md](SKILL.archive.md) for reference.
 
-- **Never** paste secrets or production credentials into the diff file.
-- Prefer unified diffs of **application code** only.
+## Migration
 
-## Roadmap
+```bash
+# Old:           cm <use this skill>
+# New (v6.0+):   cm mcp-engineering <equivalent action>
+```
 
-Add Anthropic / Google / Ollama providers via shared provider interface (see **cm-engineering-meta**).
+If you depend on a capability that didn't carry over, please file an issue:
+https://github.com/tody-agent/codymaster/issues