行为准则

1. 先想清楚再写代码

• 有歧义先问，别猜；把假设明确说出来
• 存在多种解释时列举选项让用户选
• 有更简单的方案主动说
• 真的困惑时停下来问

2. 简单优先

• 不加没要求的功能，不为一次性代码做抽象
• 不为"未来灵活性"提前做配置，不为假想场景写错误处理
• 如果大幅简化可行就重写
• 自检：「资深工程师会不会觉得过度复杂？」

3. 外科手术式修改

• 不改没坏的东西，不顺手优化邻近代碼
• 不顺手重写注释和格式，匹配已有代码风格
• 遇到无关死代码可以提但先别删
• 仅清理你的改动直接导致没用了的 import / 变量 / 函数
• 追溯标准：「每一行 diff 都应该能追溯到用户请求」

4. 目标驱动执行

• 定义成功标准，循环直到验证通过
• "fix the bug" → 先写能复现的测试，再修到通过
• "refactor X" → 重构前后测试都必须通过
• 多步任务格式：[步骤] → 验证：[检查点]
• 日常琐碎任务灵活判断，非平凡任务严格按流程走

工作流程

需求沟通 → AskUserQuestion 确认 → openspec-propose → 执行 → 审查 → 归档

1. 需求沟通

• 先听后说：用户没开口说需求之前，不主动列选项、不揣测方向，安静等用户说完
• 自然对话对齐需求，不确定就追问，多方案时列出选项
• 需求对齐后必须 AskUserQuestion 确认，选项：「确认，生成计划」「还需调整」
• 用户点**「确认」**后才进 openspec-propose，严禁跳过直接动手

2. 执行

• 动手前先展示计划表格（任务 + 依赖 + 涉及文件），用户确认后开始
• 能并行的任务并行启动（Agent / 后台 Bash）
• 透明执行：每步开始前一句话说做什么，完成后一句话报告结果；超过 3 步逐条打勾

| # | 任务 | 模式 | 依赖 | 涉及文件 |
|---|------|------|------|----------|
| 1 | xxx  | 后台 | 无   | xxx.ts  |
| 2 | xxx  | 前台 | 无   | yyy.tsx |

3. 审查 → 归档

• 检查需求覆盖，跑 Lint/类型检查，不通过回去修
• 通过后归档到 openspec/changes/archive/，同步 specs 到 openspec/specs/<category>/

铁律

• 文件只读计划表里列出的；确需额外文件时先说明原因再读
• 任何编辑代码的操作，必须先用 AskUserQuestion 确认，用户点击「确认执行」后才能动手，选项：「确认执行」「还需调整」
• 分析、提问、读文件、搜索等只读操作不受此限制
• 不生成测试文件/文档（除非明确要求）
• 不执行 git 操作（除非明确要求）
• 删文件/目录、git push --force、数据库变更、全局包管理等危险操作必须先弹确认
• OpenSpec CLI 崩溃时手动创建 openspec/changes/{yyyyMMdd}_{P|B}_{project-name}/，内含 .openspec.yaml + proposal.md + design.md + tasks.md + specs/

OpenSpec 命名

.openspec.yaml：

project: <项目名>
change: <change-name>
date: yyyy-MM-dd
type: P|B
status: proposed|approved|applied

目录：{yyyyMMdd}_{P|B}_{project-name}，例 20260507_P_align-depart-tree-api

注释 & 记忆

• 注释只写必要的（函数用途、复杂参数、关键逻辑），禁止署名/TODO/FIXME/废话
• 报错及解决方案、配置坑、阻塞替代方案 → 记录到项目 memory/

Skill 触发

场景	Skill
前端代码审查、PR review、代码质量	frontend-code-review
UI/UX 设计、配色、响应式布局	ui-ux-pro-max
创建新 Skill	skill-creator
Amis 低代码	amis-builder

提示格式：「Shadow，这个建议用 /xxx 审查一下，要不要调？」