cc-devflow 4.2.0 → 4.4.1

package/.claude/skills/domain/attention-refresh/SKILL.md

@@ -1,170 +0,0 @@
----
-name: flow-attention-refresh
-description: "注意力刷新协议。在关键时刻强制读取核心文档，防止目标遗忘。被 flow-dev, flow-ralph 等命令引用。"
----
-
-# Flow Attention Refresh - 注意力刷新协议
-
-## Overview
-
-解决 "Lost in the Middle" 效应：当上下文过长时，原始目标被"推出"注意力窗口。
-
-```
-问题:
-上下文开始: [原始目标 - 距离很远，被"遗忘"]
-     ↓
-... 50+ 工具调用 ...
-     ↓
-上下文末尾: [最近的工具输出 - 在注意力窗口]
-
-解决:
-在关键时刻强制读取目标文档 → 将目标"拉回"注意力窗口
-```
-
-## The Iron Law
-
-```
-BEFORE MAJOR DECISION → READ GOAL FILES → THEN ACT
-```
-
-## Refresh Protocols
-
-### Protocol 1: Flow Entry (每个 flow-* 命令开始)
-
-**触发点**: 任何 `/flow-*` 命令的 Entry Gate
-
-**动作**:
-```yaml
-read:
-  - BRAINSTORM.md "成功标准" 章节
-  - TASKS.md 当前阶段任务列表
-focus: 本次命令要达成什么？
-```
-
-**实现**: 已由现有 Brainstorm Alignment Check 覆盖
-
----
-
-### Protocol 2: Task Start (flow-dev 每个任务开始)
-
-**触发点**: `flow-dev` TDD 循环中，每个任务执行前
-
-**动作**:
-```yaml
-read:
-  - TASKS.md 当前任务 T### 段落 + DoD
-  - quickstart.md 相关命令
-focus: 这个任务的验收标准是什么？
-```
-
-**实现位置**: flow-dev.md 阶段 3 TDD 循环
-
-**代码片段**:
-```markdown
-**注意力刷新** (Protocol 2):
-→ Read: TASKS.md 当前任务 T### 段落
-→ Focus: 任务目标和 DoD
-→ Then: 开始执行任务
-```
-
----
-
-### Protocol 3: Ralph Iteration (Ralph 循环每次迭代)
-
-**触发点**: `/flow-ralph` 每次迭代开始
-
-**动作**:
-```yaml
-read:
-  - TASKS.md 第一个未完成任务
-  - ERROR_LOG.md 最近 5 条记录
-focus: 下一步行动 + 避免重复错误
-```
-
-**实现位置**: flow-ralph.md Ralph Loop 开始处
-
-**代码片段**:
-```markdown
-**注意力刷新** (Protocol 3):
-→ Read: TASKS.md 找到第一个 `- [ ]` 任务
-→ Read: ERROR_LOG.md 最近 5 条（如存在）
-→ Focus: 下一步行动是什么？有什么错误需要避免？
-→ Then: 执行任务
-```
-
----
-
-### Protocol 4: Error Recovery (遇到错误后)
-
-**触发点**: 测试失败、构建错误、运行时异常后
-
-**动作**:
-```yaml
-read:
-  - ERROR_LOG.md 当前错误记录
-  - TASKS.md 当前任务定义
-focus: 错误根因 + 解决方案
-```
-
-**实现位置**: flow-tdd skill 错误处理部分
-
-**代码片段**:
-```markdown
-**错误恢复刷新** (Protocol 4):
-→ Record: 将错误追加到 ERROR_LOG.md
-→ Read: ERROR_LOG.md 当前错误 + 历史相似错误
-→ Read: TASKS.md 当前任务
-→ Focus: 根因分析，避免盲目修复
-→ Then: 有针对性地修复
-```
-
----
-
-## Integration Map
-
-```
-现有机制:
-┌──────────────────────────────────────┐
-│ flow-brainstorming skill             │
-│ ↓ 触发于 /flow-init                  │
-│ ↓ 输出 BRAINSTORM.md                 │
-└──────────────────────────────────────┘
-              ↓
-┌──────────────────────────────────────┐
-│ Brainstorm Alignment Check           │
-│ ↓ 在每个 flow-* Entry Gate           │
-│ ↓ 读取 BRAINSTORM.md 验证对齐        │
-│ ↓ = Protocol 1                       │
-└──────────────────────────────────────┘
-
-新增机制:
-┌──────────────────────────────────────┐
-│ flow-attention-refresh skill (本文件) │
-│ ↓ 被 flow-dev, flow-ralph 引用       │
-│ ↓ 在更细粒度的时刻刷新注意力          │
-│ ↓ Protocol 2, 3, 4                   │
-└──────────────────────────────────────┘
-```
-
-## Rationalization Prevention
-
-| Excuse | Reality |
-|--------|---------|
-| "我记得目标是什么" | 上下文 50+ 工具调用后，你真的不记得了 |
-| "读文件浪费时间" | 读文件 < 1秒，返工 > 10分钟 |
-| "这个任务很简单" | 简单任务也会偏离目标 |
-| "刚刚读过了" | 每次迭代都要读，这是协议 |
-
-## Red Flags - STOP
-
-如果你发现自己：
-- 开始任务前没有读取 TASKS.md
-- 遇到错误后没有先记录 ERROR_LOG.md
-- Ralph 循环中忘记读取上次错误
-- 做决策时没有参考 BRAINSTORM.md
-
-**STOP。执行对应的 Protocol。**
-
----
-
-**[PROTOCOL]**: 变更时更新此头部，然后检查 CLAUDE.md

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

@@ -1,161 +0,0 @@
----
-name: flow-brainstorming
-description: "在 /flow-init 阶段强制触发，用于捕捉需求的原始意图、探索方案、记录决策。确保后续流程有明确的北极星可追溯。"
----
-
-# Flow Brainstorming - 需求头脑风暴
-
-## Overview
-
-将用户的模糊想法转化为清晰的设计规格，通过自然对话捕捉原始意图。
-
-**核心原则**：需求的原始意图是整个开发流程的「北极星」，后续每个阶段都应能追溯并验证是否偏离。
-
-## The Iron Law
-
-```
-NO FLOW EXECUTION WITHOUT BRAINSTORM ALIGNMENT
-```
-
-每个后续 flow-* 阶段开始前，必须确认与 BRAINSTORM.md 一致。
-
-## The Process
-
-### Phase 1: Understanding the Idea
-
-**一次问一个问题**，不要用多个问题压垮用户：
-
-1. 检查项目现状（文件、文档、最近提交）
-2. 问问题来细化想法：
-   - 优先多选题（更容易回答）
-   - 一个消息只问一个问题
-   - 如果话题需要更多探索，分成多个问题
-3. 聚焦理解：**目的、约束、成功标准**
-
-**问题示例**：
-```
-这个需求主要解决什么问题？
-A) 新增功能
-B) 修复现有问题
-C) 性能优化
-D) 重构/技术债
-```
-
-### Phase 2: Exploring Approaches
-
-- 提出 2-3 种不同方案，说明取舍
-- 给出你的推荐方案及理由
-- 让用户做决策
-
-**方案呈现格式**：
-```markdown
-### 方案 A: {名称} ⭐ 推荐
-
-**描述**: ...
-**优势**: ...
-**劣势**: ...
-**适用场景**: ...
-
-### 方案 B: {名称}
-...
-```
-
-### Phase 3: Presenting the Design
-
-一旦理解了要构建什么：
-
-1. 分段呈现设计（每段 200-300 字）
-2. 每段后询问是否正确
-3. 涵盖：架构、组件、数据流、错误处理、测试
-4. 准备好返回澄清
-
-### Phase 4: Documentation
-
-将验证过的设计写入 BRAINSTORM.md：
-
-```
-devflow/requirements/${REQ}/BRAINSTORM.md
-```
-
-**必须包含**：
-- 原始需求（用户原话，一字不改）
-- 核心问题定义
-- 成功标准
-- 约束条件
-- 方案探索（2-3种）
-- 最终决策及理由
-
-## Key Principles
-
-| 原则 | 说明 |
-|------|------|
-| **一次一个问题** | 不要用多个问题压垮用户 |
-| **多选题优先** | 比开放问题更容易回答 |
-| **YAGNI 无情** | 从所有设计中移除不必要的功能 |
-| **探索替代方案** | 在确定前总是提出 2-3 种方案 |
-| **增量验证** | 分段呈现设计，验证每段 |
-| **灵活应变** | 有不明白的地方就返回澄清 |
-
-## Rationalization Prevention
-
-| Excuse | Reality |
-|--------|---------|
-| "需求已经很清楚了" | Brainstorm 确保没有遗漏假设 |
-| "用户赶时间，跳过吧" | 头脑风暴节省的是后续返工时间 |
-| "这是小需求" | 小需求也有核心问题和成功标准 |
-| "方案很明显" | 明显的选择也需要记录理由 |
-| "已经讨论过了" | 口头讨论不是文档，没有追溯性 |
-| "先做再说" | 先想清楚再做，节省 3 倍时间 |
-
-## Red Flags - STOP
-
-如果你发现自己：
-- 跳过问问题直接开始做
-- 用户说"我知道要什么"就不问了
-- 没有记录方案取舍就选定
-- 没有写 BRAINSTORM.md 就进入下一阶段
-
-**STOP。返回正确流程。**
-
-## Integration with CC-DevFlow
-
-### flow-init 阶段
-
-```yaml
-Entry Gate:
-  - 解析 REQ-ID 和标题
-  - 触发 flow-brainstorming skill
-
-Brainstorm Phase:
-  1. 问问题理解需求（一次一个）
-  2. 探索 2-3 种方案
-  3. 确认最终方案
-  4. 输出 BRAINSTORM.md
-
-Exit Gate:
-  - 验证 BRAINSTORM.md 存在
-  - 验证包含必要章节
-```
-
-### 后续 flow-* 阶段
-
-```yaml
-Entry Gate 添加:
-  step: Brainstorm Alignment Check
-    - read: devflow/requirements/${REQ}/BRAINSTORM.md
-    - verify:
-        - 原始问题是否仍然是解决目标？
-        - 选定方案是否仍然适用？
-        - 约束条件是否发生变化？
-    - if 发现偏离:
-        - ask_user: "发现与原始意图偏离，是否更新 BRAINSTORM.md？"
-        - action: 记录偏离原因，更新文档
-```
-
-## Output Template
-
-参见 `.claude/docs/templates/BRAINSTORM_TEMPLATE.md`
-
----
-
-**[PROTOCOL]**: 变更时更新此头部，然后检查 CLAUDE.md

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

@@ -1,221 +0,0 @@
----
-name: flow-debugging
-description: "4-phase systematic debugging for flow-fix. NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST."
----
-
-# Flow Debugging - Systematic Debugging Method
-
-## The Iron Law
-
-```
-NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST
-```
-
-Bug fixing is not a guessing game. Systematic debugging = faster fixes + fewer regressions.
-
-## The 4-Phase Process
-
-```
-Phase 1: ROOT CAUSE INVESTIGATION (NO FIXES YET)
-    ↓
-Phase 2: PATTERN ANALYSIS
-    ↓
-Phase 3: HYPOTHESIS AND TESTING
-    ↓
-Phase 4: IMPLEMENTATION (TDD)
-```
-
-## Phase 1: Root Cause Investigation
-
-**Iron Law**: In this phase, **NO FIX CODE ALLOWED**.
-
-```yaml
-Step 1: Read Error Completely
-  - Don't skip any details
-  - Record: error type, message, stack trace
-  - Record: when it happens, frequency, impact
-
-Step 2: Stable Reproduction
-  - Find reliable reproduction steps
-  - Record: inputs, environment, preconditions
-  - If can't reproduce → gather more information
-
-Step 3: Check Recent Changes
-  - git log --oneline -20
-  - git diff HEAD~5
-  - Ask: What changed? When did it start failing?
-
-Step 4: Trace Data Flow Backwards
-  - Start from error point
-  - Trace upstream
-  - Find where data goes wrong
-```
-
-**Output**: Root cause hypothesis (evidence-based, not a guess)
-
-## Phase 2: Pattern Analysis
-
-```yaml
-Step 1: Find Working Examples
-  - Where does similar functionality work?
-  - Compare: working vs broken
-
-Step 2: Compare with Reference
-  - What does official documentation say?
-  - How do other projects do it?
-  - What's different?
-
-Step 3: Identify Patterns
-  - Is this a known bug pattern?
-  - Search: error message + framework name
-```
-
-**Output**: Confirmed or refined root cause hypothesis
-
-## Phase 3: Hypothesis and Testing
-
-```yaml
-Step 1: Form Single Hypothesis
-  - "The problem is because X"
-  - Hypothesis must be verifiable
-
-Step 2: Test One Variable at a Time
-  - Change only one factor
-  - Observe result
-  - Record: what changed, what happened
-
-Step 3: 3+ Failed Fixes → STOP
-  - If 3+ fix attempts fail
-  - Stop and question architecture
-  - Problem may be deeper than thought
-```
-
-**Red Flag**: If you're "trying this, trying that", you're guessing, not debugging.
-
-## Phase 4: Implementation (TDD)
-
-**Prerequisite**: Phases 1-3 complete, root cause confirmed
-
-```yaml
-Step 1: Write Failing Test First
-  - Test must reproduce the bug
-  - Run test, confirm it fails
-  - This is your "red light"
-
-Step 2: Implement Single Fix
-  - Fix only the root cause
-  - Don't "while I'm here" other things
-  - Minimal change
-
-Step 3: Verify
-  - Run test, confirm it passes
-  - Run related tests, confirm no regression
-  - Manual verify original issue resolved
-```
-
-## Rationalization Prevention
-
-| Excuse | Reality |
-|--------|---------|
-| "I know where the problem is" | Prove it. Investigate first. |
-| "Quick fix" | Quick fix = quick regression. Systematic debug. |
-| "No time for tests" | No tests = don't know if really fixed. |
-| "Small change" | Small changes can introduce big bugs. Test it. |
-| "Fix first, investigate later" | Fixing without understanding = guessing. |
-| "Let me try this" | "Trying" is not debugging. Form hypothesis, verify it. |
-| "It's obvious" | Nothing is obvious. Prove with evidence. |
-| "I've seen this before" | Every bug is unique. Investigate this one. |
-
-## Red Flags - STOP
-
-If you find yourself:
-- Fixing without reproduction
-- "Trying this, trying that"
-- 3+ failed fix attempts
-- Saying "fixed" without tests
-- Changing many files for one bug
-
-**STOP. Go back to Phase 1. Investigate root cause.**
-
-## Debug Output Template
-
-```markdown
-# Bug Analysis - ${BUG_ID}
-
-## Phase 1: Root Cause Investigation
-
-### Error Details
-- Type: [error type]
-- Message: [error message]
-- Stack: [key stack frames]
-
-### Reproduction
-- Steps: [1, 2, 3...]
-- Frequency: [always/sometimes/rare]
-- Environment: [conditions]
-
-### Recent Changes
-- [relevant commits]
-
-### Data Flow Analysis
-- [where data goes wrong]
-
-### Root Cause Hypothesis
-[Evidence-based hypothesis]
-
-## Phase 2: Pattern Analysis
-
-### Working Example
-[Where similar code works]
-
-### Comparison
-[Difference between working and broken]
-
-### Confirmed Root Cause
-[Refined hypothesis]
-
-## Phase 3: Hypothesis Testing
-
-### Hypothesis
-[Single testable hypothesis]
-
-### Test Results
-| Change | Result |
-|--------|--------|
-| [change 1] | [result] |
-
-## Phase 4: Implementation
-
-### Failing Test
-[Test code that reproduces bug]
-
-### Fix
-[Minimal fix code]
-
-### Verification
-- [ ] Test passes
-- [ ] No regression
-- [ ] Manual verification
-```
-
-## Integration with flow-fix
-
-This skill is the core methodology for `/flow-fix` command:
-
-```yaml
-/flow-fix phases:
-  阶段 1: Root Cause Investigation → This skill Phase 1
-  阶段 2: Pattern Analysis & Planning → This skill Phase 2
-  阶段 3: 修复执行 (TDD) → This skill Phase 3-4
-  阶段 4: 验证与发布 → verification-before-completion
-```
-
-## Cross-Reference
-
-- [flow-fix.md](../../commands/flow-fix.md) - Bug fix command
-- [flow-tdd/SKILL.md](../flow-tdd/SKILL.md) - TDD enforcement
-- [verification-before-completion](../verification-before-completion/SKILL.md) - Verification skill
-
----
-
-**[PROTOCOL]**: 变更时更新此头部，然后检查 CLAUDE.md