l864494871

HONGMACC-67B8B41F
祝老板发财

ID: 312
祝老板发财

c3VueDEzMjUxQGdtYWlsLmNvbQ==
谢谢老板

@yicong135 我是项目根目录下的 CLAUDE.md 里指向了此文件

用 @符号指向
@.claude/rules/workflow-superpowers.md
.claude/ 存在于项目根目录

我是建了个 rule ，workflow-superpowers.md 目前感觉还行。根据任务大小自动启动路径
内容如下
`
# 工作流路由

## 1. 任务分流

### Fast Path

适用于：

- 单文件修改
- 明确 bug
- 小范围配置调整
- 边界清晰的文案或规则修订
- 可直接完成并做定向验证的小改动

要求：

- 直接执行
- 约束（不可跳过）：任何 Bash 调用前，必须依据 Memory 中 `critical_rules` 逐条校验即将执行的命令。
如果命令包含被禁操作（如 `rm`、`rm -rf`、修改 Git 状态的命令），必须：
1. 改用替代方案（删除 → `mv` 至回收站 `~/.aicode.tmp/{yyyy-MM-dd}/{HH:mm}/`）
2. 如无可用替代方案，向用户报告冲突，请求指示
3. 不得在未解决冲突的情况下继续当前路径
- 做定向验证
- 默认采用满足质量要求的最短路径
- 最多只问一个真正关键的问题
- 若现有上下文已足够，就不要重复提问

### Standard Path

适用于：

- 多文件修改
- 边界基本清晰，但需要先梳理现状
- 需要对现有结构做局部调整
- 中等复杂度实现，仍可用短路径收敛

要求：

- 先梳理上下文
- 明确改动边界、风险和验证方式
- 分步执行并持续验证
- 优先使用轻量已安装的 `planning-with-files` skill ，而不是先产出重文档
- 根据任务进行情况，维护`planning-with-files` skill 衍生的规划文件，衍生的规划文件里最新产出倒序新增

### Heavy Path

适用于：

- 新功能
- 跨模块重构
- 公共 API 变更
- 三步以上的复杂任务
- 高不确定性或高破坏性任务
- 涉及共享逻辑、持久化、并发、schema 或根配置的改动

要求：

- 进入更重的规划流程
- 先设计，再实施
- 必要时拆分阶段产物和确认点
- 在实现前明确验证门禁和回退边界
- 启动 superpowers`writing-plans`产出 plan,进度与发现维护在`planning-with-files` skill 衍生的规划文件，衍生的规划文件里最新产出倒序新增

## 2. 使用 superpowers 的原则

- superpowers 是工具，不是默认仪式
- 默认采用“满足质量要求的最短路径”
- 能直接完成并验证的，不升级为更重流程
- 能用轻量 `planning-with-files` 解决的问题，不升级为重文档流程
- 轻量任务默认不产出独立 design / spec / plan ，除非用户明确要求、项目规则要求，或确有长期协作价值
- 若用户要求持续推进且风险可控，可在说明假设后继续，不因无谓确认中断

## 3. 流程升级 / 降级

### 升级到更重流程

出现下列情况时，应从 Fast Path / Standard Path 升级：

- 影响边界超出初始判断
- 涉及公共 API 、shared contract 、shared types 、schema 、持久化、并发或共享逻辑
- 需求仍不清晰，无法靠现有上下文收敛
- 验证覆盖不足，无法支持完成声明
- 任务已演变为中大型实现或重构

### 降级到更轻流程

出现下列情况时，可从 Heavy Path / Standard Path 降级：

- 改动局部且边界清晰
- 不涉及共享核心逻辑
- 验证直接、成本低
- 补长计划或补重流程的成本明显高于收益
- 问题已经收敛为单点修复

## 4. 并行与子代理

- 默认先判断是否适合并行；不适合则串行
- 只有在任务能自然拆分为 2-4 个边界清晰、可独立验证、没有明显写冲突的子任务时，才适合并行
- 若根因未明、改动集中在少数核心文件，或拆分后整合成本更高，则不要为了并行而并行

**禁止多个子代理同时修改：**

- `package.json`
- lockfile
- 公共 contract / shared types
- schema / migration
- 全局依赖
- 根配置
- CI
- 同一路由总入口
- 应用总入口
- 环境模板

## 5. 交付门禁

在声明“完成”之前，必须满足：

1. 没有验证证据时，不声称完成
2. 不伪造命令输出、测试结果或退出码
3. 关键验证无法执行时，明确说明阻塞原因
4. 需要用户承担风险的动作，先确认再做
5. 若验证不足，只能降低完成度表述，不能把“未验证”说成“已完成”
6. 能做局部验证时，先给出最贴近本次改动的验证结果
7. 任何涉及 2 个或以上文件的改动，或在 `constants.ts`、`composables`、`types/` 目录中新增/修改，必须在交付前对照 `persona-linus.md` 的审查顺序自查
8. [品味自评核验] （不可跳过）
如果本次改动触及第 7 条的范围，必须检查对话末尾是否已输出 [品味自评] 结论。
如果没有，在交付前补充输出。这条检查的是"规则是否被执行了"，而不是"规则是否存在"。

`

@happytaoer 你链接 ide ，它改动完会直接弹出 diff ，供你选择留或者取消的啊。

刚好相反，不够苦不够浓的话完全喝不下去。某迪的金奖深烘加浓美式 YYDS 。

哈哈哈哈哈，笑死了

DOTA2