Menu
轻量开发流：不落 docs / 不开 worktree / 不进计划模式，直接改代码后自动 /commit 收尾。适合「小函数改一下、说清楚即可」的小改；要文档追踪或计划讨论请走 /start
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
按照 git 规则自动分析变更并提交代码
提交前的自动 review 迭代环：委派子 agent 跑 CC 自带 /code-review（默认 sonnet × medium，并发/难复现等硬 diff 升 opus × high），发现高置信正确性问题就修、跑测试+happy-path 验证、复审，迭代到「运行验证通过 + 无高置信 correctness 问题」才放行。收敛靠运行验证+置信过滤，非 reviewer 挑不出为止。三条硬规则：永远显式传档位、永远委派子 agent、只用两个合法的模型×档位组合。由 /commit 在生成 commit 前自动调用，也可手动跑
为空项目搭建文档骨架（README.md / CLAUDE.md / DEVTREE.md），仅在项目首次开发前调用一次
依据 docs/DEVTREE.md 中作者维护的 Epic 结构，重新生成可视化图表和节点索引
完成当前开发项：撰写 SUMMARY.md，反思跨项目可沉淀流程并可向 claude-code-global 提 issue，关联并关闭 issue（GitHub / GitLab，如有），提交代码
诊断本地分支分叉并按清单引导完成 rebase，历史保持 FF 直线
| name | quick |
| description | 轻量开发流：不落 docs / 不开 worktree / 不进计划模式，直接改代码后自动 /commit 收尾。适合「小函数改一下、说清楚即可」的小改；要文档追踪或计划讨论请走 /start |
| disable-model-invocation | false |
用户调用此 skill 表示要走轻量开发流：一个很小的需求（如改一个小函数、修个笔误、调一处配置），不值得引入 /start + /finish 的重量级文档三件套，只要在 commit message 里把「改了啥、为什么」说清楚即可。
/quick 是「三档开发流」里最轻的一档：
| 档 | 入口 | worktree | docs 三件套 | 计划模式 | 收尾仪式 |
|---|---|---|---|---|---|
| 重（默认） | /start → /finish | ✓ | PROMPT/PLAN/SUMMARY | ✓ | devtree / 沉淀反思 / README / 关 issue / worktree 收尾 |
| 中 | /start --no-worktree → /finish | ✗ | PROMPT/PLAN/SUMMARY | ✓ | 同上（跳 worktree 收尾） |
| 轻 | /quick | ✗ | 无 | 无 | 仅 /commit |
/quick 从头管到尾（直接干 → commit 说清楚就完），不像 start/finish 因中间要人 review PLAN 而拆成两截。
/quick 吗/quick 只服务「一眼能说清、改动局部、无需追踪」的小改。命中以下任一信号，先停下反问用户「是否该走正规 /start」，而不是硬用 quick：
docs/DEVTREE.md）记一个 Epic 节点；/backlog + /start <issue#>）。用户坚持用 quick 或确属小改 → 继续。
args 可含以下项（三者正交、可任意组合），解析后剩余文字即本次小改动的需求描述：
--branch：切一个轻量分支 quick/<描述>（不建 worktree），改完 commit 留在该分支等用户手动合 / 提 PR。默认不带 = 在当前分支直接改。#<issue 号> 或 issue URL：两层用途——① 拉 issue 详情用于理解本次要改什么，进工作上下文指导改动（这样你传 #N 就不必再口述一遍需求）；② issue 号进收尾 commit 的 Closes #N。详情只进上下文、不落成 PROMPT.md 文档（简易流不留档，这正是它与 /start <issue#> 的关键区别）；可传多个。拉 issue 详情（仅当传了 #N / URL）：走 helper python3 $HOME/.claude/scripts/platform_issue.py issue-view <N>（按 git remote get-url origin 自动判定 GitHub / GitLab），从返回的 title / body 理解要改什么。传多个则逐个拉。URL 形态先从中提取 N。
无描述且未传 #N（即既无口述需求、又无 issue 可拉）且无法从对话上下文推断要改什么 → 追问用户改什么，拿到后再继续。
仅当 args 含 --branch：
git symbolic-ref --short refs/remotes/origin/HEAD（得 origin/master → 取末段）；失败则本地探测 main / master。git switch -c quick/<描述>（从当前 HEAD 切，<描述> 从需求描述提炼，不建 worktree）。默认（不带 --branch）：跳过本步，在当前所在分支直接改。若当前分支就是主分支（master / main），允许——简易流小改直提主分支是合理的，但打印一行提示让用户知情（「将在主分支 <主分支> 上直接改并提交」），给用户一个喊停的机会。
按需求描述直接改代码。不写 PROMPT/PLAN/SUMMARY、不建 docs 目录、不进计划模式。
rules/*.md（Python / 前端 / ROS 2 / shell / lark）—— 简易流省的是「文档仪式」，不是「代码规范」。/commit调用 /commit 提交（继承其 lint 门禁 / semantic commit message / Co-authored-by trailer，单一真源不重复实现）：
#N：把 Closes #N 作为额外上下文传给 /commit，让 message body 自然包含（不嵌入 title）。关多个 issue 时每个 #N 各占一行、各带 Closes 关键字（Closes #13 / Closes #20 / …）—— 绝不写成 Closes #13 #20（GitHub / GitLab 的关闭关键字只对紧跟的第一个号生效，后面的不会关，这是 /finish 里踩过的坑）。[round N] 前缀天然不加：/quick 默认既不建 round<N>- 分支、也不建 docs/<N>-*/ 目录 → /commit 的两路轮次探测都判不出 N → 走普通 commit、不加前缀。这是预期行为（简易流本就不进轮次追踪），无需干预。打印一行收尾提示，按分支策略分岔：
--branch：「改动已提交到 quick/<描述> 分支，review 后自行 merge / 提 PR。」<分支名>，是否 git push 由你决定。」（与全局不自动 push 的约定一致。）统一附一句：「如果这个改动其实需要文档追踪 / 计划讨论 / 开发树记节点，下次走 /start。」
/finish 的边界）/quick 一概不碰以下重流程独有的仪式 —— 要这些就走正规 /start + /finish：
/devtree/finish 那套「关联并关闭 issue」——「刻意不做」归档为 wontfix closed issue 等）；/quick 只在你显式传 #<issue> 时顺手在 commit 带 Closes #N，不替你去改 issue 状态