codymaster 4.1.0

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

@@ -0,0 +1,412 @@
+---
+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.
+---
+
+# Identity Guard — Multi-Account Safety Protocol
+
+## 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.
+
+> [!CAUTION]
+> **Real incidents this skill prevents:**
+> - Pushed client code to personal GitHub repo
+> - Deployed to wrong Cloudflare account (different org's Pages project, billing confusion)
+> - Used personal Supabase `ANON_KEY` in a client project (wrong DB entirely)
+> - `git config user.email` was personal email → commits show wrong author in client repo
+
+## The Iron Law
+
+```
+NEVER push, deploy, or use secrets WITHOUT verifying identity first.
+ASK: Which account? Which project? Which database?
+ONE command verifies all three. Run it. Always.
+```
+
+## When to Use
+
+**ALWAYS** before:
+- `git push` or `git commit` in a project with multiple account contexts
+- `wrangler pages deploy` or any Cloudflare operation
+- Creating or accessing a Supabase/Neon client
+- Setting up a new project from scratch
+- Resuming work after switching between personal and work projects
+
+---
+
+## Account Registry (Your Known Accounts)
+
+Maintain this table in your head (or in `.project-identity.json`):
+
+### GitHub Accounts
+
+| Account | Purpose | Email | When to Use |
+|---------|---------|-------|-------------|
+| `my-personal` | Personal projects, experiments | personal email | Personal repos, side projects |
+| `my-work-org` | Client work | `dev@workdomain.com` | All client projects |
+
+### Cloudflare Accounts
+
+| Account ID | Purpose | Projects |
+|-----------|---------|---------|
+| `abc123def456ghi789jkl012mno345pqr` | Client A / Org | project-1, project-2, app |
+| (personal) | Personal experiments | personal side projects |
+
+### Database Accounts
+
+| Service | Account | Purpose |
+|---------|---------|---------|
+| Supabase (Org) | org account | All Client A apps |
+| Supabase (personal) | personal account | Experiments |
+| Neon | per project | If used |
+
+---
+
+## Phase 0: Project Identity File
+
+Every project MUST have a `.project-identity.json` in the project root:
+
+```json
+{
+  "name": "my-awesome-project",
+  "description": "An awesome internal tool",
+  "github": {
+    "account": "my-work-org",
+    "org": "my-work-org",
+    "repo": "my_project_repo",
+    "remoteUrl": "https://github.com/my-work-org/my_project_repo.git",
+    "userEmail": "dev@workdomain.com"
+  },
+  "cloudflare": {
+    "accountId": "abc123def456ghi789jkl012mno345pqr",
+    "projectName": "my-frontend-app",
+    "stagingUrl": "https://my-app-staging.pages.dev",
+    "productionUrl": "https://myapp.workdomain.com",
+    "productionBranch": "production"
+  },
+  "database": {
+    "provider": "supabase",
+    "projectName": "my-database-project",
+    "urlVar": "SUPABASE_URL",
+    "anonKeyVar": "SUPABASE_ANON_KEY",
+    "serviceKeyVar": "SUPABASE_SERVICE_KEY",
+    "secretsStore": "cloudflare-secrets"
+  },
+  "i18n": {
+    "primary": "vi",
+    "languages": ["vi", "en", "th", "ph"],
+    "dir": "public/static/i18n"
+  }
+}
+```
+
+> [!IMPORTANT]
+> Add `.project-identity.json` to git but NEVER put actual secrets in it — only variable NAMES and account IDs. Secrets live in `.dev.vars` (local) or Cloudflare Secrets (production).
+
+---
+
+## Phase 1: Identity Verification
+
+### The One-Liner Check
+
+Run this before any push or deploy:
+
+```bash
+# Full identity check — GitHub + Git user + CF account + DB config
+echo "=== GitHub CLI ===" && gh auth status 2>&1 | grep -E "Logged in|github.com" && \
+echo "=== Git Remote ===" && git remote get-url origin && \
+echo "=== Git User ===" && git config user.name && git config user.email && \
+echo "=== Cloudflare ===" && cat wrangler.jsonc | grep -E "account_id|project|name" | head -5 && \
+echo "=== DB Config ===" && cat .dev.vars 2>/dev/null | grep -E "URL|SUPABASE" | sed 's/=.*/=***/' && \
+echo "=== Expected ===" && cat .project-identity.json 2>/dev/null | python3 -c "import sys,json; d=json.load(sys.stdin); print('GitHub:', d['github']['account'], '| CF:', d['cloudflare']['accountId'][:8]+'...', '| DB:', d['database']['provider'])"
+```
+
+### What to Verify (Checklist)
+
+```
+☐ GitHub CLI: logged in as <EXPECTED ACCOUNT>
+☐ git remote origin: points to <EXPECTED REPO URL>
+☐ git config user.email: matches <EXPECTED EMAIL>
+☐ wrangler.jsonc: account_id matches <EXPECTED CF ACCOUNT ID>
+☐ .dev.vars: SUPABASE_URL points to <EXPECTED SUPABASE PROJECT>
+```
+
+---
+
+## Phase 2: Fix Wrong Identity
+
+### Wrong GitHub Account
+
+```bash
+# Check current
+gh auth status
+
+# Switch to work account
+gh auth logout
+gh auth login
+# → Login with web browser → select my-work-org
+
+# Fix git user for THIS repo (not global)
+git config user.name "my-work-org"
+git config user.email "dev@workdomain.com"
+
+# Fix remote URL
+git remote set-url origin https://github.com/my-work-org/REPO_NAME.git
+```
+
+### Wrong Cloudflare Account
+
+```bash
+# Check current CF account
+wrangler whoami
+
+# Look for account_id in wrangler.jsonc
+grep account_id wrangler.jsonc
+
+# Expected for Your Project: abc123def456ghi789jkl012mno345pqr
+# Fix: update account_id in wrangler.jsonc
+```
+
+### Wrong Supabase Project
+
+```bash
+# Check which Supabase URL is in .dev.vars
+grep SUPABASE_URL .dev.vars
+
+# The URL pattern reveals the project: https://<PROJECT_ID>.supabase.co
+# Compare with the project in .project-identity.json
+
+# Fix: update .dev.vars with correct values
+# Then restart wrangler dev
+```
+
+### Wrong git author on recent commits
+
+```bash
+# See who authored the last few commits
+git log --format="%h %an <%ae>" -5
+
+# If wrong — amend last commit's author (before push only!)
+git commit --amend --author="my-work-org <dev@workdomain.com>" --no-edit
+
+# For multiple commits: rebase and re-author
+git rebase -i HEAD~N  # Then for each commit: edit → amend author → continue
+```
+
+---
+
+## Phase 3: Project Setup (New Projects)
+
+When starting a new project, answer these questions FIRST:
+
+```markdown
+Before writing any code or creating any repo, I need to lock identity:
+
+1. **GitHub account**: Personal (my-personal) or Work (my-work-org)?
+2. **Cloudflare account**: Which account ID?
+3. **Database**: Which Supabase org? New project or existing?
+4. **Languages**: Single locale or multi-language from day 1?
+   → If multi-language: list all target languages now
+```
+
+Then create `.project-identity.json` BEFORE the first commit:
+
+```bash
+# Lock git identity to this project immediately
+git config user.name "my-work-org"
+git config user.email "dev@workdomain.com"
+git remote set-url origin https://github.com/my-work-org/NEW_REPO.git
+
+# Verify before first push
+git config user.email  # Must match expected
+git remote get-url origin  # Must match expected
+gh auth status  # Must show correct account
+```
+
+#### Record Identity Decision (cm-continuity)
+
+After locking identity for a new project, write to `.cm/memory/decisions.json`:
+- `decision`: "GitHub identity locked to [account], CF account [id], DB: [provider/project]"
+- `rationale`: "Multi-account safety — prevents wrong-account deploys"
+- `scope`: `global`
+- `status`: `active`
+
+Also update `.cm/CONTINUITY.md` Working Context with the locked identity.
+
+---
+
+## Phase 4: Multi-Account Git Setup (OS Level)
+
+### Using SSH Keys per Account
+
+```bash
+# Generate separate keys for each account
+ssh-keygen -t ed25519 -C "dev@workdomain.com" -f ~/.ssh/id_my_work_org
+ssh-keygen -t ed25519 -C "personal@..." -f ~/.ssh/id_personal
+
+# ~/.ssh/config — route by host alias
+Host github-work
+  HostName github.com
+  User git
+  IdentityFile ~/.ssh/id_my_work_org
+
+Host github-personal
+  HostName github.com
+  User git
+  IdentityFile ~/.ssh/id_personal
+```
+
+### Using SSH, reference by alias in project:
+
+```bash
+# For work projects:
+git remote set-url origin git@github-work:my-work-org/REPO.git
+
+# For personal projects:
+git remote set-url origin git@github-personal:my-personal/REPO.git
+```
+
+### Global vs Local git config
+
+```bash
+# Global: personal (default for new repos)
+git config --global user.name "my-personal"
+git config --global user.email "personal@email.com"
+
+# Per-repo override for work projects (run inside each work repo):
+git config user.name "my-work-org"
+git config user.email "dev@workdomain.com"
+```
+
+> [!TIP]
+> Use `includeIf` in `~/.gitconfig` to auto-apply work identity for repos in specific directories:
+> ```ini
+> [includeIf "gitdir:~/Builder/ClientA/"]
+>     path = ~/.gitconfig-work
+> ```
+> `~/.gitconfig-work`:
+> ```ini
+> [user]
+>     name = my-work-org
+>     email = dev@workdomain.com
+> ```
+
+---
+
+## Phase 5: Token Lifecycle Management 🔄
+
+> **NEW — Secrets don't just need to be hidden. They need to be ROTATED.**
+> **Full rotation playbooks in `cm-secret-shield` Layer 5.**
+
+### Rotation Schedule
+
+| Platform | Token Type | Max Lifetime | Where to Rotate |
+|----------|-----------|-------------|----------------|
+| **Supabase** | `anon_key` | 90 days | Dashboard → Settings → API |
+| **Supabase** | `service_role_key` | 30 days | Dashboard → Settings → API |
+| **Cloudflare** | API Token | 90 days | Dashboard → My Profile → API Tokens |
+| **GitHub** | Personal Access Token | 90 days | Settings → Developer Settings → PAT |
+| **OpenAI/Gemini** | API Key | 90 days | Platform dashboard |
+
+### After Rotation
+
+```bash
+# 1. Update Cloudflare Secrets with new values
+wrangler secret put SUPABASE_ANON_KEY
+wrangler secret put SUPABASE_SERVICE_KEY
+
+# 2. Update local .dev.vars
+# 3. Redeploy
+npm run deploy:staging
+
+# 4. Verify: test staging URL
+```
+
+> For emergency rotation (leaked secret), see `cm-secret-shield` Emergency Rotation Playbook.
+
+---
+
+## Red Flags — Identity Confusion
+
+```
+❌ git push and see "Repository not found" or "Permission denied"
+   → Wrong account. Run identity check.
+
+❌ wrangler deploy succeeded but can't find it in your CF dashboard
+   → Deployed to wrong CF account. Check wrangler.jsonc account_id.
+
+❌ Authentication fails with correct password
+   → `gh auth status` shows wrong account. Logout and login to correct one.
+
+❌ Production app shows the wrong data / can't connect to DB
+   → Wrong SUPABASE_URL or key. Check Cloudflare Secrets for the project.
+
+❌ git log shows wrong author email on commits
+   → git config user.email is wrong. Fix and amend before pushing.
+
+❌ New repo was created under wrong GitHub org
+   → Delete and recreate under correct org, then update remote URL.
+```
+
+---
+
+## Recovery Playbook
+
+### "I pushed to the wrong GitHub repo"
+
+```bash
+# 1. Delete the push (if repo is private, remove sensitive data)
+git push origin --delete <branch>  # Remove the branch
+
+# 2. If sensitive data was exposed: contact GitHub support immediately
+#    Also rotate any secrets that appeared in the code
+
+# 3. Push to the correct repo:
+git remote set-url origin https://github.com/CORRECT_ORG/CORRECT_REPO.git
+git push origin <branch>
+```
+
+### "I deployed to the wrong Cloudflare account"
+
+```bash
+# 1. Log into correct CF account
+# 2. Deploy immediately to overwrite:
+CLOUDFLARE_ACCOUNT_ID=<CORRECT_ID> wrangler pages deploy dist --project-name <CORRECT_PROJECT>
+
+# 3. Go to WRONG account's CF dashboard and delete the project or rollback deployment
+```
+
+### "I used wrong Supabase keys in production"
+
+```bash
+# 1. Update Cloudflare Secrets with correct values:
+wrangler secret put SUPABASE_URL           # Enter correct URL
+wrangler secret put SUPABASE_SERVICE_KEY   # Enter correct key
+wrangler secret put SUPABASE_ANON_KEY      # Enter correct key
+
+# 2. Redeploy to pick up new secrets
+npm run deploy
+
+# 3. Rotate the accidentally exposed keys in Supabase dashboard
+```
+
+---
+
+## Integration with Other Skills
+
+| Skill | When |
+|-------|------|
+| `cm-project-bootstrap` | Identity lock is Phase 0 of every new project |
+| `cm-safe-deploy` | Gate 0 secret hygiene checks wrangler.jsonc |
+| `cm-test-gate` | Phase 4 secret hygiene in test gate setup |
+| `cm-secret-shield` | Layer 5 token lifecycle extends identity management |
+| `cm-continuity` | Record identity decisions to decisions.json |
+
+## The Bottom Line
+
+**One `.project-identity.json`. One verification command. Every push, every deploy.**
+
+Wrong account = wasted time, broken deployments, exposed client code. The check takes 3 seconds.
+
+This is non-negotiable.

package/skills/cm-jtbd/SKILL.md

@@ -0,0 +1,98 @@
+---
+name: cm-jtbd
+description: "Customer discovery framework using Jobs-To-Be-Done theory — uncover the functional, social, and emotional jobs customers hire products to do. Produces JTBD canvases with job statements, outcome metrics, and competing solutions. Use alongside cm-brainstorm-idea for evidence-based product decisions."
+---
+
+# Jobs-To-Be-Done — Customer Discovery Framework
+
+> **Understand the job, not the customer.**
+> People don't buy products — they hire them to get a job done.
+
+## When to Use
+
+- Before designing a new feature or product
+- When existing features aren't converting or being used
+- Alongside `cm-brainstorm-idea` for deep customer context
+- User mentions: "customer discovery", "JTBD", "what do customers want", "product-market fit", "why are users churning"
+
+## The JTBD Framework
+
+### Job Statement Formula
+
+```
+When [SITUATION], I want to [MOTIVATION], so I can [EXPECTED OUTCOME]
+```
+
+### Three Job Dimensions
+
+| Dimension | Definition | Example |
+|-----------|-----------|---------|
+| **Functional** | The core task to accomplish | "Get from A to B quickly" |
+| **Social** | How the person wants to be perceived | "Be seen as a reliable professional" |
+| **Emotional** | How the person wants to feel | "Feel confident in my decision" |
+
+## Process
+
+### Phase 1: Job Discovery (Interviews)
+
+1. Recruit 5-8 recent customers (ideally within 90 days of purchase)
+2. Use the Switch Interview technique — ask about the moment they decided to switch/buy
+3. Key questions:
+   - "Walk me through the day you decided to [buy/switch/start using X]"
+   - "What were you doing before that solution existed?"
+   - "What was the first thing you tried? Why didn't that work?"
+   - "What almost stopped you from switching?"
+4. Record patterns: triggers → anxiety → progress → outcomes
+
+### Phase 2: JTBD Canvas
+
+For each major job discovered, complete the canvas:
+
+```
+JOB STATEMENT:
+When [situation], I want to [motivation], so I can [outcome]
+
+FUNCTIONAL DIMENSION: [core task]
+SOCIAL DIMENSION:     [perception goal]
+EMOTIONAL DIMENSION:  [feeling goal]
+
+FORCES PUSHING TO HIRE:
+(+) Push: [what makes them switch from current solution]
+(+) Pull: [what attracts them to new solution]
+
+FORCES RESISTING HIRE:
+(-) Anxiety: [fears about new solution]
+(-) Habit: [attachment to old solution]
+
+COMPETING SOLUTIONS CURRENTLY HIRED:
+1. [direct competitor or workaround]
+2. [indirect solution]
+3. [do-nothing option]
+
+OUTCOME METRICS (how customer measures success):
+- Speed: [e.g., "get answer in <5 minutes"]
+- Accuracy: [e.g., "zero errors in the output"]
+- Effort: [e.g., "no manual steps required"]
+```
+
+### Phase 3: Opportunity Scoring
+
+Rate each outcome metric:
+- **Importance** (1-10): How important is this outcome to the customer?
+- **Satisfaction** (1-10): How satisfied are they with current solutions?
+- **Opportunity score** = Importance + max(Importance − Satisfaction, 0)
+
+Scores ≥ 15 = underserved outcomes → highest priority to address.
+
+## Output
+
+Save JTBD canvas to `docs/jtbd/jtbd-canvas-[date].md`.
+
+## Integration
+
+| Skill | Relationship |
+|-------|-------------|
+| `cm-brainstorm-idea` | UPSTREAM: JTBD feeds into strategic analysis |
+| `cm-planning` | DOWNSTREAM: Validated jobs inform feature plans |
+| `cro-methodology` | COMPLEMENT: JTBD objections → CRO objection handling |
+| `cm-dockit` | OUTPUT: JTBD canvases are a document type in DocKit |

package/skills/cm-planning/SKILL.md

@@ -0,0 +1,130 @@
+---
+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."
+---
+
+# Planning — Brainstorm + Write Plans
+
+> **Role: Product Manager** — You explore intent, define scope, and document implementation plans before any code is written.
+
+> **Two phases, one skill:** Explore WHAT to build, then document HOW.
+
+## 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
+
+4.  **Skill Coverage Audit** — Do I have the right skills?
+    -   List all technologies/frameworks/tools referenced in the scope
+    -   Cross-reference with `cm-skill-index` Layer 1 triggers
+    -   If gap found → trigger Discovery Loop (`cm-skill-mastery` Part C):
+        `npx skills find "{keyword}"` → review → ask user → install
+    -   Note any gaps in plan as: "⚠️ No skill coverage — will trigger discovery during execution"
+
+5.  **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
+
+### Red Flags — STOP
+
+-   Starting code before brainstorming
+-   Assuming you know what the user wants
+-   Skipping scope definition
+-   "It's simple, no need to plan"
+
+## Phase B: Write Implementation Plan
+
+### When to Write a Plan
+
+-   Task has 3+ steps
+-   Multiple files involved
+-   Changes affect other components
+-   User explicitly asks for a plan
+
+### Plan Structure
+
+```markdown
+# [Goal]
+
+## Context
+What and why.
+
+## Requirements (for L2+ projects)
+| ID | Type | Description | Story | Test |
+|----|------|-------------|-------|------|
+| FR-001 | Functional | [requirement] | S-001 | T-001 |
+| NFR-001 | Non-Functional | [requirement] | Arch | Perf-001 |
+
+## Proposed Changes
+
+### [Component/File]
+- What changes
+- Why this approach
+
+## Verification
+How to verify it works.
+```
+
+> **Requirement Tracing (L2+ projects):** For medium and large projects, include FR/NFR IDs that trace from requirements → stories → tests. See `_shared/helpers.md#Project-Level-Detection` for level definitions.
+
+### Plan Rules
+
+```
+✅ DO:
+- Break into small, testable steps
+- Order by dependency (foundations first)
+- Include verification for each step
+- Keep steps bite-sized (15-30 min each)
+- Include FR/NFR table for L2+ projects
+
+❌ 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
+
+Per `_shared/helpers.md#Update-Continuity`
+Per `_shared/helpers.md#Save-Decision` — for any architecture decisions made during planning
+
+---
+
+## Integration
+
+| After planning... | Use skill |
+|-------------------|-----------|
+| Complex initiative/enhancement? | `cm-brainstorm-idea` (run BEFORE planning) |
+| Need isolated workspace | `cm-git-worktrees` |
+| Execute the plan (same session) | `cm-execution` |
+| Write tests first | `cm-tdd` |
+| Building UI/frontend | `cm-ui-preview` |
+
+## The Bottom Line
+
+**Think before you build. Document before you code. No exceptions.**