implement-issues

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Implement issues (one tick)

实现问题（单次执行）

One

ready-for-agent

issue implemented end-to-end per invocation, then stop. Compose with

/loop

for recurrence (

/loop /implement-issues

/loop 1h /implement-issues

);

/loop

owns pacing. Never schedule yourself.

This is the middle leg of the loop pipeline:

process-issues  ->  implement-issues  ->  process-prs
(ready-for-        (non-draft PR,         (review +
 agent issue)       Closes #N)             recommend-* verdict, you merge)

State derives entirely from GitHub (labels, assignees, branches, open PRs), so a tick is idempotent: with no grabbable issue it costs one

gh issue list

and exits.

每次调用端到端实现一个标记为

ready-for-agent

的问题，然后停止。可与

/loop

组合实现重复执行（

/loop /implement-issues

、

/loop 1h /implement-issues

）；

/loop

负责控制执行节奏。切勿自行调度任务。

这是循环流程的中间环节：

process-issues  ->  implement-issues  ->  process-prs
(标记为ready-for-        (非草稿PR，         (审核 +
 agent的问题)       包含Closes #N)             给出recommend-*结论，由你合并)

状态完全源自GitHub（标签、经办人、分支、开放PR），因此单次执行具有幂等性：若没有可处理的问题，仅执行一次

gh issue list

后就退出。

Rails

规则

Never merge. The PR is opened for review; merging stays the maintainer's hand (and
```
/process-prs
```
's verdict is a recommendation, not an action).
Never ship a guess. If the brief is underspecified or the work can't reach green, abort and demote (see below), never open a speculative PR.
The finalize gates are mandatory, not optional.
```
/review-fix
```
and
```
/recommit
```
run on every change before the PR opens, whatever its size, and
```
/verify
```
runs whenever the change is behavioral and a smoke is practical. "It's a one-line / test-only / obviously-correct change" is not grounds to skip
```
/review-fix
```
or
```
/recommit
```
, and a manual diff read is not a substitute for
```
/review-fix
```
. That rationalization is exactly how unreviewed AI-slop lands in a PR. Skipping a gate that applies is a process violation; if one genuinely cannot run, say so explicitly in the report rather than silently dropping it.
Never take an issue owned by another loop. Only unassigned issues are grabbable; assignment is the ownership signal.
Never touch clean-room / relicensing issues. Those are owned by their own dispatcher and run under a protocol that forbids reading the prior implementation. This pass reads the brief and explores the codebase normally, which would contaminate such work. The unassigned-only rail keeps it out, but treat this as a hard boundary.

Every issue comment starts with a disclaimer:

> *This was generated by AI during implementation.*

切勿合并PR。PR仅用于提交审核；合并操作由维护者负责（
```
/process-prs
```
给出的结论是建议，而非执行操作）。
切勿提交猜测性内容。如果需求描述不明确，或无法通过所有检查，应中止任务并降级处理（见下文），切勿提交推测性PR。
最终检查环节为强制要求，不可跳过。无论改动大小，PR提交前必须运行
```
/review-fix
```
和
```
/recommit
```
；若改动涉及业务逻辑且可进行冒烟测试，则必须运行
```
/verify
```
。“这只是一行代码/仅修改测试/显然正确的改动”不能作为跳过
```
/review-fix
```
或
```
/recommit
```
的理由，手动查看差异也不能替代
```
/review-fix
```
。这种合理化借口正是未经审核的AI生成垃圾内容进入PR的原因。跳过适用的检查环节属于流程违规；若确实无法运行某环节，需在报告中明确说明原因，而非悄悄跳过。
切勿处理其他循环流程已认领的问题。仅可处理未分配的问题；分配状态是所有权的标识。
切勿处理clean-room/重许可问题。这些问题由专门的调度器负责，且遵循禁止查看原有实现的协议。本流程会读取需求描述并正常探索代码库，这会污染此类工作。仅处理未分配问题的规则可避免这种情况，但需将此视为硬性边界。

所有问题评论必须以免责声明开头：

> *This was generated by AI during implementation.*

0. Preflight

0. 预检

Abort if not a git repo, or if there is no GitHub remote. This skill is GitHub-only (
```
gh
```
, issues, pull requests).
If the repo has no
```
ready-for-agent
```
label, there is nothing to do; exit.

若当前目录不是git仓库，或没有GitHub远程仓库，则中止任务。本技能仅适用于GitHub（依赖
```
gh
```
、issues、pull requests）。
若仓库没有
```
ready-for-agent
```
标签，则无任务可处理，直接退出。

1. Pick and claim one issue

1. 挑选并认领一个问题

Grabbable =

ready-for-agent

and unassigned and not owned by another active loop and has no existing branch or open PR for it.

bash

gh issue list --state open --label ready-for-agent \
  --json number,title,createdAt,assignees \
  --jq '[.[] | select((.assignees | length) == 0)] | sort_by(.createdAt) | .[0]'

(

gh issue list --assignee ""

does not filter to unassigned, so the unassigned check lives in the

jq

Take the oldest grabbable issue. If none, report and exit.

The issue must carry an agent brief (the
```
triage
```
skill's
```
AGENT-BRIEF.md
```
contract). If it has
```
ready-for-agent
```
but no brief, that is a gate violation: comment, remove
```
ready-for-agent
```
, apply
```
needs-triage
```
, and stop. Do not implement from a bare title.
Claim it: create the conventional branch in an isolated worktree with
```
git wt feat/<N>-slug
```
(or
```
fix/<N>-slug
```
per the issue's category; ignored files travel into the worktree), and assign the issue to yourself (
```
gh issue edit <N> --add-assignee @me
```
). The branch and the assignee are the claim, so a later tick or another loop skips it.

可处理的问题 = 标记为

ready-for-agent

且未分配且未被其他活跃循环流程认领且没有对应的分支或开放PR。

bash

gh issue list --state open --label ready-for-agent \
  --json number,title,createdAt,assignees \
  --jq '[.[] | select((.assignees | length) == 0)] | sort_by(.createdAt) | .[0]'

（

gh issue list --assignee ""

不会筛选出未分配的问题，因此未分配检查在

jq

中实现。）

选择最早的可处理问题。若无符合条件的问题，提交报告并退出。

问题必须包含Agent需求说明（即
```
triage
```
技能的
```
AGENT-BRIEF.md
```
约定内容）。若问题标记为
```
ready-for-agent
```
但无需求说明，属于违反流程：需添加评论，移除
```
ready-for-agent
```
标签，添加
```
needs-triage
```
标签，然后停止任务。切勿仅根据标题进行实现。
认领问题：在独立工作树中创建符合规范的分支，命名格式为
```
git wt feat/<N>-slug
```
（或根据问题类型使用
```
fix/<N>-slug
```
；忽略文件会同步到工作树），并将问题分配给自己（
```
gh issue edit <N> --add-assignee @me
```
）。分支和经办人状态是认领标识，后续的单次执行或其他循环流程会跳过该问题。

2. Implement and finalize

2. 实现与最终检查

Work entirely in the worktree, treating the agent brief as the contract (the issue body is context); run the steps below in order:

Implement the brief. Read code before changing it; touch only what the brief requires; respect any ADRs /
```
CONTEXT.md
```
.
Get the full test suite and lint/typecheck green.
Confirm every acceptance criterion in the brief is satisfied.
```
/review-fix
```
to a clean round (reviewers -> fixes -> re-verify; stop on a clean round or on oscillation). Invoke the skill; a hand review of the diff does not count.
```
/recommit
```
into a clean, logical commit sequence.
```
/verify
```
whenever the change is behavioral and a smoke is practical (the skill picks the method per project type). This is the one conditional gate: skip it only when the change is non-behavioral (e.g. test-only or docs) or no smoke is practical, and note the reason in the report.

完全在工作树中开展工作，以Agent需求说明为约定（问题正文为上下文）；按以下顺序执行步骤：

实现需求说明中的内容。修改代码前先阅读现有代码；仅修改需求说明要求的部分；遵守任何ADRs/
```
CONTEXT.md
```
中的规定。
确保完整测试套件、代码检查/类型检查全部通过。
确认需求说明中的所有验收标准均已满足。
运行
```
/review-fix
```
直至得到无问题结果（审核→修复→重新验证；在无问题结果或出现循环时停止）。必须调用该技能；手动查看差异不视为完成此步骤。
运行
```
/recommit
```
整理出清晰、逻辑连贯的提交序列。
若改动涉及业务逻辑且可进行冒烟测试，则运行
```
/verify
```
（该技能会根据项目类型选择测试方法）。这是唯一的可选检查环节：仅当改动不涉及业务逻辑（如仅修改测试或文档）或无法进行冒烟测试时才可跳过，并需在报告中说明原因。

3. Open the PR

3. 提交PR

/make-pr

: push and open a non-draft PR (the branch is already conventional, so no

/make-branch

rename is needed), body

Closes #N

, assignee the git user, and no verdict label (

/process-prs

applies that during its independent review).

/make-pr

drafts PRs it opens autonomously by default, so pass an explicit ready (non-draft) request to override that; otherwise the PR lands as a draft and

/process-prs

's non-draft queue never picks it up. Record the PR url in the report and stop.

运行

/make-pr

：推送分支并提交一个非草稿PR（分支已符合规范，无需运行

/make-branch

重命名），PR正文包含

Closes #N

，经办人设置为当前git用户，不添加结论标签（

/process-prs

会在独立审核时添加该标签）。

/make-pr

默认会将自主提交的PR设为草稿，因此需**显式指定为就绪状态（非草稿）**以覆盖默认设置；否则PR会以草稿形式提交，

/process-prs

的非草稿队列将无法处理该PR。在报告中记录PR链接并停止任务。

4. Abort and demote

4. 中止与降级处理

If the brief proves underspecified mid-implementation, or the work cannot reach green:

Remove the worktree and branch (releases the claim, leaves no cruft).
Unassign the issue (
```
gh issue edit <N> --remove-assignee @me
```
).
Post a disclaimer-prefixed comment naming the specific blocker (the ambiguous requirement, the failing behavior, what a human must decide).
Demote by swapping the labels with
```
gh issue edit <N> --remove-label ready-for-agent --add-label <state>
```
(GitHub labels are additive, so
```
ready-for-agent
```
must be removed explicitly).
```
<state>
```
is
```
needs-info
```
if it needs the reporter, or
```
ready-for-human
```
if it needs a maintainer decision or a human to get it green.

No PR. The demoted issue re-enters the pipeline rather than dying silently.

若在实现过程中发现需求说明不明确，或无法通过所有检查：

删除工作树和分支（释放认领状态，不留下冗余内容）。
取消问题的分配（
```
gh issue edit <N> --remove-assignee @me
```
）。
添加以免责声明开头的评论，说明具体的阻塞原因（如模糊的需求、失败的行为、需要人工决策的内容）。
降级处理：通过
```
gh issue edit <N> --remove-label ready-for-agent --add-label <state>
```
替换标签（GitHub标签为累加式，因此需显式移除
```
ready-for-agent
```
标签）。
```
<state>
```
若需要报告者补充信息则设为
```
needs-info
```
，若需要维护者决策或人工介入以通过检查则设为
```
ready-for-human
```
。

不提交PR。降级后的问题会重新进入流程，而非静默终止。

Report

报告

End with one line for

/loop

: the issue implemented and the PR url, the abort + demotion, or "no unassigned ready-for-agent issue this tick." If a finalize gate was skipped or could not run, note which and why alongside that line.

结尾添加一行供

/loop

使用的内容：已实现的问题及PR链接、中止并降级处理的说明，或“本次执行无未分配的ready-for-agent问题”。若跳过或无法运行某个最终检查环节，需在该行旁注明具体环节及原因。

Composition

组合使用

Consumes

/process-issues

ready-for-agent

output and produces a PR that

/process-prs

finalizes and verdicts. Three single-purpose passes, each

/loop

-paced, none ever merging: triage, implement, finalize.

接收

/process-issues

输出的

ready-for-agent

问题，生成供

/process-prs

完成最终处理并给出结论的PR。三个单一功能的环节，每个环节由

/loop

控制节奏，均不执行合并操作：分类、实现、最终处理。