commit

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

commit

提交操作

Commit changes in atomic steps, then finalise and clean up the feature branch when requested.

以原子化步骤提交变更，在用户要求时完成功能分支的收尾与清理工作。

Guardrails

约束规则

Require user confirmation before every commit.
For every atomic commit proposal, always provide both a proposed title and a proposed body before asking for approval.
Keep commits atomic; if a title needs "and", split the change set.
Never mix unrelated files in one commit.
Determine commit
```
type
```
from the actual diff intent, not from branch name, file paths, or habit.
Never use
```
chore
```
for behaviour changes (user-visible flow, API contract, data semantics, bug correction, or security fix).
If a change group contains multiple intents (
```
feat
```
+
```
fix
```
,
```
fix
```
+
```
chore
```
, etc.), split it before proposing.
Never add AI attribution or
```
Co-authored-by
```
trailers unless the user explicitly asks.
Ask for the merge target branch during finalise mode; do not assume
```
main
```
(it may be
```
dev
```
or another branch).
Use
```
review
```
as a quality gate before commit/finalise when needed.
Treat memory capture as built-in: update
```
tasks/memory.md
```
during commit/finalise when durable information emerges; do not rely on a separate memory-only step.
During finalise, bundle tracking updates (PRD archive,
```
tasks/todo.md
```
strikethrough, and memory updates when needed) into one pre-merge finalise commit; if no tracking changes are needed, skip the finalise commit and state why.
During finalise, follow the repository's approved merge strategy and platform constraints; if policy is unclear, ask before merging.
Never delete the base/default branch.
Never delete the currently checked-out branch.
Require explicit user confirmation before deleting local or remote branches.
Do not claim tests passed or checks succeeded without actually running them; if you didn't run it, say so.

每次提交前必须获得用户确认。
对于每个原子化提交提案，在请求确认前必须同时提供建议的标题和正文。
保持提交的原子性；如果标题需要使用“and”，则拆分变更集。
不得在一个提交中混合无关文件。
根据实际代码差异的意图确定提交
```
type
```
，而非分支名称、文件路径或习惯。
行为变更（用户可见流程、API契约、数据语义、bug修复或安全修复）不得使用
```
chore
```
类型。
如果一组变更包含多种意图（
```
feat
```
+
```
fix
```
、
```
fix
```
+
```
chore
```
等），需先拆分再提案。
除非用户明确要求，否则不得添加AI署名或
```
Co-authored-by
```
标记。
在收尾模式下询问合并目标分支；不要默认是
```
main
```
（可能是
```
dev
```
或其他分支）。
必要时，在提交/收尾前使用
```
review
```
作为质量关卡。
内置记忆捕获功能：当出现需要持久化的信息时，在提交/收尾过程中更新
```
tasks/memory.md
```
；不要依赖单独的记忆步骤。
在收尾阶段，将跟踪更新（PRD归档、
```
tasks/todo.md
```
删除线标记、必要时的记忆更新）合并到一个合并前的收尾提交中；如果不需要跟踪变更，说明原因并跳过该收尾提交。
在收尾阶段，遵循仓库认可的合并策略和平台限制；如果策略不明确，合并前需询问用户。
不得删除基础/默认分支。
不得删除当前已检出的分支。
删除本地或远程分支前必须获得用户明确确认。
未实际运行测试或检查的情况下，不得声称测试通过或检查成功；如果未运行，需明确说明。

Commit Message Rules

提交消息规则

Title format (required)

标题格式（必填）

<emoji> <type>: <imperative summary>

```
type
```
must be one of:
```
feat
```
,
```
fix
```
,
```
chore
```
Summary must be short, specific, and imperative (e.g., "add", "fix", "remove", "refactor")
Avoid vague summaries like "update code" or "fix stuff"

<emoji> <type>: <命令式摘要>

```
type
```
必须为以下之一：
```
feat
```
,
```
fix
```
,
```
chore
```
摘要必须简短、具体且为命令式（例如："add"、"fix"、"remove"、"refactor"）
避免模糊的摘要，如"update code"或"fix stuff"

Finalise title (required)

收尾提交标题（必填）

For a finalise commit, require:

🧹 chore: finalise f-## <short-summary>

Keep the summary short and imperative.

对于收尾提交，要求格式为：

🧹 chore: finalise f-## <简短摘要>

摘要需保持简短且为命令式。

Emoji mapping (default)

表情符号映射（默认）

```
feat
```
→
```
✨
```
```
fix
```
→
```
🐛
```
```
chore
```
→
```
🧹
```

Use a different emoji only if it more precisely matches the change.

```
feat
```
→
```
✨
```
```
fix
```
→
```
🐛
```
```
chore
```
→
```
🧹
```

仅当其他表情符号更精准匹配变更时，才可使用替代表情。

Type and body guidance (required)

类型与正文指南（必填）

Use the detailed rubric and templates in

references/commit-rules.md

for:

selecting
```
feat
```
vs
```
fix
```
vs
```
chore
```
classifying mixed-intent diffs
writing standard commit bodies
writing finalise commit bodies

Read this reference before proposing the first commit in a session, and revisit it whenever classification is ambiguous.

使用

references/commit-rules.md

中的详细规则和模板来：

选择
```
feat
```
、
```
fix
```
或
```
chore
```
类型
分类混合意图的代码差异
编写标准提交正文
编写收尾提交正文

在会话中提出第一个提交提案前，请阅读此参考文档；每当分类存在歧义时，需重新查阅。

Modes

模式

```
commit
```
mode: propose and execute one atomic commit at a time.
```
finalise
```
mode: merge/close the completed branch and delete feature branches.
```
hotfix
```
mode: for urgent fixes committed directly to the default branch. Requires
```
review local
```
approval; PR is optional. Still update
```
tasks/memory.md
```
with the hotfix rationale.

```
commit
```
模式：一次提案并执行一个原子化提交。
```
finalise
```
模式：合并/关闭已完成的分支并删除功能分支。
```
hotfix
```
模式：用于直接提交到默认分支的紧急修复。需要
```
review local
```
批准；PR为可选。仍需更新
```
tasks/memory.md
```
记录热修复的理由。

Workflow

工作流程

Inspect current changes (

git status --short

git diff

git diff --staged

Partition changes into atomic commit groups.
For the next group, propose:
- files/hunks included
- type rationale (why this is
```
feat
```
  /
```
fix
```
  /
```
chore
```
  , citing concrete diff intent)
- commit title (emoji + type + imperative summary)
- commit body (Summary/Why/Context/Alternatives/Trade-offs/Consequences)
Ask for a decision:
- ```
yes
```
  : stage only that group and commit
- ```
edit
```
  : revise message/scope and ask again
- ```
skip
```
  : leave group uncommitted and move on
- ```
split
```
  : break the group into smaller commits and repropose
After each accepted commit:
- commit immediately
- report commit hash + title + short "what changed" summary
- propose the next atomic group until done
During commit mode, evaluate memory-worthy outcomes and update
```
tasks/memory.md
```
inline when needed:
- durable rationale not obvious from code diff alone
- implementation gotchas that should survive branch lifecycle
- if no durable memory change is needed, explicitly skip with reason

检查当前变更（

git status --short

git diff

git diff --staged

）。

将变更划分为原子化提交组。
针对下一组变更，提案内容包括：
- 包含的文件/代码块
- 类型理由（为何是
```
feat
```
  /
```
fix
```
  /
```
chore
```
  ，需引用具体的代码差异意图）
- 建议的标题
- 建议的正文（包含摘要/原因/上下文/替代方案/权衡/影响）
请求用户决策：
- ```
yes
```
  ：仅暂存该组并提交
- ```
edit
```
  ：修改消息/范围后重新提案
- ```
skip
```
  ：保留该组不提交，继续处理下一组
- ```
split
```
  ：将该组拆分为更小的提交后重新提案
每次提交被接受后：
- 立即执行提交
- 报告提交哈希+标题+简短的“变更内容”摘要
- 提案下一个原子化组，直至所有变更处理完成
在提交模式下，评估是否有需要记忆的结果，必要时实时更新
```
tasks/memory.md
```
：
- 代码差异本身无法体现的持久化理由
- 应在分支生命周期中保留的实现注意事项
- 如果不需要变更持久化记忆，需明确说明原因并跳过

Finalise Mode

收尾模式

Use after all intended commits are done.

Confirm preconditions:
- working tree clean
- on feature branch (not base)
Determine the feature PRD path to finalise:
- prefer active feature PRD files in
```
tasks/
```
  matching the feature ID (
```
tasks/f-##-*.md
```
  )
- if multiple matches exist or feature ID is unclear, ask the user for the exact path
Before merge, prepare tracking updates:
- if the PRD path matches
```
tasks/f-##-<slug>.md
```
  , ensure
```
tasks/archive/
```
  exists and move the PRD to
```
tasks/archive/f-##-<slug>.md
```
  (same filename); if already archived, skip move
- apply strikethrough to the matching feature entry in
```
tasks/todo.md
```
  (
```
- [x] f-##: name
```
  →
```
- [x] ~~f-##: name~~
```
  )
- if
```
tasks/memory.md
```
  exists (or should exist), update it when durable state changed:
  - add completed milestone entry for the finalised feature
  - update "Current state" (next up / blockers) if it changed
  - capture any key decisions or gotchas discovered during completion
- stage all resulting tracking changes together and propose exactly one
```
🧹 chore: finalise f-## ...
```
  commit (use short finalise body); if no tracking changes are needed, explicitly state why and skip the finalise commit
Ask the user to confirm the target branch for merge (for example:
```
main
```
,
```
dev
```
,
```
release/*
```
).
Choose finalise path (require explicit user input):
- PR path (preferred): requires PR URL/number and
```
review pr: Ready to accept PR: Yes
```
  before merging; merge into the confirmed target branch using the repository-approved strategy (merge/squash/rebase), close it, then clean up branches
- Local path: requires
```
review local: Good to commit: Yes
```
  before merging, and is allowed only when repo policy allows local merges. Apply the policy-specific flow from
```
references/finalise-policy.md
```
  (merge-commit / linear-history / local squash / local rebase / PR-only).
Apply branch safety checks before deletion:
- confirm
```
<feature-branch>
```
  is not the target branch
- confirm
```
<feature-branch>
```
  is not the default branch
- confirm current HEAD is not
```
<feature-branch>
```
  when deleting it
Delete completed feature branch only after explicit user confirmation:
- local:
```
git branch -d <feature-branch>
```
- remote:
```
git push origin --delete <feature-branch>
```

在所有预期提交完成后使用。

确认前置条件：
- 工作树干净
- 当前处于功能分支（非基础分支）
确定要收尾的功能PRD路径：
- 优先选择
```
tasks/
```
  中与功能ID匹配的活跃功能PRD文件（
```
tasks/f-##-*.md
```
  ）
- 如果存在多个匹配项或功能ID不明确，询问用户具体路径
合并前，准备跟踪更新：
- 如果PRD路径为
```
tasks/f-##-<slug>.md
```
  ，确保
```
tasks/archive/
```
  目录存在，并将PRD移动到
```
tasks/archive/f-##-<slug>.md
```
  （文件名相同）；如果已归档，跳过移动操作
- 在
```
tasks/todo.md
```
  中对匹配的功能条目添加删除线（
```
- [x] f-##: name
```
  →
```
- [x] ~~f-##: name~~
```
  ）
- 如果
```
tasks/memory.md
```
  已存在（或应存在），当持久化状态变更时更新该文件：
  - 为已收尾的功能添加完成的里程碑条目
  - 如果“当前状态”（下一步/阻塞项）有变化，进行更新
  - 记录完成过程中发现的关键决策或注意事项
- 将所有生成的跟踪变更暂存在一起，并提案一个
```
🧹 chore: finalise f-## ...
```
  提交（使用简短的收尾正文）；如果不需要跟踪变更，明确说明原因并跳过该收尾提交
询问用户确认合并的目标分支（例如：
```
main
```
,
```
dev
```
,
```
release/*
```
）。
选择收尾路径（需要用户明确输入）：
- PR路径（推荐）：需要PR URL/编号，且在合并前需获得
```
review pr: Ready to accept PR: Yes
```
  的批准；使用仓库认可的策略（merge/squash/rebase）合并到确认的目标分支，关闭PR，然后清理分支
- 本地路径：合并前需获得
```
review local: Good to commit: Yes
```
  的批准，仅当仓库策略允许本地合并时才可使用。遵循
```
references/finalise-policy.md
```
  中的策略特定流程（合并提交/线性历史/本地压缩/本地变基/仅PR）。
删除分支前应用安全检查：
- 确认
```
<feature-branch>
```
  不是目标分支
- 确认
```
<feature-branch>
```
  不是默认分支
- 删除时确认当前HEAD不是
```
<feature-branch>
```
仅在获得用户明确确认后删除已完成的功能分支：
- 本地：
```
git branch -d <feature-branch>
```
- 远程：
```
git push origin --delete <feature-branch>
```

Output

输出

For each proposed commit, provide:

atomic scope (files/hunks)
short "what changed" summary
type rationale (1-2 lines; evidence-based)
proposed title
proposed body
explicit confirmation prompt (
```
Commit this change now?
```
)

After execution, provide:

created commit hash/title
short "what changed" summary
remaining uncommitted groups
finalise recommendation when all groups are complete
memory sync status (
```
updated
```
or
```
skipped
```
with reason)
End with a short status block:
- Files changed: list of created/updated files
- Key decisions: any assumptions or choices made (if any)
- Next step: recommended next skill or action

对于每个提交提案，需提供：

原子化范围（文件/代码块）
简短的“变更内容”摘要
类型理由（1-2行；基于证据）
建议的标题
建议的正文
明确的确认提示（
```
Commit this change now?
```
）

执行完成后，需提供：

创建的提交哈希/标题
简短的“变更内容”摘要
剩余未提交的组
所有组处理完成后的收尾建议
记忆同步状态（
```
updated
```
或
```
skipped
```
并说明原因）
以简短的状态块结尾：
- 变更文件：列出创建/更新的文件
- 关键决策：做出的任何假设或选择（如有）
- 下一步：推荐的后续操作或技能