# Quick > 轻量开发流：不落 docs / 不开 worktree / 不进计划模式，直接改代码后自动 /commit 收尾。适合「小函数改一下、说清楚即可」的小改；要文档追踪或计划讨论请走 /start - Skill: `pkulijing/quick` (Agent Skill) - Install (CLI): `npx skillmds@latest add pkulijing/quick` - Raw SKILL.md: https://api.skillmd.com/api/skills/pkulijing/quick/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: pkulijing (https://skillmd.com/u/pkulijing) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/pkulijing/quick --- 用户调用此 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 `）。 用户坚持用 quick 或确属小改 → 继续。 ## 参数解析 args 可含以下项（三者正交、可任意组合），解析后剩余文字即本次小改动的需求描述： - **`--branch`**：切一个轻量分支 `quick/`（**不建 worktree**），改完 commit 留在该分支等用户手动合 / 提 PR。默认不带 = 在当前分支直接改。 - **`#` 或 issue URL**：两层用途——① **拉 issue 详情用于理解本次要改什么**，进工作上下文指导改动（这样你传 `#N` 就不必再口述一遍需求）；② issue 号进收尾 commit 的 `Closes #N`。**详情只进上下文、不落成 PROMPT.md 文档**（简易流不留档，这正是它与 `/start ` 的关键区别）；可传多个。 - **剩余文字**：需求描述。 **拉 issue 详情**（仅当传了 `#N` / URL）：走 helper `python3 $HOME/.claude/scripts/platform_issue.py issue-view `（按 `git remote get-url origin` 自动判定 GitHub / GitLab），从返回的 `title` / `body` 理解要改什么。传多个则逐个拉。URL 形态先从中提取 N。 无描述**且**未传 `#N`（即既无口述需求、又无 issue 可拉）且无法从对话上下文推断要改什么 → 追问用户改什么，拿到后再继续。 ## Step 1：（可选）切轻量分支 **仅当 args 含 `--branch`**： - 探测主分支：`git symbolic-ref --short refs/remotes/origin/HEAD`（得 `origin/master` → 取末段）；失败则本地探测 `main` / `master`。 - 若工作区已有未提交改动 → 提示用户「切分支会带走当前未提交改动」，等用户确认。 - `git switch -c quick/`（从当前 HEAD 切，**不建 worktree**）。短描述从需求描述提炼，**规格与「为什么 ref 位置必须纯 ASCII」同 `/start`，见 `skills/start/references/worktree-create.md`「短描述规格」条**，此处不复述。 **默认（不带 `--branch`）**：跳过本步，在当前所在分支直接改。若当前分支就是主分支（`master` / `main`），**允许**——简易流小改直提主分支是合理的，但打印一行提示让用户知情（「将在主分支 `<主分支>` 上直接改并提交」），给用户一个喊停的机会。 ## Step 2：直接实现 按需求描述直接改代码。**不写 PROMPT/PLAN/SUMMARY、不建 docs 目录、不进计划模式。** - **规则不豁免**：命中语言 / 栈触发条件时照常先 Read 对应 `playbooks/*.md`（Python / 前端 / ROS 2 / shell / lark）—— 简易流省的是「文档仪式」，不是「代码规范」。 - 把「为什么这么改」的关键信息记住，供 Step 3 的 commit message 用（commit message 承载「为什么」，代码本身说清「做了什么」）。 - 若确有必要，可加一行行内注释解释非显然的设计动机（写「当前真相」，不写「本轮 / issue #N」这类演化历史标记）。 ## Step 3：收尾 —— 调用 `/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`** —— 这条硬规则连同它的代价，单一真源在 `skills/finish/SKILL.md` Step 4。 - **`[round N]` 前缀天然不加**：`/quick` 默认既不建 `round` 分支、也不建 `docs/-*/` 目录 → `/commit` 的两路轮次探测都判不出 N → 走普通 commit、不加前缀。**这是预期行为**（简易流本就不进轮次追踪），无需干预。 ## Step 4：轻量收尾提示 打印一行收尾提示，按分支策略分岔： - **`--branch`**：「改动已提交到 `quick/` 分支，review 后自行 merge / 提 PR。」 - **默认**：「已提交到当前分支 `<分支名>`，是否 `git push` 由你决定。」（与全局不自动 push 的约定一致。） 统一附一句：「如果这个改动其实需要文档追踪 / 计划讨论 / 开发树记节点，下次走 `/start`。」 ## 明确不做（与 `/finish` 的边界） `/quick` **一概不碰**以下重流程独有的仪式 —— 要这些就走正规 `/start` + `/finish`： - 不写 SUMMARY.md - 不做跨项目可沉淀流程反思、不向 claude-code-global 提 issue - 不调 `/devtree` - 不做 README review & update - 不主动做 issue 生命周期管理（`/finish` 那套「关联并关闭 issue」——「刻意不做」归档为 `wontfix` closed issue 等）；`/quick` 只在你显式传 `#` 时顺手在 commit 带 `Closes #N`，不替你去改 issue 状态 - 不做 worktree 收尾（rebase / FF merge / 清理 worktree·分支·tag）