@phuc1403/musketeer 0.8.0 → 0.9.0

package/template/.claude/skills/code-review/references/spec-compliance-review.md

@@ -0,0 +1,43 @@
+---
+name: spec-compliance-review
+description: First-pass review checking implementation matches spec/plan requirements before quality review
+---
+
+# Spec Compliance Review
+
+## Purpose
+
+Verify implementation matches what was requested BEFORE evaluating code quality.
+Well-written code that doesn't match requirements is still wrong.
+
+## When to Use
+
+- After implementing features from a plan
+- Before code quality review pass
+- When plan/spec exists for the work being reviewed
+
+## Process
+
+1. **Load spec/plan** — Read the plan.md or phase file that defined this work
+2. **List requirements** — Extract every requirement, acceptance criterion
+3. **Check each requirement** against actual implementation:
+   - Present? → PASS
+   - Missing? → MISSING (must fix before quality review)
+   - Extra (not in spec)? → EXTRA (flag for removal unless justified)
+4. **Verdict:**
+   - All requirements met, no unjustified extras → PASS → proceed to quality review
+   - Missing requirements → FAIL → implementer fixes → re-review
+   - Unjustified extras → WARN → discuss with user
+
+## Checklist Template
+
+| # | Requirement | Status | Notes |
+|---|-------------|--------|-------|
+| 1 | [from spec] | PASS/MISSING/EXTRA | [evidence] |
+
+## Red Flags
+
+- Skipping spec review because "code looks good"
+- Accepting extra features without spec justification
+- Treating spec review as optional
+- Reviewing code quality before confirming spec compliance

package/template/.claude/skills/code-review/references/task-management-reviews.md

@@ -0,0 +1,140 @@
+# Review Task Management Patterns
+
+Track review pipeline execution via Claude Native Tasks (TaskCreate, TaskUpdate, TaskList).
+
+## When to Create Tasks
+
+| Review Scope | Tasks? | Rationale |
+|--------------|--------|-----------|
+| Single-file fix | No | Scout + review + done, overhead not worth it |
+| Multi-file feature (3+ files) | Yes | Track scout → review → fix → verify chain |
+| Parallel reviewers (2+ scopes) | Yes | Coordinate independent reviews |
+| Review cycle with Critical fixes | Yes | Dependencies between fix → re-verify |
+
+**3-Task Rule:** Skip task creation when review pipeline has <3 meaningful steps.
+
+## Review Pipeline as Tasks
+
+```
+TaskCreate: "Scout edge cases"         → pending
+TaskCreate: "Review implementation"    → pending, blockedBy: [scout]
+TaskCreate: "Fix critical issues"      → pending, blockedBy: [review]
+TaskCreate: "Verify fixes pass"        → pending, blockedBy: [fix]
+```
+
+Dependency chain auto-unblocks: scout → review → fix → verify.
+
+## Task Schemas
+
+### Scout Task
+
+```
+TaskCreate(
+  subject: "Scout edge cases for {feature}",
+  activeForm: "Scouting edge cases",
+  description: "Identify affected files, data flows, boundary conditions. Changed: {files}",
+  metadata: { reviewStage: "scout", feature: "{feature}",
+              changedFiles: "src/auth.ts,src/middleware.ts",
+              priority: "P2", effort: "3m" }
+)
+```
+
+### Review Task
+
+```
+TaskCreate(
+  subject: "Review {feature} implementation",
+  activeForm: "Reviewing {feature}",
+  description: "Code-reviewer subagent reviews {BASE_SHA}..{HEAD_SHA}. Plan: {plan_ref}",
+  metadata: { reviewStage: "review", feature: "{feature}",
+              baseSha: "{BASE_SHA}", headSha: "{HEAD_SHA}",
+              priority: "P1", effort: "10m" },
+  addBlockedBy: ["{scout-task-id}"]
+)
+```
+
+### Fix Task (created after review finds issues)
+
+```
+TaskCreate(
+  subject: "Fix {severity} issues from review",
+  activeForm: "Fixing {severity} review issues",
+  description: "Address: {issue_list}",
+  metadata: { reviewStage: "fix", severity: "critical",
+              issueCount: 3, priority: "P1", effort: "15m" },
+  addBlockedBy: ["{review-task-id}"]
+)
+```
+
+### Verify Task
+
+```
+TaskCreate(
+  subject: "Verify fixes pass tests and build",
+  activeForm: "Verifying fixes",
+  description: "Run test suite, build, confirm 0 failures. Evidence before claims.",
+  metadata: { reviewStage: "verify", priority: "P1", effort: "5m" },
+  addBlockedBy: ["{fix-task-id}"]
+)
+```
+
+## Parallel Review Coordination
+
+For multi-scope reviews (e.g., backend + frontend changed independently):
+
+```
+// Create scoped review tasks — no blockedBy between them
+TaskCreate(subject: "Review backend auth changes",
+  metadata: { reviewStage: "review", scope: "src/api/,src/middleware/",
+              agentIndex: 1, totalAgents: 2, priority: "P1" })
+
+TaskCreate(subject: "Review frontend auth UI",
+  metadata: { reviewStage: "review", scope: "src/components/auth/",
+              agentIndex: 2, totalAgents: 2, priority: "P1" })
+
+// Both run simultaneously via separate code-reviewer subagents
+// Fix task blocks on BOTH completing:
+TaskCreate(subject: "Fix all review issues",
+  addBlockedBy: ["{backend-review-id}", "{frontend-review-id}"])
+```
+
+## Task Lifecycle
+
+```
+Scout:    pending → in_progress → completed (scout report returned)
+Review:   pending → in_progress → completed (reviewer findings returned)
+Fix:      pending → in_progress → completed (all Critical/Important fixed)
+Verify:   pending → in_progress → completed (tests pass, build clean)
+```
+
+### Handling Re-Reviews
+
+When fixes introduce new issues → create new review cycle:
+
+```
+TaskCreate(subject: "Re-review after fixes",
+  addBlockedBy: ["{fix-task-id}"],
+  metadata: { reviewStage: "review", cycle: 2, priority: "P1" })
+```
+
+Limit to 3 cycles. If still failing after cycle 3 → escalate to user.
+
+## Integration with Planning Tasks
+
+Review tasks are **separate from** cook/planning phase tasks.
+
+**When cook spawns review:**
+1. Cook completes implementation phase → creates review pipeline tasks
+2. Review pipeline executes (scout → review → fix → verify)
+3. All review tasks complete → cook marks phase as reviewed
+4. Cook proceeds to next phase
+
+Review tasks reference the phase but don't block it directly — the orchestrator manages handoff.
+
+## Quality Check
+
+After pipeline registration: `Registered [N] review tasks (scout → review → fix → verify chain)`
+
+## Error Handling
+
+If `TaskCreate` fails: log warning, fall back to sequential review without task tracking. Review pipeline functions identically — tasks add visibility, not functionality.

package/template/.claude/skills/code-review/references/verification-before-completion.md

@@ -0,0 +1,139 @@
+---
+name: verification-before-completion
+description: Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always
+---
+
+# Verification Before Completion
+
+## Overview
+
+Claiming work is complete without verification is dishonesty, not efficiency.
+
+**Core principle:** Evidence before claims, always.
+
+**Violating the letter of this rule is violating the spirit of this rule.**
+
+## The Iron Law
+
+```
+NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE
+```
+
+If you haven't run the verification command in this message, you cannot claim it passes.
+
+## The Gate Function
+
+```
+BEFORE claiming any status or expressing satisfaction:
+
+1. IDENTIFY: What command proves this claim?
+2. RUN: Execute the FULL command (fresh, complete)
+3. READ: Full output, check exit code, count failures
+4. VERIFY: Does output confirm the claim?
+   - If NO: State actual status with evidence
+   - If YES: State claim WITH evidence
+5. ONLY THEN: Make the claim
+
+Skip any step = lying, not verifying
+```
+
+## Common Failures
+
+| Claim | Requires | Not Sufficient |
+|-------|----------|----------------|
+| Tests pass | Test command output: 0 failures | Previous run, "should pass" |
+| Linter clean | Linter output: 0 errors | Partial check, extrapolation |
+| Build succeeds | Build command: exit 0 | Linter passing, logs look good |
+| Bug fixed | Test original symptom: passes | Code changed, assumed fixed |
+| Regression test works | Red-green cycle verified | Test passes once |
+| Agent completed | VCS diff shows changes | Agent reports "success" |
+| Requirements met | Line-by-line checklist | Tests passing |
+
+## Red Flags - STOP
+
+- Using "should", "probably", "seems to"
+- Expressing satisfaction before verification ("Great!", "Perfect!", "Done!", etc.)
+- About to commit/push/PR without verification
+- Trusting agent success reports
+- Relying on partial verification
+- Thinking "just this once"
+- Tired and wanting work over
+- **ANY wording implying success without having run verification**
+
+## Rationalization Prevention
+
+| Excuse | Reality |
+|--------|---------|
+| "Should work now" | RUN the verification |
+| "I'm confident" | Confidence ≠ evidence |
+| "Just this once" | No exceptions |
+| "Linter passed" | Linter ≠ compiler |
+| "Agent said success" | Verify independently |
+| "I'm tired" | Exhaustion ≠ excuse |
+| "Partial check is enough" | Partial proves nothing |
+| "Different words so rule doesn't apply" | Spirit over letter |
+
+## Key Patterns
+
+**Tests:**
+```
+✅ [Run test command] [See: 34/34 pass] "All tests pass"
+❌ "Should pass now" / "Looks correct"
+```
+
+**Regression tests (TDD Red-Green):**
+```
+✅ Write → Run (pass) → Revert fix → Run (MUST FAIL) → Restore → Run (pass)
+❌ "I've written a regression test" (without red-green verification)
+```
+
+**Build:**
+```
+✅ [Run build] [See: exit 0] "Build passes"
+❌ "Linter passed" (linter doesn't check compilation)
+```
+
+**Requirements:**
+```
+✅ Re-read plan → Create checklist → Verify each → Report gaps or completion
+❌ "Tests pass, phase complete"
+```
+
+**Agent delegation:**
+```
+✅ Agent reports success → Check VCS diff → Verify changes → Report actual state
+❌ Trust agent report
+```
+
+## Why This Matters
+
+From 24 failure memories:
+- your human partner said "I don't believe you" - trust broken
+- Undefined functions shipped - would crash
+- Missing requirements shipped - incomplete features
+- Time wasted on false completion → redirect → rework
+- Violates: "Honesty is a core value. If you lie, you'll be replaced."
+
+## When To Apply
+
+**ALWAYS before:**
+- ANY variation of success/completion claims
+- ANY expression of satisfaction
+- ANY positive statement about work state
+- Committing, PR creation, task completion
+- Moving to next task
+- Delegating to agents
+
+**Rule applies to:**
+- Exact phrases
+- Paraphrases and synonyms
+- Implications of success
+- ANY communication suggesting completion/correctness
+
+## The Bottom Line
+
+**No shortcuts for verification.**
+
+Run the command. Read the output. THEN claim the result.
+
+This is non-negotiable.

package/template/.claude/skills/git/SKILL.md

@@ -1,115 +1,131 @@
----
-name: ck:git
-description: "Git operations with conventional commits. Use for staging, committing, pushing, PRs, merges. Auto-splits commits by type/scope. Security scans for secrets."
-argument-hint: "cm|cp|pr|merge [args]"
-metadata:
-  author: claudekit
-  version: "1.0.0"
----
-
-# Git Operations
-
-## Default (No Arguments)
-
-If invoked without arguments, use `AskUserQuestion` to present available git operations:
-
-| Operation | Description |
-|-----------|-------------|
-| `cm` | Stage files & create commits |
-| `cp` | Stage files, create commits and push |
-| `pr` | Create Pull Request |
-| `merge` | Merge branches |
-
-Present as options via `AskUserQuestion` with header "Git Operation", question "What would you like to do?".
-
-Execute git workflows via `git-manager` subagent to isolate verbose output.
-
-**IMPORTANT:**
-- Sacrifice grammar for the sake of concision.
-- Ensure token efficiency while maintaining high quality.
-- Pass these rules to subagents.
-
-## Arguments
-- `cm`: Stage files & create commits
-- `cp`: Stage files, create commits and push
-- `pr`: Create Pull Request [to-branch] [from-branch]
-  - `to-branch`: Target branch (default: main)
-  - `from-branch`: Source branch (default: current branch)
-- `merge`: Merge [to-branch] [from-branch]
-  - `to-branch`: Target branch (default: main)
-  - `from-branch`: Source branch (default: current branch)
-
-## Quick Reference
-
-| Task | Reference |
-|------|-----------|
-| Commit | `references/workflow-commit.md` |
-| Push | `references/workflow-push.md` |
-| Pull Request | `references/workflow-pr.md` |
-| Merge | `references/workflow-merge.md` |
-| Standards | `references/commit-standards.md` |
-| Safety | `references/safety-protocols.md` |
-| Branches | `references/branch-management.md` |
-| GitHub CLI | `references/gh-cli-guide.md` |
-
-## Core Workflow
-
-### Step 1: Stage + Analyze
-```bash
-git add -A && git diff --cached --stat && git diff --cached --name-only
-```
-
-### Step 2: Security Check
-Scan for secrets before commit:
-```bash
-git diff --cached | grep -iE "(api[_-]?key|token|password|secret|credential)"
-```
-**If secrets found:** STOP, warn user, suggest `.gitignore`.
-
-### Step 3: Split Decision
-
-**NOTE:**
-- Search for related issues on GitHub and add to body.
-- Only use `feat`, `fix`, or `perf` prefixes for files in `.claude` directory (do not use `docs`).
-
-**Split commits if:**
-- Different types mixed (feat + fix, code + docs)
-- Multiple scopes (auth + payments)
-- Config/deps + code mixed
-- FILES > 10 unrelated
-
-**Single commit if:**
-- Same type/scope, FILES ≤ 3, LINES ≤ 50
-
-### Step 4: Commit
-```bash
-git commit -m "type(scope): description"
-```
-
-## Output Format
-```
-✓ staged: N files (+X/-Y lines)
-✓ security: passed
-✓ commit: HASH type(scope): description
-✓ pushed: yes/no
-```
-
-## Error Handling
-
-| Error | Action |
-|-------|--------|
-| Secrets detected | Block commit, show files |
-| No changes | Exit cleanly |
-| Push rejected | Suggest `git pull --rebase` |
-| Merge conflicts | Suggest manual resolution |
-
-## References
-
-- `references/workflow-commit.md` - Commit workflow with split logic
-- `references/workflow-push.md` - Push workflow with error handling
-- `references/workflow-pr.md` - PR creation with remote diff analysis
-- `references/workflow-merge.md` - Branch merge workflow
-- `references/commit-standards.md` - Conventional commit format rules
-- `references/safety-protocols.md` - Secret detection, branch protection
-- `references/branch-management.md` - Naming, lifecycle, strategies
-- `references/gh-cli-guide.md` - GitHub CLI commands reference
+---
+name: ck:git
+description: "Manage git commits, pushes, PRs, branch merges, and PR review-and-merge automation. Use for commit, push, PR creation, PR merge, CI follow-up, and secret scanning."
+user-invocable: true
+when_to_use: "Invoke for commits, PRs, branch hygiene, or release git steps."
+category: dev-tools
+keywords: [git, commits, staging, PR, merge, merge-pr, ci]
+argument-hint: "cm|cp|pr|merge|merge-pr [args]"
+metadata:
+  author: claudekit
+  version: "1.0.0"
+---
+
+# Git Operations
+
+## Default (No Arguments)
+
+If invoked without arguments, use `AskUserQuestion` to present available git operations:
+
+| Operation | Description |
+|-----------|-------------|
+| `cm` | Stage files & create commits |
+| `cp` | Stage files, create commits and push |
+| `pr` | Create Pull Request |
+| `merge` | Merge branches |
+| `merge-pr` | Review, label, merge PRs, then watch/fix CI |
+
+Present as options via `AskUserQuestion` with header "Git Operation", question "What would you like to do?".
+
+Execute git workflows via `git-manager` subagent to isolate verbose output.
+Keep verbose git/gh output out of the main context: `references/context-efficiency.md`.
+
+**IMPORTANT:**
+- Sacrifice grammar for the sake of concision.
+- Ensure token efficiency while maintaining high quality.
+- Pass these rules to subagents.
+
+## Arguments
+- `cm`: Stage files & create commits
+- `cp`: Stage files, create commits and push
+- `pr`: Create Pull Request [to-branch] [from-branch]
+  - `to-branch`: Target branch (default: main)
+  - `from-branch`: Source branch (default: current branch)
+- `merge`: Merge [to-branch] [from-branch]
+  - `to-branch`: Target branch (default: main)
+  - `from-branch`: Source branch (default: current branch)
+- `merge-pr`: Review, label, merge, and post-merge verify PRs
+  - Usage: `/ck:git merge-pr <PR numbers or URLs>`
+  - Accepts one or more PR numbers or GitHub PR URLs
+  - Runs `/code-review <PR>` before any label or merge (findings only — no auto-fix, no GitHub replies)
+  - Adds label `ready to ship` only once the review is clean and checks are green
+  - Merges only reviewed-and-ready PRs, then watches target-branch CI to success
+
+## Quick Reference
+
+| Task | Reference |
+|------|-----------|
+| Commit | `references/workflow-commit.md` |
+| Push | `references/workflow-push.md` |
+| Pull Request | `references/workflow-pr.md` |
+| Merge | `references/workflow-merge.md` |
+| Merge PRs | `references/workflow-merge-pr.md` |
+| Standards | `references/commit-standards.md` |
+| Safety | `references/safety-protocols.md` |
+| Branches | `references/branch-management.md` |
+| GitHub CLI | `references/gh-cli-guide.md` |
+| Context efficiency | `references/context-efficiency.md` |
+
+## Core Workflow
+
+### Step 1: Stage + Analyze
+```bash
+git add -A && git diff --cached --stat && git diff --cached --name-only
+```
+
+### Step 2: Security Check
+Scan for secrets before commit:
+```bash
+git diff --cached | grep -iE "(api[_-]?key|token|password|secret|credential)"
+```
+**If secrets found:** STOP, warn user, suggest `.gitignore`.
+
+### Step 3: Split Decision
+
+**NOTE:**
+- Search for related issues on GitHub and add to body.
+- Only use `feat`, `fix`, or `perf` prefixes for files in `.claude` directory (do not use `docs`).
+
+**Split commits if:**
+- Different types mixed (feat + fix, code + docs)
+- Multiple scopes (auth + payments)
+- Config/deps + code mixed
+- FILES > 10 unrelated
+
+**Single commit if:**
+- Same type/scope, FILES ≤ 3, LINES ≤ 50
+
+### Step 4: Commit
+```bash
+git commit -m "type(scope): description"
+```
+
+## Output Format
+```
+✓ staged: N files (+X/-Y lines)
+✓ security: passed
+✓ commit: HASH type(scope): description
+✓ pushed: yes/no
+```
+
+## Error Handling
+
+| Error | Action |
+|-------|--------|
+| Secrets detected | Block commit, show files |
+| No changes | Exit cleanly |
+| Push rejected | Suggest `git pull --rebase` |
+| Merge conflicts | Suggest manual resolution |
+
+## References
+
+- `references/workflow-commit.md` - Commit workflow with split logic
+- `references/workflow-push.md` - Push workflow with error handling
+- `references/workflow-pr.md` - PR creation with remote diff analysis
+- `references/workflow-merge.md` - Branch merge workflow
+- `references/workflow-merge-pr.md` - PR review, ready label, merge, and CI convergence workflow
+- `references/commit-standards.md` - Conventional commit format rules
+- `references/safety-protocols.md` - Secret detection, branch protection
+- `references/branch-management.md` - Naming, lifecycle, strategies
+- `references/gh-cli-guide.md` - GitHub CLI commands reference
+- `references/context-efficiency.md` - Keeping verbose git/gh output out of context