quick

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

/quick - Tracked Lightweight Execution

/quick - 轻量级跟踪执行

Operator Context

操作者背景

This skill implements the Quick tier from the five-tier task hierarchy (Fast > Quick > Simple > Medium > Complex). It fills the gap between zero-ceremony

/fast

(1-3 edits, no plan) and full-ceremony Simple+ (task_plan.md, agent routing, quality gates). Quick tasks get a lightweight plan and tracking without the overhead of the full pipeline.

The key design principle is composable rigor: the base mode is minimal (plan + execute), and users add process incrementally via flags rather than getting all-or-nothing ceremony.

该技能实现了五级任务层级（Fast > Quick > Simple > Medium > Complex）中的Quick层级。它填补了无仪式感的

/fast

（1-3次编辑，无规划）和全仪式感的Simple+（task_plan.md、Agent路由、质量关卡）之间的空白。Quick任务可获得轻量级规划和跟踪，无需完整流水线的开销。

核心设计原则是可组合严谨性：基础模式极简（规划+执行），用户可通过标志逐步添加流程，而非被迫接受全量仪式感。

Hardcoded Behaviors (Always Apply)

硬编码行为（始终生效）

CLAUDE.md Compliance: Read and follow repository CLAUDE.md before execution.
Task ID Assignment: Every quick task gets a unique ID in YYMMDD-xxx format (Base36 sequence). This enables tracking and cross-referencing.
Inline Plan: Create a brief inline plan (not a full task_plan.md) before executing. The plan is 3-5 lines: what changes, which files, why. This is the minimum viable plan — enough to catch misunderstandings before editing.
STATE.md Logging: Log task ID, description, status, and commit hash to STATE.md.
Branch Safety: Create a feature branch if on main/master.
Commit After Execute: Every quick task ends with a commit.
No Parallel Execution: Quick tasks are single-threaded. If parallelism is needed, upgrade to Simple+.

CLAUDE.md 合规性：执行前阅读并遵循仓库的CLAUDE.md。
任务ID分配：每个Quick任务都会获得一个YYMMDD-xxx格式的唯一ID（Base36序列），用于跟踪和交叉引用。
内联规划：执行前创建简短的内联规划（而非完整的task_plan.md）。规划为3-5行：修改内容、涉及文件、修改原因。这是最小可行规划——足以在编辑前发现误解。
STATE.md 日志记录：将任务ID、描述、状态和提交哈希记录到STATE.md。
分支安全：若当前在main/master分支，则创建功能分支。
执行后提交：每个Quick任务最终都会执行提交操作。
无并行执行：Quick任务为单线程。若需要并行执行，请升级到Simple+层级。

Default Behaviors (ON unless disabled)

默认行为（除非禁用否则开启）

Feature Branch Per Task: Create
```
quick/<task-id>-<description>
```
branch for each task. This keeps quick work isolated and reviewable.
Conventional Commits: Use conventional commit format.
Edit Tracking: Count edits for scope awareness (warn at 10+, suggest upgrade at 15+).

每个任务对应一个功能分支：为每个任务创建
```
quick/<task-id>-<description>
```
分支，使快速工作独立且可评审。
规范化提交：使用规范化提交格式。
编辑跟踪：统计编辑次数以感知范围（达到10次时发出警告，达到15次时建议升级）。

Optional Behaviors (OFF unless enabled)

可选行为（除非启用否则关闭）

--discuss
: Add a pre-planning discussion phase to resolve ambiguities before committing to a plan. Use when requirements are unclear or the user says "I'm not sure exactly what I want."
--research
: Add a research phase before planning to understand existing code, read related files, and build context. Use when the change touches unfamiliar code.
--full
: Add plan verification + full quality gates after execution. Use when the change is small but high-risk (auth, payments, data migration).
--no-branch
: Skip feature branch creation, work on current branch. Use when contributing to an existing feature branch.
--no-commit
: Skip the commit step. Use when batching multiple quick tasks into one commit.

--discuss
：添加规划前的讨论阶段，在确定规划前解决歧义。当需求不明确或用户表示「我不确定具体想要什么」时使用。
--research
：添加规划前的调研阶段，了解现有代码、阅读相关文件并构建上下文。当改动涉及不熟悉的代码时使用。
--full
：执行后添加规划验证+完整质量关卡。当改动虽小但风险较高（如认证、支付、数据迁移）时使用。
--no-branch
：跳过功能分支创建，在当前分支工作。适用于为现有功能分支贡献代码时。
--no-commit
：跳过提交步骤。适用于将多个Quick任务批量提交时。

What This Skill CAN Do

该技能可完成的工作

Plan and execute targeted code changes (4-15 file edits)
Track tasks with unique IDs for auditability
Compose rigor levels via flags (--discuss, --research, --full)
Create isolated feature branches per task
Escalate from /fast when scope is exceeded

规划并执行针对性代码改动（4-15次文件编辑）
使用唯一ID跟踪任务以满足可审计性
通过标志组合严谨性级别（--discuss、--research、--full）
为每个任务创建独立的功能分支
当超出/fast的范围时从/fast升级

What This Skill CANNOT Do

该技能不可完成的工作

Spawn subagents or parallel workers (upgrade to Simple+)
Manage multi-component features (use feature lifecycle skills)
Run wave-based parallel execution (use dispatching-parallel-agents)
Replace full task_plan.md planning (that is Simple+ tier)

生成子Agent或并行工作进程（请升级到Simple+）
管理多组件功能（使用功能生命周期技能）
运行波浪式并行执行（使用dispatching-parallel-agents）
替代完整的task_plan.md规划（这是Simple+层级的内容）

Instructions

操作步骤

Phase 0: DISCUSS (only with --discuss flag)

阶段0：讨论（仅在使用--discuss标志时触发）

Goal: Resolve ambiguities before planning.

This phase activates when the user passes

--discuss

or the request contains signals of uncertainty ("not sure", "maybe", "could be", "what do you think").

Step 1: Identify ambiguities

Read the request and list specific questions:

What exactly should change? (if underspecified)
Which approach among alternatives? (if multiple valid paths)
What are the acceptance criteria? (if success is unclear)

Step 2: Present questions

===================================================================
 QUICK DISCUSS: <task summary>
===================================================================

 Before planning, I need to resolve:

 1. <question>
 2. <question>

===================================================================

Wait for user response. Do not proceed until ambiguities are resolved.

GATE: All ambiguities resolved. Proceed to Phase 0.5 or Phase 1.

目标：规划前解决歧义。

当用户传递

--discuss

或请求中包含不确定性信号（如「不确定」「也许」「可能」「你觉得呢」）时，该阶段激活。

步骤1：识别歧义

阅读请求并列出具体问题：

具体需要修改什么？（若描述不明确）
在多个备选方案中选择哪一种？（若存在多种有效路径）
验收标准是什么？（若成功定义不清晰）

步骤2：提出问题

===================================================================
 QUICK DISCUSS: <任务摘要>
===================================================================

 在规划前，我需要解决以下问题：

 1. <问题>
 2. <问题>

===================================================================

等待用户回复。在歧义解决前请勿继续。

关卡：所有歧义已解决。进入阶段0.5或阶段1。

Phase 0.5: RESEARCH (only with --research flag)

阶段0.5：调研（仅在使用--research标志时触发）

Goal: Build understanding of the relevant code before planning.

This phase activates when the user passes

--research

or the task touches code that needs investigation.

Step 1: Identify scope

Determine which files and patterns need reading to understand the change.

Step 2: Read and analyze

Read relevant source files, tests, and configuration. Build a mental model of:

Current behavior
Where the change fits
What might break

Step 3: Summarize findings

Present a brief (3-5 line) summary of what you learned and how it affects the plan.

GATE: Sufficient understanding to plan the change. Proceed to Phase 1.

目标：规划前构建对相关代码的理解。

当用户传递

--research

或任务涉及需要调研的代码时，该阶段激活。

步骤1：确定范围

确定需要阅读哪些文件和模式以理解改动需求。

步骤2：阅读与分析

阅读相关源文件、测试和配置。构建以下心智模型：

当前行为
改动的适配位置
可能会破坏的内容

步骤3：总结调研结果

呈现简短的（3-5行）调研总结，说明学到的内容及其对规划的影响。

关卡：已充分理解改动需求。进入阶段1。

Phase 1: PLAN

阶段1：规划

Goal: Create a lightweight inline plan.

Step 1: Generate task ID

Format:

YYMMDD-xxx

where xxx is Base36 sequential.

To determine the next sequence number:

bash

undefined

目标：创建轻量级内联规划。

步骤1：生成任务ID

格式：

YYMMDD-xxx

，其中xxx为Base36序列。

确定下一个序列编号的方法：

bash

undefined

Check STATE.md for today's tasks to determine next sequence

检查STATE.md中今日的任务以确定下一个序列编号

date_prefix=$(date +%y%m%d)


If STATE.md exists in the repo root, find the highest sequence number for today's date prefix and increment. If no tasks today, start at `001`. Use Base36 (0-9, a-z) for the sequence: 001, 002, ... 009, 00a, 00b, ... 00z, 010, ...

**Step 2: Create inline plan**

Display the plan — do NOT write a task_plan.md file:

=================================================================== QUICK [task-id]: <description>

Plan:

<what to change in file X>
<what to change in file Y>
<why: brief rationale>

Files: <file1>, <file2> Estimated edits: <N>

===================================================================


If estimated edits exceed 15, suggest upgrading:

This task estimates 15+ edits. Consider using /do for full planning and agent routing. Proceed with /quick anyway? [Y/n]


**Step 3: Create feature branch** (unless --no-branch)

```bash
git checkout -b quick/<task-id>-<brief-kebab-description>

GATE: Task ID assigned, plan displayed, branch created. Proceed to Phase 2.

date_prefix=$(date +%y%m%d)


若仓库根目录存在STATE.md，则找到今日日期前缀下的最高序列编号并递增。若今日无任务，则从`001`开始。序列使用Base36（0-9，a-z）：001, 002, ... 009, 00a, 00b, ... 00z, 010, ...

**步骤2：创建内联规划**

显示规划——请勿编写task_plan.md文件：

=================================================================== QUICK [task-id]: <描述>

规划：

<修改文件X的具体内容>
<修改文件Y的具体内容>
<原因：简短理由>

涉及文件：<file1>, <file2> 预计编辑次数：<N>

===================================================================


若预计编辑次数超过15次，建议升级：

该任务预计需要15+次编辑。考虑使用/do进行完整规划和Agent路由。是否仍继续使用/quick？[Y/n]


**步骤3：创建功能分支**（除非使用--no-branch）

```bash
git checkout -b quick/<task-id>-<简短连字符描述>

关卡：任务ID已分配，规划已显示，分支已创建。进入阶段2。

Phase 2: EXECUTE

阶段2：执行

Goal: Implement the plan.

Step 1: Make edits

Execute the changes described in the plan. Track edit count.

Step 2: Scope monitoring

At 10 edits: display a warning — "10 edits reached. Quick tasks typically stay under 15."
At 15 edits: suggest upgrade — "15 edits reached. This may benefit from /do with full planning. Continue? [Y/n]"
No hard cap — the user decides. Quick's scope is advisory, not enforced like Fast's 3-edit gate.

Step 3: Verify changes (base mode)

Run a quick sanity check:

bash

undefined

目标：实现规划内容。

步骤1：进行编辑

执行规划中描述的修改。统计编辑次数。

步骤2：范围监控

达到10次编辑时：显示警告——「已完成10次编辑。Quick任务通常应保持在15次以内。」
达到15次编辑时：建议升级——「已完成15次编辑。该任务可能受益于带完整规划的/do。是否继续？[Y/n]」
无硬限制——由用户决定。Quick的范围是建议性的，不像Fast的3次编辑关卡那样强制。

步骤3：验证改动（基础模式）

运行快速 sanity 检查：

bash

undefined

Check for syntax errors in edited files (language-appropriate)

检查编辑文件的语法错误（根据语言选择合适的命令）

e.g., python3 -m py_compile file.py, go build ./..., tsc --noEmit

例如：python3 -m py_compile file.py, go build ./..., tsc --noEmit


If `--full` flag is set, run the full quality gate instead (see Phase 2.5).

**GATE**: All planned edits complete. Sanity check passes.


若设置了`--full`标志，则改为运行完整质量关卡（见阶段2.5）。

**关卡**：所有规划的编辑已完成。Sanity检查通过。

Phase 2.5: VERIFY (only with --full flag)

阶段2.5：验证（仅在使用--full标志时触发）

Goal: Run full quality gates on the changes.

Step 1: Run tests

bash

undefined

目标：对改动运行完整质量关卡。

步骤1：运行测试

bash

undefined

Run tests for affected packages/modules only

仅运行受影响包/模块的测试

Do not run full test suite unless explicitly requested

除非明确要求，否则不要运行完整测试套件


**Step 2: Lint check**

Run the repo's configured linter on changed files.

**Step 3: Review changes**

```bash
git diff

Review the diff for:

Unintended changes
Missing error handling
Broken imports

GATE: Tests pass, lint clean, diff reviewed. Proceed to Phase 3.


**步骤2：代码检查**

对改动文件运行仓库配置的代码检查工具。

**步骤3：评审改动**

```bash
git diff

评审差异以检查：

意外改动
缺失的错误处理
损坏的导入

关卡：测试通过，代码检查无问题，差异已评审。进入阶段3。

Phase 3: COMMIT

阶段3：提交

Goal: Commit with a clean message.

Step 1: Stage changes

bash

git add <specific-files>

Step 2: Commit

bash

git commit -m "$(cat <<'EOF'
<type>: <description>

Quick task <task-id>
EOF
)"

Include the task ID in the commit body for traceability.

GATE: Commit succeeded. Verify with

git log -1 --oneline

目标：使用清晰的信息提交改动。

步骤1：暂存改动

bash

git add <具体文件>

步骤2：提交

bash

git commit -m "$(cat <<'EOF'
<类型>: <描述>

Quick任务 <task-id>
EOF
)"

在提交正文中包含任务ID以实现可追溯性。

关卡：提交成功。使用

git log -1 --oneline

验证。

Phase 4: LOG

阶段4：日志记录

Goal: Record the task in STATE.md.

Step 1: Update STATE.md

If STATE.md does not exist in the repo root, create it:

markdown

undefined

目标：在STATE.md中记录任务。

步骤1：更新STATE.md

若仓库根目录不存在STATE.md，则创建它：

markdown

undefined

Task State

任务状态

Quick Tasks

Quick任务

Date	ID	Description	Commit	Branch	Tier	Status


Append the new task:

```markdown
| YYYY-MM-DD | <task-id> | <description> | <short-hash> | <branch> | quick | done |

If the task was escalated from

/fast

, note the tier as

fast->quick

Step 2: Display summary

===================================================================
 QUICK [task-id]: COMPLETE
===================================================================

 Description: <description>
 Files edited: <N>
 Commit: <hash> on <branch>
 Flags: <--discuss, --research, --full, or "base">
 Logged: STATE.md

 Next steps:
   - Push: /pr-sync
   - More work: /quick <next task>
   - Merge to parent: git merge quick/<task-id>-...

===================================================================

日期	ID	描述	提交	分支	层级	状态


追加新任务：

```markdown
| YYYY-MM-DD | <task-id> | <描述> | <短哈希> | <分支> | quick | done |

若任务是从

/fast

升级而来，则将层级标记为

fast->quick

。

步骤2：显示摘要

===================================================================
 QUICK [task-id]: 完成
===================================================================

 描述：<描述>
 编辑文件数：<N>
 提交：<哈希> 位于 <分支>
 标志：<--discuss, --research, --full，或「基础」>
 已记录到：STATE.md

 下一步：
   - 推送：/pr-sync
   - 更多工作：/quick <下一个任务>
   - 合并到父分支：git merge quick/<task-id>-...

===================================================================

Examples

示例

Example 1: Base Mode

示例1：基础模式

User says:

/quick add --verbose flag to the CLI

Generate ID: 260322-001
Plan: add flag definition, wire to handler, update help text (3 edits)
Create branch:
```
quick/260322-001-add-verbose-flag
```
Execute edits, commit, log to STATE.md

用户输入：

/quick add --verbose flag to the CLI

生成ID：260322-001
规划：添加标志定义、连接到处理程序、更新帮助文本（3次编辑）
创建分支：
```
quick/260322-001-add-verbose-flag
```
执行编辑、提交、记录到STATE.md

Example 2: With Research

示例2：带调研

User says:

/quick --research fix the timeout bug in auth middleware

RESEARCH: Read auth middleware, identify timeout source, trace call path
PLAN: change timeout value in config, update middleware to use it (2 edits)
EXECUTE, COMMIT, LOG

用户输入：

/quick --research fix the timeout bug in auth middleware

调研：阅读认证中间件、确定超时来源、跟踪调用路径
规划：修改配置中的超时值、更新中间件以使用该值（2次编辑）
执行、提交、记录

Example 3: Escalated from Fast

示例3：从Fast升级

/fast

hit 3-edit limit while fixing a bug across 5 files.

Quick picks up with context: "Continuing from /fast — 3 files already edited"
PLAN: remaining 2 files to edit
EXECUTE remaining edits, COMMIT all changes, LOG as tier
```
fast->quick
```

/fast

在跨5个文件修复bug时达到3次编辑限制。

Quick承接上下文：「继续从/fast的工作——已编辑3个文件」
规划：剩余2个文件需要编辑
执行剩余编辑、提交所有改动、记录为层级
```
fast->quick
```

Example 4: Full Rigor

示例4：完整严谨性

User says:

/quick --full update payment amount rounding logic

PLAN: identify rounding function, change to banker's rounding
EXECUTE the edit
VERIFY: run payment tests, lint, review diff
COMMIT, LOG

用户输入：

/quick --full update payment amount rounding logic

规划：识别舍入函数、改为银行家舍入法
执行编辑
验证：运行支付测试、代码检查、评审差异
提交、记录

Error Handling

错误处理

Error: Task ID Collision

错误：任务ID冲突

Cause: Two quick tasks started in the same second with the same sequence Solution: Increment the sequence number. If STATE.md is corrupted, scan git log for

Quick task YYMMDD-

patterns to find the true next ID.

原因：在同一秒内启动了两个具有相同序列的Quick任务 解决方案：递增序列编号。若STATE.md损坏，扫描git日志中的

Quick task YYMMDD-

模式以找到正确的下一个ID。

Error: Scope Exceeds Quick Tier

错误：超出Quick层级范围

Cause: Task requires 15+ edits, multiple components, or parallel work Solution: Display upgrade suggestion. If user confirms, continue in quick mode. If user wants full ceremony, invoke

/do

with the original request.

原因：任务需要15+次编辑、多组件或并行工作 解决方案：显示升级建议。若用户确认，继续使用Quick模式。若用户需要全仪式感，使用原始请求调用

/do

。

Error: Test Failure in --full Mode

错误：--full模式下测试失败

Cause: Quality gate found issues with the changes Solution: Fix the failing tests. If the fix requires significant additional work, note it in STATE.md and suggest a follow-up

/quick

task rather than expanding scope.

原因：质量关卡发现改动存在问题 解决方案：修复失败的测试。若修复需要大量额外工作，在STATE.md中记录并建议后续使用

/quick

任务，而非扩大当前任务范围。

Error: Branch Conflict

错误：分支冲突

Cause: Branch

quick/<task-id>-...

already exists Solution: Increment the task ID sequence number and try again.

原因：

quick/<task-id>-...

分支已存在 解决方案：递增任务ID序列编号并重试。

Anti-Patterns

反模式

Anti-Pattern 1: Skipping the Plan

反模式1：跳过规划

What it looks like: Jumping straight to edits without displaying the inline plan Why wrong: The plan catches misunderstandings before they become wrong edits. It takes 10 seconds and saves minutes. Do instead: Always display the inline plan. Even for obvious tasks — it confirms alignment.

表现：直接进行编辑而不显示内联规划 错误原因：规划可在错误编辑前发现误解。只需10秒，却能节省数分钟时间。 正确做法：始终显示内联规划。即使是明显的任务——这可确保对齐。

Anti-Pattern 2: Using Quick for Features

反模式2：使用Quick开发功能

What it looks like: Building a multi-component feature as a series of

/quick

tasks Why wrong: Features need design docs, coordinated implementation, and integration testing. Quick tasks are isolated units. Do instead: Use the feature lifecycle (

/feature-design

/feature-plan

/feature-implement

表现：将多组件功能拆分为一系列

/quick

任务开发 错误原因：功能需要设计文档、协调实现和集成测试。Quick任务是独立单元。 正确做法：使用功能生命周期（

/feature-design

/feature-plan

/feature-implement

）。

Anti-Pattern 3: Never Using Flags

反模式3：从不使用标志

What it looks like: Always running base

/quick

even when research or verification is clearly needed Why wrong: Base mode assumes you know exactly what to change. When you don't, you make wrong changes faster. Do instead: Use

--research

when touching unfamiliar code,

--discuss

when requirements are unclear,

--full

when the change is high-risk.

表现：即使明显需要调研或验证，也始终运行基础

/quick

错误原因：基础模式假设你完全知道需要修改什么。当你不确定时，会更快地做出错误修改。 正确做法：当涉及不熟悉的代码时使用

--research

，当需求不明确时使用

--discuss

，当改动风险较高时使用

--full

。

Anti-Pattern 4: Using Quick to Avoid Planning

反模式4：使用Quick避免规划

What it looks like: Classifying a Simple+ task as "quick" to skip task_plan.md Why wrong: The inline plan is not a substitute for full planning. Complex tasks need full plans. Do instead: If the task genuinely needs a full plan, use

/do

and let the router classify properly.

表现：将Simple+任务归类为「quick」以跳过task_plan.md 错误原因：内联规划无法替代完整规划。复杂任务需要完整规划。 正确做法：若任务确实需要完整规划，使用

/do

并让路由程序正确分类。

Anti-Rationalization

反合理化

Rationalization	Why It's Wrong	Required Action
"This is quick, no need for a plan"	Quick's inline plan IS the minimum — skipping it means no plan at all	Display the inline plan
"15 edits but it's all simple stuff"	Edit count is a scope signal, not a difficulty signal	Show the upgrade suggestion at 15
"I'll add the task ID later"	Later never comes; untracked tasks are invisible	Assign ID in Phase 1
"No need for a branch, it's small"	Small changes on main break the same as big ones	Create feature branch (or use --no-branch explicitly)
"Skip --research, I know this code"	Confidence != correctness; /fast exists for when you truly know	Use --research when touching unfamiliar code
"Don't need --full for this"	Risk is about impact, not size; a one-line auth change can be catastrophic	Use --full for any security/payment/data change

合理化理由	错误原因	要求动作
「这是快速任务，不需要规划」	Quick的内联规划就是最低要求——跳过它意味着完全没有规划	显示内联规划
「15次编辑但都是简单内容」	编辑次数是范围信号，而非难度信号	在15次编辑时显示升级建议
「我稍后再添加任务ID」	稍后永远不会到来；未跟踪的任务是不可见的	在阶段1分配ID
「不需要分支，改动很小」	主分支上的小改动和大改动一样会破坏代码	创建功能分支（或显式使用--no-branch）
「跳过--research，我了解这段代码」	自信不等于正确；当你真正了解时可以使用/fast	当涉及不熟悉的代码时使用--research
「这个不需要--full」	风险关乎影响而非大小；一行认证改动也可能是灾难性的	任何安全/支付/数据改动都使用--full