quicklisted

用户调用此 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： - ��求需要进计划模式讨论方案、或方案本身有分歧要先对齐； - 需要落 PROMPT/PLAN 供未来追踪，或值得在开发树（`docs/DEVTREE.md`）记一个 Epic 节点； - 涉及多文件的架构改动、跨模块重构； - 对应一个需要长期追踪的 issue（长期可追踪的开发项推荐 `/backlog` + `/start <issue#>`）。 用户坚持用 quick 或确属小改 → 继续。 ## 参数解析 args 可含以下项（三者正交、可任意组合），解析后剩余文字即本次小改动的需求描述： - **`--branch`**：切一个轻量分支 `quick/<描述>`（**不建 worktree**），改完 commit 留在该分支等用户手动合 / 提 PR。默认不带 = 在当前分支直接改。 - **`#<issue 号>` 或 issue URL**：两层用途——① **拉 issue 详情用于理解本次要改什么**，进工作