git-propose

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Git Propose

Review all working directory changes and return commit proposal output in the exact structure below. Prefer best-effort recommendations over questions unless risk is material (secrets/data loss).

查看所有工作目录变更，并按照以下精确结构返回提交建议输出。除非存在重大风险（如泄露机密/数据丢失），否则优先给出尽力而为的建议而非提问。

Gather Git State

收集Git状态

Run:

bash

git rev-parse --is-inside-work-tree
git status --porcelain=v1
git ls-files --others --exclude-standard
git diff --staged --name-status
git diff --name-status
git diff --staged
git diff
git diff --staged --stat
git diff --stat

Treat staged content as intentional unless incomplete or unsafe without related unstaged changes. Assess all change buckets before proposing commits:

staged tracked changes
unstaged tracked changes
untracked files

运行：

bash

git rev-parse --is-inside-work-tree
git status --porcelain=v1
git ls-files --others --exclude-standard
git diff --staged --name-status
git diff --name-status
git diff --staged
git diff
git diff --staged --stat
git diff --stat

除非暂存内容不完整，或在缺少相关未暂存变更的情况下存在风险，否则将已暂存内容视为用户的有意操作。在提出提交建议前，评估所有变更类别：

已暂存的已跟踪变更
未暂存的已跟踪变更
未跟踪文件

Preflight and Empty-State Rules

预检与空状态规则

Run
```
git rev-parse --is-inside-work-tree
```
first. If it fails, do not run remaining git-state commands.
If not inside a git work tree, return the required output format with:
- ```
Repo State Summary
```
  :
```
Not a git repository
```
  .
- ```
Proposed Commit Plan
```
  :
```
0 commits
```
  .
- ```
Build-Mode Notes
```
  : assumption that no git state is available.

If working tree is clean (no staged, unstaged, or untracked changes), return the required output format with:

```
Repo State Summary
```
:
```
Clean working tree
```
.
```
Proposed Commit Plan
```
:
```
0 commits
```
.

Commit Proposals (Ready to Paste)

No commit proposed

首先运行
```
git rev-parse --is-inside-work-tree
```
。如果执行失败，请勿运行其余的Git状态命令。
如果当前不在Git工作区中，按照要求的输出格式返回：
- ```
Repo State Summary
```
  :
```
Not a git repository
```
- ```
Proposed Commit Plan
```
  :
```
0 commits
```
- ```
Build-Mode Notes
```
  : 假设无Git状态可用

如果工作区干净（无已暂存、未暂存或未跟踪变更），按照要求的输出格式返回：

```
Repo State Summary
```
:
```
Clean working tree
```
```
Proposed Commit Plan
```
:
```
0 commits
```

Commit Proposals (Ready to Paste)

No commit proposed

Required Output Format

要求的输出格式

Return exactly these section headings in this order:

```
## Repo State Summary
```
```
## Red Flags / Safety Notes (if any)
```
```
## Proposed Commit Plan
```
```
## Commit Proposals (Ready to Paste)
```
```
## Build-Mode Notes
```

Required content inside those sections:

Repo State Summary:
- Staged: brief summary
- Unstaged: brief summary
- Untracked: brief summary and include when needed for commit intent
- Mixed staged/unstaged in same files: yes/no and impact
Red Flags / Safety Notes:
- Call out secrets/credentials, generated artifacts, lockfile-only drift, huge formatting churn, risky partial staging
Proposed Commit Plan:
- Number of commits
- Rationale for split/merge choice
- Why ordering is reviewable
Commit Proposals:
- Intent / Scope (no file paths)
- Suggested staging (by intent, no file paths)
- Full commit message: title + blank line + body + optional footers
Build-Mode Notes:
- Explicit assumptions
- Ask clarifying questions only for real risk

Use this exact Markdown skeleton:

markdown

undefined

请严格按照以下顺序返回这些章节标题：

```
## Repo State Summary
```
```
## Red Flags / Safety Notes (if any)
```
```
## Proposed Commit Plan
```
```
## Commit Proposals (Ready to Paste)
```
```
## Build-Mode Notes
```

各章节内的必填内容：

Repo State Summary:
- Staged: 简要摘要
- Unstaged: 简要摘要
- Untracked: 简要摘要，必要时说明其与提交意图的关联
- Mixed staged/unstaged in same files: 是/否及影响
Red Flags / Safety Notes (if any):
- 指出机密/凭证、生成的产物、仅锁文件变更、大量格式调整、风险部分暂存等问题
Proposed Commit Plan:
- 提交次数
- 拆分/合并选择的理由
- 提交顺序便于评审的原因
Commit Proposals:
- 意图/范围（不包含文件路径）
- 建议的暂存方式（按意图，不包含文件路径）
- 完整提交消息：标题 + 空行 + 正文 + 可选页脚
Build-Mode Notes:
- 明确的假设
- 仅在存在实际风险时提出澄清问题

使用以下精确的Markdown模板：

markdown

undefined

Repo State Summary

Staged: ...
Unstaged: ...
Untracked: ...
Mixed staged/unstaged in same files: ...

Staged: ...
Unstaged: ...
Untracked: ...
Mixed staged/unstaged in same files: ...

Red Flags / Safety Notes (if any)

Proposed Commit Plan

Number of commits: ...
Rationale for split/merge choice: ...
Why ordering is reviewable: ...

Number of commits: ...
Rationale for split/merge choice: ...
Why ordering is reviewable: ...

Commit Proposals (Ready to Paste)

Commit 1

Intent / Scope: ...
Suggested staging: ...

Full commit message:

Subject:
```
type(scope): Subject
```
Body:
- ```
Body line 1
```
- ```
Body line 2
```

Intent / Scope: ...
Suggested staging: ...

Full commit message:

Subject:
```
type(scope): Subject
```
Body:
- ```
Body line 1
```
- ```
Body line 2
```

Build-Mode Notes

Explicit assumptions: ...
Clarifying questions (only if real risk): ...

undefined

Explicit assumptions: ...
Clarifying questions (only if real risk): ...

undefined

Commit Strategy Rules

提交策略规则

Choose single commit for one cohesive concern.
Split commits by concern when feature/refactor/fix/docs/tooling are mixed.
Favor cohesion over raw size.
Order by dependency and narrative:
- enabling refactors first
- functional changes next
- tests with the behavior they verify
- docs after behavior
Keep each commit independently reviewable and preferably revertible.

单一提交对应一个内聚的关注点。
当功能/重构/修复/文档/工具类变更混合时，按关注点拆分提交。
优先保证内聚性而非仅考虑变更大小。
按依赖关系和叙事逻辑排序：
- 先提交启用性重构
- 再提交功能变更
- 测试代码与所验证的行为放在同一提交
- 文档变更在行为变更之后提交
确保每个提交均可独立评审，最好可单独回滚。

Commit Message Rules

提交消息规则

Use Conventional Commits:
```
type(scope): subject
```
.
Allowed types:
```
feat
```
,
```
fix
```
,
```
refactor
```
,
```
docs
```
,
```
chore
```
,
```
test
```
,
```
perf
```
,
```
style
```
,
```
ci
```
.
Write subject in imperative present tense, capitalized, no trailing period.
Keep subject near 50 chars (can stretch when clarity requires).
Insert one blank line between subject and body.
Write body around 72-char wraps; explain why, approach, and tradeoffs.
Avoid file paths and line references in commit body.
Add optional footers (
```
Fixes #123
```
,
```
BREAKING CHANGE: ...
```
) when relevant.

使用Conventional Commits规范：
```
type(scope): subject
```
。
允许的类型：
```
feat
```
,
```
fix
```
,
```
refactor
```
,
```
docs
```
,
```
chore
```
,
```
test
```
,
```
perf
```
,
```
style
```
,
```
ci
```
。
标题使用祈使语气现在时，首字母大写，无结尾句号。
标题长度控制在约50字符（如需清晰表达可适当延长）。
标题与正文之间插入一个空行。
正文每行约72字符换行；解释变更原因、实现方式和权衡点。
正文中避免提及文件路径和行号。
相关时添加可选页脚（如
```
Fixes #123
```
,
```
BREAKING CHANGE: ...
```
）。

Ambiguity Handling

歧义处理

In build-like execution, continue with best-effort proposals and state assumptions.
Ask a question only when proceeding may introduce material risk.

在类构建执行场景中，继续给出尽力而为的建议并说明假设。
仅当继续执行可能带来重大风险时才提出问题。