cs-issue 启动必读 开始任何判断或动作前，先读取 ；缺失则视为骨架不完整，提示先补齐或运行 ，不要回退到外部 AI 入口文件。 修 bug 直觉是"找到错的地方改了完事"，但这个直觉路径反复制造同样的麻烦： 1. 问题描述只在脑子里改完就忘——三个月后 bug 再现没复现步骤留存 2. 根因没分析就动手——改了表面现象深层问题等下次爆发 3. 修复范围扩散——发现一个 bug 顺手改五处引入新问题，无法追溯 4. 没验收闭环——怎么判断改好了？改好了什么？没记录 issue 工作流在"看到问题"和"动手改代码"之间塞缓冲： 本技能不写任何东西，只看当前 issue 走到哪步、决定触发哪个子技能。 --- 文件放哪儿 日期取 发现 / 提报问题当天 定了不动。slug 能一眼看出是什么问题（ 、 ）。 是阶段 3 必出产物 ——无论修复简单还是复杂都要写。它不是仪式，是回溯凭证：没有它下次类似问题来你只能从 git log 反推。 所有 issue 文档带 YAML frontmatter（ 分别为 / / ）便于 按 severity / tags / status 检索。 --- 两条路径 标准路径（问题复杂或根因不明） | 阶段 | 子技能 | 主导 | 产出 | |---|---|---|---| | 1 问题报告 | | 用户描述，AI 引导 | | | 2 根因…