做事方法论（Doing Methodology）
一套把"凭直觉忙活"变成"有纪律地交付"的流程框架。核心理念：先想清楚 → 用对的流程 → 证据说话 → 不过度设计（YAGNI）→ 小步提交。
源自开源的 superpowers 技能体系，已适配 WorkBuddy：用 Skill 工具调用其他技能，用 Agent 工具派发子代理做并行/隔离执行。
四大铁律（不可妥协）
- 技能优先：只要任务有 1% 可能适用某个技能，就先调用它，再做任何回应（包括反问、读文件、写码）。流程型技能（设计、调试）优先于实现型技能。
- 先红后绿：写任何功能/修任何 bug，没有先写出失败测试，不写生产代码。先写的代码一律删掉重来。
- 先根因后修：遇 bug/测试失败，没有完成根因调查，不提修复方案。症状式修复等于失败。
- 证据先行：没有在本条消息里跑过验证命令，不声称"完成/修好/通过"。"should/probably/seems" 一律不算。
标准工作流（按任务类型路由）
任务到来
└─ ① 技能匹配（references/01）：有适用技能先用 Skill 调用
│
├─ 创造性任务（建功能/加组件/改行为）
│ └─ ② 设计（references/02）：brainstorming → 写 spec → writing-plans → 分步计划
│
├─ 执行计划
│ └─ ④ 执行（references/04）：建隔离工作区 → subagent/内联执行 → 收尾决定合并
│
├─ 写代码 / 修 bug
│ └─ ⑤ 质量（references/05）：TDD（先红后绿）+ 系统化调试（先根因）+ 完成前验证
│
├─ 完成前 / 合并前
│ └─ ⑥ 评审（references/06）：请评审抓缺陷 → 收反馈技术核验
│
└─ 想沉淀一套流程
└─ ③ 技能编写（references/03）：用 TDD 方法写/改技能本身
何时用本技能
- 用户说"做个 X""加个功能""改一下行为" → 走 ② 设计，禁止跳过设计直接写码。
- 用户说"这 bug 修一下""测试挂了" → 走 ⑤ 调试，禁止瞎猜硬改。
- 用户说"实现计划""帮我执行" → 走 ④ 执行。
- 用户说"写个技能/把这套流程固化" → 走 ③。
- 任何"搞定了/通过了/修好了"要出口前 → 走 ⑤ 的验证闸门。
通用红线（出现即停，回到流程起点）
- "这问题很简单，不用走流程" —— 简单的事也有根因/也有测试价值。
- "先试着改 X 看看" / "加几处改动跑下测试" —— 一次只改一个变量。
- "我先看下代码/先问问再决定用不用技能" —— 技能检查在一切之前。
- "应该好了吧" / "看起来对了" —— 跑验证，看输出，再说话。
- "就这一次不 TDD/不验证" —— 没有例外。
配套参考（按需加载，不要一次全读）
references/01-entry-invocation.md— 入口与技能调用（using-superpowers 适配）references/02-design.md— 设计与计划（brainstorming + writing-plans）references/03-skill-authoring.md— 技能编写（writing-skills）references/04-execution.md— 执行与开发（并行派发 / 计划执行 / subagent 驱动 / 隔离工作区 / 收尾合并）references/05-quality-debug.md— 质量与调试（TDD / 系统化调试 / 完成前验证）references/06-code-review.md— 代码评审（请评审 / 收评审）
使用方式：读到这里即可。落到具体阶段时，再读对应的 references/<x>.md 拿详细步骤、模板与红线表。不要试图把全部内容塞进单次上下文。
