cc-devflow 4.2.0 → 4.4.1

package/.claude/skills/domain/finishing-branch/SKILL.md

@@ -1,189 +0,0 @@
----
-name: flow-finishing-branch
-description: "Decide how to complete a development branch: merge, PR, squash, or cleanup."
----
-
-# Flow Finishing Branch - 分支完成决策
-
-## Overview
-
-When development work is complete, you need to decide how to integrate it. This skill guides that decision.
-
-## Decision Options
-
-### A) Fast-forward Merge
-
-```yaml
-When to use:
-  - Small changes (< 5 files)
-  - Single developer
-  - No review needed
-  - Clean commit history
-
-Command:
-  git checkout main
-  git merge --ff-only feature/xxx
-  git branch -d feature/xxx
-
-Pros:
-  - Fast
-  - Clean history
-  - No merge commit
-
-Cons:
-  - No review record
-  - No CI verification
-```
-
-### B) Create PR (Recommended)
-
-```yaml
-When to use:
-  - Team projects
-  - Need review record
-  - CI verification required
-  - Production code
-
-Command:
-  git push -u origin feature/xxx
-  gh pr create --title "..." --body "..."
-
-Pros:
-  - Review record
-  - CI verification
-  - Discussion thread
-  - Audit trail
-
-Cons:
-  - Takes longer
-  - Requires reviewer
-```
-
-### C) Squash and Merge
-
-```yaml
-When to use:
-  - Many small commits
-  - Messy commit history
-  - Want single commit in main
-
-Command:
-  gh pr merge --squash
-
-Pros:
-  - Clean main history
-  - Single logical commit
-  - Hides WIP commits
-
-Cons:
-  - Loses detailed history
-  - Harder to bisect
-```
-
-### D) Cleanup Only
-
-```yaml
-When to use:
-  - Work was abandoned
-  - Experiment failed
-  - Requirements changed
-
-Command:
-  git checkout main
-  git branch -D feature/xxx
-  git push origin --delete feature/xxx  # if pushed
-
-Pros:
-  - Clean slate
-  - No dead branches
-
-Cons:
-  - Work is lost (unless needed later)
-```
-
-## Decision Matrix
-
-```
-┌─────────────────────────────────────────────────────────────┐
-│                    Decision Matrix                          │
-├─────────────────────────────────────────────────────────────┤
-│                                                             │
-│  Files Changed    Review Needed    History Clean    Action  │
-│  ─────────────    ─────────────    ─────────────    ──────  │
-│  < 5              No               Yes              A) FF   │
-│  < 5              No               No               C) Sq   │
-│  Any              Yes              Yes              B) PR   │
-│  Any              Yes              No               C) Sq   │
-│  N/A              N/A              N/A (abandoned)  D) Del  │
-│                                                             │
-└─────────────────────────────────────────────────────────────┘
-```
-
-## Pre-Completion Checklist
-
-Before choosing any option, verify:
-
-```yaml
-□ All tests pass
-□ Build succeeds
-□ No lint errors
-□ Documentation updated (if needed)
-□ EXECUTION_LOG.md updated
-□ No uncommitted changes
-```
-
-## The Process
-
-```yaml
-1. Verify completion
-   → Run tests, build, lint
-   → Check all tasks done
-
-2. Assess the work
-   → How many files changed?
-   → Is review needed?
-   → Is commit history clean?
-
-3. Choose option
-   → Use decision matrix
-   → Default to PR if unsure
-
-4. Execute
-   → Run appropriate commands
-   → Verify success
-
-5. Cleanup
-   → Delete local branch
-   → Delete remote branch (if not PR)
-```
-
-## Rationalization Prevention
-
-| Excuse | Reality |
-|--------|---------|
-| "PR is overkill" | PR provides audit trail. Use it. |
-| "I'll review my own code" | Self-review misses issues. Get another pair of eyes. |
-| "History doesn't matter" | History helps debugging. Keep it clean. |
-| "Just merge it" | Verify first. Merge second. |
-
-## Integration with flow-release
-
-This skill is used in `/flow-release` to decide branch handling:
-
-```yaml
-/flow-release execution:
-  1. Verify all gates pass
-  2. Load this skill
-  3. Present options to user
-  4. Execute chosen option
-  5. Update status
-```
-
-## Cross-Reference
-
-- [flow-release.md](../../commands/flow-release.md) - Release command
-- [verification-before-completion](../verification-before-completion/SKILL.md) - Verification skill
-
----
-
-**[PROTOCOL]**: 变更时更新此头部，然后检查 CLAUDE.md

package/.claude/skills/domain/receiving-review/SKILL.md

@@ -1,153 +0,0 @@
----
-name: flow-receiving-review
-description: "Handle code review feedback with technical rigor. Don't blindly agree - verify before implementing."
----
-
-# Flow Receiving Review - 处理代码审查反馈
-
-## The Iron Law
-
-```
-VERIFY FEEDBACK BEFORE IMPLEMENTING - DON'T BLINDLY AGREE
-```
-
-## Overview
-
-When receiving code review feedback, maintain technical rigor. Reviewers can be wrong. Your job is to:
-1. Understand the feedback
-2. Verify it's correct
-3. Then implement (or push back)
-
-## The Process
-
-### Step 1: Understand the Feedback
-
-```yaml
-For each comment:
-  1. Read completely - don't skim
-  2. Identify the concern:
-     - Is it a bug?
-     - Is it a style preference?
-     - Is it a performance issue?
-     - Is it a security concern?
-  3. If unclear → ASK for clarification
-     - "Could you elaborate on why X is problematic?"
-     - "What specific scenario does this address?"
-```
-
-### Step 2: Verify the Feedback
-
-```yaml
-Before implementing ANY change:
-  1. Is the feedback technically correct?
-     - Does the suggested change actually fix the issue?
-     - Could it introduce new problems?
-
-  2. Does it align with project standards?
-     - Check Constitution
-     - Check existing patterns
-
-  3. Is there evidence?
-     - Can you reproduce the issue?
-     - Does the suggested fix work?
-
-If feedback seems wrong:
-  → Don't silently disagree
-  → Don't blindly implement
-  → Respond with your analysis
-```
-
-### Step 3: Respond Appropriately
-
-```yaml
-If feedback is correct:
-  → Acknowledge: "Good catch, fixing now"
-  → Implement the fix
-  → Verify the fix works
-
-If feedback is unclear:
-  → Ask: "Could you clarify what you mean by X?"
-  → Don't guess the intent
-
-If feedback seems incorrect:
-  → Explain your reasoning
-  → Provide evidence
-  → "I considered X, but Y because Z. What do you think?"
-
-If feedback is a preference (not a bug):
-  → Discuss trade-offs
-  → Defer to project standards if they exist
-```
-
-## Rationalization Prevention
-
-| Excuse | Reality |
-|--------|---------|
-| "Reviewer knows better" | Reviewers make mistakes. Verify. |
-| "Just do what they say" | Blind compliance = poor code. |
-| "Don't want to argue" | Technical discussion ≠ argument. |
-| "It's faster to just change it" | Wrong changes waste more time. |
-| "They'll reject if I push back" | Good reviewers appreciate rigor. |
-
-## Red Flags - STOP
-
-If you find yourself:
-- Implementing changes you don't understand
-- Agreeing with feedback you think is wrong
-- Not asking clarifying questions
-- Making changes without verifying they work
-
-**STOP. Understand first. Verify second. Implement third.**
-
-## Response Templates
-
-### Agreeing with Feedback
-```
-Good catch! You're right that [issue]. I've updated [file] to [fix].
-Verified by running [test/command].
-```
-
-### Asking for Clarification
-```
-I want to make sure I understand correctly. Are you suggesting [interpretation]?
-If so, I'm wondering about [concern]. Could you elaborate?
-```
-
-### Respectfully Disagreeing
-```
-I considered [suggestion], but I went with [current approach] because:
-1. [Reason 1]
-2. [Reason 2]
-
-The trade-off is [X]. What do you think about [alternative]?
-```
-
-### Requesting Evidence
-```
-I'm having trouble reproducing [issue]. Could you share:
-- Steps to reproduce
-- Expected vs actual behavior
-- Environment details
-```
-
-## Integration with flow-review
-
-This skill is used in `/flow-review` when processing reviewer feedback:
-
-```yaml
-After receiving review:
-  1. Load this skill
-  2. Process each comment using the 3-step process
-  3. Respond appropriately
-  4. Track changes in EXECUTION_LOG.md
-```
-
-## Cross-Reference
-
-- [flow-review.md](../../commands/flow-review.md) - Two-stage review command
-- [spec-reviewer.md](../../agents/spec-reviewer.md) - Spec compliance agent
-- [code-quality-reviewer.md](../../agents/code-quality-reviewer.md) - Quality review agent
-
----
-
-**[PROTOCOL]**: 变更时更新此头部，然后检查 CLAUDE.md

package/.claude/skills/domain/tdd/SKILL.md

@@ -1,218 +0,0 @@
----
-name: flow-tdd
-description: "Enforces TDD Iron Law in flow-dev. NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST."
----
-
-# Flow TDD - Test-Driven Development Enforcement
-
-## The Iron Law
-
-```
-NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST
-```
-
-This is NON-NEGOTIABLE. No exceptions. No "just this once."
-
-## The TDD Cycle
-
-```
-RED:    Write a failing test
-        → Run it
-        → Confirm it FAILS
-        → If it passes immediately → ERROR (invalid test)
-
-GREEN:  Write minimal code to pass
-        → Only enough to make the test pass
-        → No extra features
-        → No "while I'm here" additions
-
-REFACTOR: Clean up
-        → Keep tests green
-        → Improve structure
-        → Remove duplication
-```
-
-## Enforcement in flow-dev
-
-### Phase 2: Tests First
-
-```yaml
-TASKS.md Phase 2 (Tests):
-  - Write contract tests
-  - Write integration tests
-  - Write unit tests
-  - Run all tests → ALL MUST FAIL
-
-⚠️ TEST VERIFICATION CHECKPOINT:
-  → Run: npm test (or equivalent)
-  → Expected: All new tests FAIL
-  → If any test passes immediately → STOP
-  → Passing test = invalid test or code already exists
-```
-
-### Phase 3: Implementation
-
-```yaml
-TASKS.md Phase 3 (Implementation):
-  - Implement to make tests pass
-  - One test at a time
-  - Minimal code only
-
-After each implementation:
-  → Run tests
-  → Verify previously failing test now passes
-  → Verify no regressions
-```
-
-## What If Code Already Exists?
-
-If you've written code before tests:
-
-```yaml
-Option A: DELETE AND RESTART (Recommended)
-  1. Delete the implementation code
-  2. Keep only the interface/contract
-  3. Write failing tests
-  4. Re-implement with TDD
-
-Option B: WRITE TESTS THAT FAIL FIRST
-  1. Comment out the implementation
-  2. Write tests
-  3. Run tests → verify they fail
-  4. Uncomment implementation
-  5. Run tests → verify they pass
-
-NEVER: Keep code and write passing tests
-  → This is "testing after" disguised as TDD
-  → Tests that pass immediately prove nothing
-```
-
-## Rationalization Prevention
-
-| Excuse | Reality |
-|--------|---------|
-| "Too simple to test" | Simple code breaks. Test takes 30 seconds. |
-| "I'll test after" | Tests passing immediately prove nothing. |
-| "Tests after achieve same goals" | Tests-after = "what does this do?" Tests-first = "what should this do?" |
-| "Already manually tested" | Ad-hoc ≠ systematic. No record, can't re-run. |
-| "Deleting X hours is wasteful" | Sunk cost fallacy. Keeping unverified code is technical debt. |
-| "Keep as reference, write tests first" | You'll adapt it. That's testing after. Delete means delete. |
-| "Need to explore first" | Fine. Throw away exploration, start with TDD. |
-| "Test hard = design unclear" | Listen to test. Hard to test = hard to use. |
-| "TDD slows me down" | TDD faster than debugging. Pragmatic = test-first. |
-| "This is different because..." | No. This is rationalization. Follow the law. |
-| "Spirit not letter" | Violating letter IS violating spirit. No loopholes. |
-| "I'm being pragmatic, not dogmatic" | TDD IS pragmatic. Shortcuts = debugging in production = slower. |
-| "Just this once" | No exceptions. Rules exist for this exact moment. |
-
-## Red Flags - STOP
-
-If you find yourself:
-- Writing code before tests
-- Tests passing immediately
-- Saying "just this once"
-- Keeping "exploration" code
-- Writing tests that describe existing code
-
-**STOP. Delete the code. Write the test first.**
-
-## Test Quality Requirements
-
-```yaml
-Good Tests:
-  ✅ Test behavior, not implementation
-  ✅ Use realistic data
-  ✅ Cover edge cases
-  ✅ Independent (no shared state)
-  ✅ Fast (< 1 second each)
-  ✅ Descriptive names
-
-Bad Tests (Cheater Tests):
-  ❌ assert True
-  ❌ assert result is not None
-  ❌ Mock everything, test nothing
-  ❌ Test implementation details
-  ❌ Depend on execution order
-```
-
-## Error Recording Protocol
-
-当测试失败或构建错误发生时，必须立即记录到 ERROR_LOG.md:
-
-```yaml
-Error Recording Workflow:
-  1. Capture Error Context:
-     - Phase (flow-dev / T###)
-     - Error Type (Test Failure | Build Error | Runtime Error)
-     - Full error message
-     - Timestamp
-
-  2. Create ERROR_LOG.md if not exists:
-     → Use .claude/docs/templates/ERROR_LOG_TEMPLATE.md
-     → Location: devflow/requirements/${REQ_ID}/ERROR_LOG.md
-
-  3. Append Error Record:
-     ## [TIMESTAMP] E###: TITLE
-     **Phase**: flow-dev / T###
-     **Error Type**: Test Failure
-     **Error Message**:
-     ```
-     [完整错误信息]
-     ```
-     **Root Cause**: [分析后填写]
-     **Resolution**: [解决后填写]
-     **Prevention**: [可选]
-
-  4. Debug with Error Context:
-     → Read ERROR_LOG.md for similar past errors
-     → Apply attention refresh (Protocol 4)
-     → Fix the root cause, not symptoms
-
-  5. Update Record After Fix:
-     → Fill Root Cause
-     → Fill Resolution
-     → Add Prevention if applicable
-```
-
-### Error Recording Example
-
-```markdown
-## [2026-01-08T14:30:00] E001: Test Failure - User Login Validation
-
-**Phase**: flow-dev / T005
-**Error Type**: Test Failure
-**Error Message**:
-\`\`\`
-FAIL src/auth/login.test.ts
-  × should reject invalid email format
-    Expected: false
-    Received: true
-\`\`\`
-
-**Root Cause**: 正则表达式 `/^.+@.+$/` 过于宽松，接受了 `user@` 这样的无效邮箱
-**Resolution**: 更新正则为 `/^[^\s@]+@[^\s@]+\.[^\s@]+$/` 要求至少有域名和顶级域
-**Prevention**: 扩充测试用例，添加边界情况（无域名、无顶级域、特殊字符等）
-```
-
-## Integration with Constitution
-
-- **Article I**: Complete implementation includes tests
-- **Article VI**: TDD Mandate (this skill)
-- **Article IX**: Integration-first testing
-
-## Integration with Attention Refresh
-
-- **Protocol 4**: Error Recovery 时读取 ERROR_LOG.md
-- 避免重复犯相同错误
-- 从历史错误中学习
-
-## Cross-Reference
-
-- [flow-attention-refresh](../flow-attention-refresh/SKILL.md) - Protocol 4
-- [ERROR_LOG_TEMPLATE.md](../../docs/templates/ERROR_LOG_TEMPLATE.md)
-- [rationalization-library.md](../../rules/rationalization-library.md#article-vi-test-first-development---rationalization-table)
-- [project-constitution.md](../../rules/project-constitution.md#article-vi-test-first-development-测试优先开发)
-
----
-
-**[PROTOCOL]**: 变更时更新此头部，然后检查 CLAUDE.md

package/.claude/skills/domain/verification/SKILL.md

@@ -1,158 +0,0 @@
----
-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
-
-This skill enforces a critical discipline: **never claim completion without fresh verification evidence**.
-
-The most common failure mode for AI agents is claiming success without actually verifying. This skill prevents that by requiring explicit verification steps before any completion claim.
-
-## The Iron Law
-
-```
-NO COMPLETION CLAIMS WITHOUT FRESH VERIFICATION EVIDENCE
-```
-
-## The Process
-
-### Before ANY Completion Claim
-
-```
-1. IDENTIFY: What command proves this claim?
-   → "Tests pass" requires: npm test / pytest / go test
-   → "Build succeeds" requires: npm run build / make
-   → "Lint clean" requires: npm run lint / eslint
-   → "Type check passes" requires: tsc --noEmit / mypy
-
-2. RUN: Execute the FULL command (fresh, complete)
-   → Not cached results
-   → Not partial output
-   → Not "I ran it earlier"
-
-3. READ: Full output, check exit code, count failures
-   → Exit code 0 = success
-   → Exit code non-zero = failure
-   → Count actual pass/fail numbers
-
-4. VERIFY: Does output confirm the claim?
-   → "All tests pass" = 0 failures in output
-   → "Build succeeds" = no errors, artifacts created
-   → "No lint errors" = 0 problems found
-
-5. ONLY THEN: Make the claim with evidence
-   → Quote the relevant output
-   → Include exit code
-   → Show pass/fail counts
-```
-
-## Verification Commands by Context
-
-### Flow Exit Gates
-
-| Flow | Verification Command | Success Criteria |
-|------|---------------------|------------------|
-| /flow-prd | `validate-constitution --type prd` | Exit 0, no violations |
-| /flow-epic | `validate-constitution --type epic` | Exit 0, no violations |
-| /flow-dev | `npm test && npm run build` | All tests pass, build succeeds |
-| /flow-qa | `npm test && npm run lint` | All pass, no blockers |
-| /flow-release | `gh pr checks` | All checks pass |
-
-### Common Development Tasks
-
-| Claim | Required Verification |
-|-------|----------------------|
-| "Tests pass" | Run full test suite, show output |
-| "Build succeeds" | Run build command, show output |
-| "Lint clean" | Run linter, show 0 errors |
-| "Type check passes" | Run type checker, show output |
-| "No regressions" | Run affected tests, compare before/after |
-| "Bug fixed" | Show failing test → fix → passing test |
-
-## Rationalization Prevention
-
-| Excuse | Reality |
-|--------|---------|
-| "I just ran it" | Run it again. Fresh evidence required. |
-| "It was passing before" | Before ≠ now. Verify current state. |
-| "The change is trivial" | Trivial changes break things. Verify. |
-| "I'm confident it works" | Confidence ≠ evidence. Run the command. |
-| "Tests are slow" | Slow tests > broken production. Run them. |
-| "I'll verify after commit" | Verify BEFORE commit. Always. |
-| "The CI will catch it" | You catch it first. Don't waste CI cycles. |
-| "It's just documentation" | Doc changes can break builds. Verify. |
-
-## Red Flags - STOP
-
-If you find yourself:
-- Saying "should work" without running verification
-- Claiming "tests pass" without showing output
-- Saying "I believe" instead of "I verified"
-- Skipping verification "just this once"
-- Trusting cached or stale results
-
-**STOP. Run the verification command. Show the evidence.**
-
-## Evidence Format
-
-When claiming completion, always include:
-
-```markdown
-## Verification Evidence
-
-**Command**: `npm test`
-**Exit Code**: 0
-**Output Summary**:
-- Tests: 42 passed, 0 failed
-- Coverage: 85%
-- Duration: 12.3s
-
-**Conclusion**: All tests pass. Ready for commit.
-```
-
-## Integration with CC-DevFlow
-
-### Every Flow Exit Gate
-
-```yaml
-Exit Gate Verification:
-  1. Identify required verification commands
-  2. Run each command fresh
-  3. Capture full output
-  4. Verify success criteria met
-  5. Document evidence in EXECUTION_LOG.md
-  6. Only then proceed to next stage
-```
-
-### Task Completion
-
-```yaml
-Task Completion Verification:
-  1. Run task-specific tests
-  2. Verify acceptance criteria met
-  3. Show evidence in task completion message
-  4. Mark task complete only with evidence
-```
-
-## The Discipline
-
-This skill is about **intellectual honesty**. It's easy to believe something works. It's harder to prove it.
-
-The discipline is:
-1. **Assume nothing** - Don't trust memory or intuition
-2. **Verify everything** - Run the actual commands
-3. **Show evidence** - Quote output, not beliefs
-4. **Fresh results only** - No stale or cached data
-
-## Cross-Reference
-
-- Constitution Article I: Quality First (complete implementation)
-- Constitution Article VI: Test-First Development (TDD)
-- rationalization-library.md: Cross-Article rationalizations
-
----
-
-**[PROTOCOL]**: 变更时更新此头部，然后检查 CLAUDE.md