claude-devkit-cli 1.1.1 → 1.2.0

package/README.md

@@ -63,16 +63,16 @@ npx claude-devkit-cli init .
 claude
 
 # 3. Create your first spec and test plan
-/plan "describe your feature here"
+/mf-plan "describe your feature here"
 
 # 4. Write code, then test
-/test
+/mf-test
 
 # 5. Review before merging
-/review
+/mf-review
 
 # 6. Commit
-/commit
+/mf-commit
 ```
 
 That's it. The CLI auto-detects your project type and configures everything.
@@ -136,12 +136,12 @@ your-project/
 │   │   ├── sensitive-guard.sh ← Blocks access to secrets
 │   │   └── self-review.sh     ← Quality checklist on stop
 │   └── commands/
-│       ├── plan.md            ← /plan command
-│       ├── challenge.md       ← /challenge command
-│       ├── test.md            ← /test command
-│       ├── fix.md             ← /fix command
-│       ├── review.md          ← /review command
-│       └── commit.md          ← /commit command
+│       ├── mf-plan.md         ← /mf-plan command
+│       ├── mf-challenge.md    ← /mf-challenge command
+│       ├── mf-test.md         ← /mf-test command
+│       ├── mf-fix.md          ← /mf-fix command
+│       ├── mf-review.md       ← /mf-review command
+│       └── mf-commit.md       ← /mf-commit command
 ├── scripts/
 │   └── build-test.sh          ← Universal test runner
 └── docs/
@@ -196,21 +196,21 @@ This removes hooks, commands, settings, and build-test.sh. It preserves `CLAUDE.
 > When: Building something new — no existing code or spec.
 
 ```
-1. /plan "description of the feature"
+1. /mf-plan "description of the feature"
    → Generates spec + test plan. Review both.
 
 2. Implement code in chunks.
-   After each chunk: /test
+   After each chunk: /mf-test
    Repeat until green.
 
-3. /review (before merge)
+3. /mf-review (before merge)
 
-4. /commit
+4. /mf-commit
 ```
 
 **Example:**
 ```
-/plan "User authentication with email/password login, password reset via email, and session management with 24h expiry"
+/mf-plan "User authentication with email/password login, password reset via email, and session management with 24h expiry"
 ```
 
 ### Update Existing Feature
@@ -220,14 +220,14 @@ This removes hooks, commands, settings, and build-test.sh. It preserves `CLAUDE.
 ```
 1. Edit the spec first: docs/specs/<feature>.md
 
-2. /plan docs/specs/<feature>.md
+2. /mf-plan docs/specs/<feature>.md
    → Updates the test plan with new/modified/removed cases.
 
 3. Implement the code change.
-   /test
+   /mf-test
    Fix until green.
 
-4. /review → /commit
+4. /mf-review → /mf-commit
 ```
 
 ### Bug Fix
@@ -235,15 +235,15 @@ This removes hooks, commands, settings, and build-test.sh. It preserves `CLAUDE.
 > When: Something is broken.
 
 ```
-1. /fix "description of the bug"
+1. /mf-fix "description of the bug"
    → Writes failing test → fixes code → runs full suite.
 
-2. /commit
+2. /mf-commit
 ```
 
 **Example:**
 ```
-/fix "Search returns no results when query contains apostrophes like O'Brien"
+/mf-fix "Search returns no results when query contains apostrophes like O'Brien"
 ```
 
 ### Remove Feature
@@ -258,20 +258,20 @@ This removes hooks, commands, settings, and build-test.sh. It preserves `CLAUDE.
 3. bash scripts/build-test.sh (run full suite)
    Fix cascading breaks.
 
-4. /commit
+4. /mf-commit
 ```
 
 ---
 
 ## 5. Commands Reference
 
-### /plan — Generate Spec + Test Plan
+### /mf-plan — Generate Spec + Test Plan
 
 **Usage:**
 ```
-/plan docs/specs/auth.md                    # Mode A: from existing spec
-/plan "user authentication with OAuth2"     # Mode B: from description
-/plan docs/specs/auth.md (after spec edit)  # Mode C: update existing plan
+/mf-plan docs/specs/auth.md                    # Mode A: from existing spec
+/mf-plan "user authentication with OAuth2"     # Mode B: from description
+/mf-plan docs/specs/auth.md (after spec edit)  # Mode C: update existing plan
 ```
 
 **Modes:**
@@ -304,13 +304,13 @@ Priorities: **P0** (must have), **P1** (should have), **P2** (nice to have).
 - Spec: `docs/specs/<feature>.md`
 - Test plan: `docs/test-plans/<feature>.md`
 
-### /challenge — Adversarial Plan Review
+### /mf-challenge — Adversarial Plan Review
 
 **Usage:**
 ```
-/challenge docs/test-plans/auth.md   # challenge a test plan
-/challenge docs/specs/auth.md        # challenge a spec
-/challenge "user authentication"     # challenge by feature name
+/mf-challenge docs/test-plans/auth.md   # challenge a test plan
+/mf-challenge docs/specs/auth.md        # challenge a spec
+/mf-challenge "user authentication"     # challenge by feature name
 ```
 
 **How it works (7 phases):**
@@ -377,19 +377,19 @@ Priorities: **P0** (must have), **P1** (should have), **P2** (nice to have).
 6. Skip style/formatting — substance only
 
 **When to use:**
-- After `/plan`, before coding — for complex features
+- After `/mf-plan`, before coding — for complex features
 - Features involving auth, payments, data pipelines, multi-service integration
 - NOT needed for simple CRUD, small bug fixes, or trivial features
 
 **Token cost:** 15-30k (uses parallel subagents, doesn't bloat main context)
 
-### /test — Write + Run Tests
+### /mf-test — Write + Run Tests
 
 **Usage:**
 ```
-/test                              # test all changes vs base branch
-/test src/api/users.ts             # test specific file
-/test "user authentication"        # test specific feature
+/mf-test                              # test all changes vs base branch
+/mf-test src/api/users.ts             # test specific file
+/mf-test "user authentication"        # test specific feature
 ```
 
 **How it works:**
@@ -409,11 +409,11 @@ Priorities: **P0** (must have), **P1** (should have), **P2** (nice to have).
 
 **What NOT to test:** Private/internal methods, framework behavior, trivial getters/setters, implementation details.
 
-### /fix — Test-First Bug Fix
+### /mf-fix — Test-First Bug Fix
 
 **Usage:**
 ```
-/fix "description of the bug"
+/mf-fix "description of the bug"
 ```
 
 **How it works:**
@@ -427,12 +427,12 @@ Priorities: **P0** (must have), **P1** (should have), **P2** (nice to have).
 
 **Multiple bugs:** Triages by severity, fixes one at a time, commits each separately.
 
-### /review — Pre-Merge Quality Gate
+### /mf-review — Pre-Merge Quality Gate
 
 **Usage:**
 ```
-/review                            # review all changes vs base branch
-/review src/auth/                  # review specific directory
+/mf-review                            # review all changes vs base branch
+/mf-review src/auth/                  # review specific directory
 ```
 
 **How it works:**
@@ -461,11 +461,11 @@ Priorities: **P0** (must have), **P1** (should have), **P2** (nice to have).
 - Never auto-fixes code — report only
 - Checks spec-test alignment: code changed → spec/tests also changed? Vague requirements without metrics ("fast", "secure") get flagged with a suggestion to add concrete numbers
 
-### /commit — Smart Git Commit
+### /mf-commit — Smart Git Commit
 
 **Usage:**
 ```
-/commit
+/mf-commit
 ```
 
 **How it works:**
@@ -749,7 +749,7 @@ Skip sections that don't apply. Match depth to feature complexity.
 
 ### Test Plan Format
 
-Generated by `/plan` at `docs/test-plans/<feature-name>.md`:
+Generated by `/mf-plan` at `docs/test-plans/<feature-name>.md`:
 
 ```markdown
 # Test Plan: <Feature Name>
@@ -817,8 +817,8 @@ Create new `.md` files in `.claude/commands/`:
 # .claude/commands/deploy.md
 
 Run the deployment pipeline:
-1. /review
-2. /commit
+1. /mf-review
+2. /mf-commit
 3. Run: bash scripts/deploy.sh $ARGUMENTS
 4. Verify deployment health: curl -f https://api.example.com/health
 ```
@@ -831,20 +831,20 @@ Then use: `/deploy staging`
 
 | Activity | Tokens | Frequency |
 |----------|--------|-----------|
-| `/test` (incremental, 1-3 files) | 5–10k | Every code chunk |
-| `/fix` (single bug) | 3–5k | As needed |
-| `/commit` | 2–4k | Every commit |
-| `/review` (diff-based) | 10–20k | Before merge |
-| `/plan` (new feature) | 20–40k | Start of feature |
-| `/challenge` (adversarial review) | 15–30k | After /plan, complex features |
+| `/mf-test` (incremental, 1-3 files) | 5–10k | Every code chunk |
+| `/mf-fix` (single bug) | 3–5k | As needed |
+| `/mf-commit` | 2–4k | Every commit |
+| `/mf-review` (diff-based) | 10–20k | Before merge |
+| `/mf-plan` (new feature) | 20–40k | Start of feature |
+| `/mf-challenge` (adversarial review) | 15–30k | After /mf-plan, complex features |
 | Full audit (manual prompt) | 100k+ | Before release |
 
 ### Minimizing Token Usage
 
-- **Test incrementally.** `/test` after each small chunk uses 5-10k. Waiting until everything is done then running `/test` on a large diff uses 50k+.
-- **Use filters.** `/test src/auth/login.ts` is cheaper than `/test` on the whole project.
-- **Skip `/plan` for tiny changes.** Under 5 lines with no behavior change? Just `/test` and `/commit`.
-- **Use `/review` only before merge.** Not after every commit.
+- **Test incrementally.** `/mf-test` after each small chunk uses 5-10k. Waiting until everything is done then running `/mf-test` on a large diff uses 50k+.
+- **Use filters.** `/mf-test src/auth/login.ts` is cheaper than `/mf-test` on the whole project.
+- **Skip `/mf-plan` for tiny changes.** Under 5 lines with no behavior change? Just `/mf-test` and `/mf-commit`.
+- **Use `/mf-review` only before merge.** Not after every commit.
 
 ---
 
@@ -871,7 +871,7 @@ Then use: `/deploy staging`
 
 ### Wrong base branch
 
-**Symptom:** `/test` or `/review` compares against wrong branch.
+**Symptom:** `/mf-test` or `/mf-review` compares against wrong branch.
 
 **Check:**
 ```bash
@@ -901,19 +901,19 @@ export FILE_GUARD_EXCLUDE="*.generated.swift,*.pb.go,*.min.js,*.snap"
 ## 12. FAQ
 
 **Q: Do I need specs for every tiny change?**
-A: No. Changes under 5 lines with no behavior change can skip the spec. Just `/test` and `/commit`. The spec-first rule is for meaningful behavior changes.
+A: No. Changes under 5 lines with no behavior change can skip the spec. Just `/mf-test` and `/mf-commit`. The spec-first rule is for meaningful behavior changes.
 
 **Q: Can I use mocks in tests?**
 A: Only for external services you can't run locally (third-party APIs, email services). Never mock your own code or database just to make tests pass faster.
 
 **Q: What if Claude writes a test that tests the wrong thing?**
-A: This usually means the spec is ambiguous. Clarify the spec first, then re-run `/test`. Good specs produce good tests.
+A: This usually means the spec is ambiguous. Clarify the spec first, then re-run `/mf-test`. Good specs produce good tests.
 
 **Q: Can I use this with other AI coding tools?**
 A: The commands and hooks are Claude Code-specific. The specs, test plans, workflow, and `build-test.sh` work with any tool or manual workflow.
 
-**Q: When should I use `/challenge`?**
-A: After `/plan`, for complex features involving authentication, payments, data pipelines, or multi-service integration. It spawns parallel hostile reviewers that find security holes, failure modes, and false assumptions BEFORE you write code. Skip it for simple CRUD or small features — the overhead isn't worth it.
+**Q: When should I use `/mf-challenge`?**
+A: After `/mf-plan`, for complex features involving authentication, payments, data pipelines, or multi-service integration. It spawns parallel hostile reviewers that find security holes, failure modes, and false assumptions BEFORE you write code. Skip it for simple CRUD or small features — the overhead isn't worth it.
 
 **Q: How do I do a full coverage audit?**
 A: This is intentionally not a command (it's expensive and rare). When needed, prompt Claude directly: "Audit test coverage for feature X against docs/test-plans/X.md. Identify gaps and write missing tests."

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "claude-devkit-cli",
-  "version": "1.1.1",
+  "version": "1.2.0",
   "description": "CLI toolkit for spec-first development with Claude Code — hooks, commands, guards, and test runners",
   "bin": {
     "claude-devkit": "./bin/devkit.js",

package/src/commands/init.js

@@ -164,7 +164,7 @@ export async function initCommand(path, opts) {
   console.log('  .claude/CLAUDE.md          — Project rules (review and customize)');
   console.log('  .claude/settings.json      — Hook configuration');
   console.log('  .claude/hooks/             — 6 guards (file, path, glob, comment, sensitive, self-review)');
-  console.log('  .claude/commands/          — /plan, /challenge, /test, /fix, /review, /commit');
+  console.log('  .claude/commands/          — /mf-plan, /mf-challenge, /mf-test, /mf-fix, /mf-review, /mf-commit');
   console.log('  scripts/build-test.sh      — Universal test runner');
   console.log('  docs/WORKFLOW.md           — Workflow reference');
   log.blank();
@@ -176,8 +176,8 @@ export async function initCommand(path, opts) {
   console.log('Next steps:');
   console.log('  1. Review .claude/CLAUDE.md — ensure project info is correct');
   console.log('  2. Write your first spec:   docs/specs/<feature>.md');
-  console.log('  3. Generate test plan:      /plan docs/specs/<feature>.md');
-  console.log('  4. Start coding + testing:  /test');
+  console.log('  3. Generate test plan:      /mf-plan docs/specs/<feature>.md');
+  console.log('  4. Start coding + testing:  /mf-test');
   log.blank();
 
   if (warnings > 0) {

package/src/lib/installer.js

@@ -20,12 +20,12 @@ export const COMPONENTS = {
     '.claude/hooks/sensitive-guard.sh',
   ],
   commands: [
-    '.claude/commands/plan.md',
-    '.claude/commands/challenge.md',
-    '.claude/commands/test.md',
-    '.claude/commands/fix.md',
-    '.claude/commands/review.md',
-    '.claude/commands/commit.md',
+    '.claude/commands/mf-plan.md',
+    '.claude/commands/mf-challenge.md',
+    '.claude/commands/mf-test.md',
+    '.claude/commands/mf-fix.md',
+    '.claude/commands/mf-review.md',
+    '.claude/commands/mf-commit.md',
   ],
   config: [
     '.claude/settings.json',

package/templates/.claude/CLAUDE.md

@@ -13,12 +13,12 @@ Every change follows this cycle: **SPEC → TEST PLAN → CODE + TESTS → BUILD
 
 | Trigger | Commands | Details |
 |---------|----------|---------|
-| New feature | `/plan` → `/challenge` (optional) → code in chunks → `/test` each chunk | Start with spec or description |
-| Update feature | Update spec first → `/plan` → code → `/test` | Spec changes before code changes |
-| Bug fix | `/fix "description"` | Test-first: write failing test → fix → green |
+| New feature | `/mf-plan` → `/mf-challenge` (optional) → code in chunks → `/mf-test` each chunk | Start with spec or description |
+| Update feature | Update spec first → `/mf-plan` → code → `/mf-test` | Spec changes before code changes |
+| Bug fix | `/mf-fix "description"` | Test-first: write failing test → fix → green |
 | Remove feature | Mark spec as removed → delete code + tests → build pass | Run full suite after removal |
-| Pre-merge check | `/review` | Diff-based quality gate |
-| Commit changes | `/commit` | Secret scan + conventional commit |
+| Pre-merge check | `/mf-review` | Diff-based quality gate |
+| Commit changes | `/mf-commit` | Secret scan + conventional commit |
 
 For detailed workflow steps, templates, and decision trees, see `docs/WORKFLOW.md`.
 

package/templates/.claude/commands/{challenge.md → mf-challenge.md}

@@ -1,4 +1,4 @@
-Think hard. This is adversarial plan review — you are the coordinator who sends hostile reviewers to DESTROY a plan, then adjudicates their findings.
+Adversarial review — spawn hostile reviewers to break the plan before coding.
 
 ## Input
 
@@ -195,7 +195,7 @@ Reviewers: N lenses
 Findings: X total → Y accepted, Z rejected
 Severity: N Critical, N High, N Medium
 Files modified: [list]
-Next: /test to implement, or /plan to regenerate if major changes.
+Next: /mf-test to implement, or /mf-plan to regenerate if major changes.
 ```
 
 If a reviewer returns > 7 findings, take only top 7 by severity. If a reviewer fails, proceed with remaining reviewers.

package/templates/.claude/commands/{commit.md → mf-commit.md}

@@ -1,4 +1,4 @@
-EXECUTE, not EXPLORE. Follow these steps exactly. Minimize tool calls.
+Stage, scan secrets, generate conventional commit message.
 
 ## Step 1 — Analyze (single compound command)
 

package/templates/.claude/commands/{fix.md → mf-fix.md}

@@ -1,4 +1,4 @@
-Test-first bug fix. Investigate → Reproduce → Fix → Verify → Learn.
+Test-first bug fix — write failing test, fix code, verify green.
 
 Bug: $ARGUMENTS
 

package/templates/.claude/commands/{plan.md → mf-plan.md}

@@ -1,4 +1,4 @@
-Think hard about this task. A bad plan wastes days, a good plan saves weeks.
+Generate spec + test plan from description or existing spec.
 
 ## Determine mode
 
@@ -116,7 +116,7 @@ Write to `docs/test-plans/<feature-name>.md`:
 ## Phase 4: Summary
 
 Show: test case counts (P0/P1/P2), implementation order, estimated scope.
-Next steps: "Use `/test` after each chunk. For complex plans, run `/challenge` first."
+Next steps: "Use `/mf-test` after each chunk. For complex plans, run `/mf-challenge` first."
 
 ## Naming Convention
 

package/templates/.claude/commands/{review.md → mf-review.md}

@@ -1,4 +1,4 @@
-Think hard about this review. You are the last gate before code reaches the main branch.
+Pre-merge code review — security, correctness, spec alignment.
 
 ## Phase 0: Understand Intent
 

package/templates/.claude/commands/{test.md → mf-test.md}

@@ -1,4 +1,4 @@
-EXECUTE, not EXPLORE. Write tests, run them, make them pass. Don't read unrelated files.
+Write tests from test plan, compile, run, fix until green.
 
 ## Phase 0: Build Context
 

package/templates/docs/WORKFLOW.md

@@ -11,24 +11,24 @@
 When: Building something that doesn't exist yet (no code, no spec).
 
 ```
-Step 1 → /plan "description of feature"
+Step 1 → /mf-plan "description of feature"
           Generates: docs/specs/<feature>.md (spec)
                      docs/test-plans/<feature>.md (test plan)
           Answers validation questions about assumptions.
           Review both before proceeding.
 
-Step 2 → (Optional) /challenge docs/test-plans/<feature>.md
+Step 2 → (Optional) /mf-challenge docs/test-plans/<feature>.md
           Adversarial review: spawns hostile reviewers to find flaws.
           Recommended for complex features, auth, data pipelines.
           Skip for simple CRUD or small features.
 
 Step 3 → Implement in chunks. After each chunk:
-          /test
+          /mf-test
           Repeat until chunk is green.
 
-Step 4 → /review (before merge)
+Step 4 → /mf-review (before merge)
 
-Step 5 → /commit
+Step 5 → /mf-commit
 ```
 
 ### Update Existing Feature
@@ -39,14 +39,14 @@ When: Changing behavior, adding options, refactoring logic.
 Step 1 → Update spec FIRST: docs/specs/<feature>.md
           Describe what's changing and why.
 
-Step 2 → /plan docs/specs/<feature>.md
+Step 2 → /mf-plan docs/specs/<feature>.md
           Updates the test plan with new/modified/removed test cases.
 
 Step 3 → Implement code changes.
-          /test
+          /mf-test
           Fix until green.
 
-Step 4 → /review → /commit
+Step 4 → /mf-review → /mf-commit
 ```
 
 ### Bug Fix
@@ -54,10 +54,10 @@ Step 4 → /review → /commit
 When: Something is broken and needs fixing.
 
 ```
-Step 1 → /fix "description of the bug"
+Step 1 → /mf-fix "description of the bug"
           Writes failing test → fixes code → confirms green → runs full suite.
 
-Step 2 → /commit
+Step 2 → /mf-commit
 
 Optional → If the bug reveals an undocumented edge case, update the spec.
 ```
@@ -75,7 +75,7 @@ Step 2 → Delete production code and related test code.
 Step 3 → Run full test suite: bash scripts/build-test.sh
           Fix any cascading breakage.
 
-Step 4 → /commit
+Step 4 → /mf-commit
 ```
 
 ---
@@ -86,20 +86,20 @@ Use this to decide which workflow to follow:
 
 ```
 Is this a brand new feature (no existing spec or code)?
-├─ Yes → New Feature workflow. Start with /plan.
+├─ Yes → New Feature workflow. Start with /mf-plan.
 │   └─ Is the feature complex (auth, data pipeline, multi-service)?
-│       ├─ Yes → Run /challenge after /plan, before coding.
-│       └─ No → Skip /challenge, go straight to implementation.
+│       ├─ Yes → Run /mf-challenge after /mf-plan, before coding.
+│       └─ No → Skip /mf-challenge, go straight to implementation.
 └─ No
     ├─ Is this a bug fix?
-    │   ├─ Yes → Bug Fix workflow. Start with /fix.
+    │   ├─ Yes → Bug Fix workflow. Start with /mf-fix.
     │   └─ No
     │       ├─ Are you removing/deprecating code?
     │       │   ├─ Yes → Remove Feature workflow.
     │       │   └─ No → Update Feature workflow. Start by editing the spec.
     │       │
     │       └─ Is the change very small (< 5 lines, behavior unchanged)?
-    │           └─ Yes → Skip spec update. Just /test and /commit.
+    │           └─ Yes → Skip spec update. Just /mf-test and /mf-commit.
 ```
 
 ---
@@ -170,16 +170,16 @@ Files to delete: [list]
 
 | Workflow | Estimated Tokens | When |
 |----------|-----------------|------|
-| `/test` (incremental) | 5–10k | Daily, after each code chunk |
-| `/fix` (single bug) | 3–5k | As bugs arise |
-| `/commit` | 2–4k | Each commit |
-| `/review` (diff-based) | 10–20k | Before merge |
-| `/plan` (new feature) | 20–40k | Start of new feature |
-| `/challenge` (adversarial) | 15–30k | After /plan, for complex features |
+| `/mf-test` (incremental) | 5–10k | Daily, after each code chunk |
+| `/mf-fix` (single bug) | 3–5k | As bugs arise |
+| `/mf-commit` | 2–4k | Each commit |
+| `/mf-review` (diff-based) | 10–20k | Before merge |
+| `/mf-plan` (new feature) | 20–40k | Start of new feature |
+| `/mf-challenge` (adversarial) | 15–30k | After /mf-plan, for complex features |
 | Full audit (manual) | 100k+ | Before release, quarterly |
 
 **Rule of thumb:** Daily work uses templates + `/test` → low token cost.
-Save `/plan` and full audits for significant milestones.
+Save `/mf-plan` and full audits for significant milestones.
 
 ---