implement-task-linear

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Implement Task from Linear

实现来自Linear的任务

Implement exactly one Linear issue. The issue is the required input and scope boundary; its provenance chain and repository context refine how to implement it without silently adding work.

严格实现一个Linear任务。该任务是必需的输入和范围边界；其来源链和仓库上下文会细化实现方式，避免无意义地增加额外工作。

1. Resolve the target and Linear boundary

1. 确定目标与Linear边界

Require an unambiguous Linear issue identifier or URL. Ask for one when absent.

Fetch the target's full description, status, labels, team, project, relation identifiers, comments, and requirement-bearing attachments. Record its exact team ID and project ID. If it has no project, ask the user to assign it or authorize assignment to a named project before inspecting surrounding Linear work.

After resolving the target, apply this boundary to every other Linear issue read or mutation:

query with both recorded IDs, then verify both IDs on every result;
discover parents, sub-issues, blockers, duplicates, and related issues through scoped queries rather than directly fetching an unverified identifier;
treat a cross-scope relation as unavailable context and report only its existence;
create issues only with both recorded IDs.

Resolve the team's relevant workflow states, especially In Progress, In Review, Backlog, and any blocked state, by ID. Report ambiguity instead of guessing.

This step is complete when the target, acceptance criteria, team/project IDs, and usable workflow states are known.

需要明确的Linear任务标识符或URL。若未提供，请向用户索要。

获取目标任务的完整描述、状态、标签、团队、项目、关联标识符、评论以及承载需求的附件。记录其确切的团队ID和项目ID。如果任务未分配项目，请在查看相关Linear工作前，要求用户分配项目或授权将其分配至指定项目。

确定目标后，将以下边界应用于所有其他读取或修改Linear任务的操作：

同时使用已记录的两个ID进行查询，然后验证每个结果的两个ID；
通过范围查询发现父任务、子任务、阻塞任务、重复任务和相关任务，而非直接获取未经验证的标识符；
将跨范围的关联视为不可用上下文，仅报告其存在；
创建任务时必须同时使用已记录的两个ID。

确定团队相关的工作流状态，尤其是“In Progress（进行中）”、“In Review（审核中）”、“Backlog（待办）”以及任何阻塞状态的ID。若存在歧义，请报告而非猜测。

当目标任务、验收标准、团队/项目ID以及可用工作流状态均明确后，此步骤完成。

2. Follow the provenance chain

2. 追溯来源链

Determine the repository root and read every applicable

AGENTS.md

before other repository work.

Then resolve context in this order. Each source is optional unless the target explicitly depends on it:

Originating spec — follow every explicit
```
Source
```
path or URL, spec link, design link, or requirement-bearing attachment in the target. When
```
to-linear
```
represented the spec as a native parent, find that parent through a team-and-project-scoped query, verify both IDs, then read its full description and comments. If no provenance is recorded, search
```
docs/
```
,
```
specs/
```
, and
```
.scratch/
```
for a single clear match to the target title, source name, or feature slug; ask before choosing among plausible matches. Inspect in-scope parents, blockers, milestone or cycle neighbours, and overlapping issues when they can clarify intent, dependencies, or drift.
Plan — read root
```
PLAN.md
```
fully when it exists. Use it for the larger outcome, sequencing, dependencies, and the target's place in the plan.
Domain context — read root
```
CONTEXT.md
```
fully when it exists. Also read root
```
CONTEXT-MAP.md
```
fully when it exists and follow every context entry applicable to the target. Context files define project language and domain boundaries, not implementation scope.
Decisions — read applicable ADRs under root
```
docs/adr/
```
and any context-specific
```
docs/adr/
```
. Follow pertinent artifact pointers from the selected spec, plan, context files, ADRs, and current conversation.
Repository truth — inspect the implicated code, tests, documentation, schemas, migrations, generated artifacts, configuration, and git status. Preserve unrelated user changes.

The prerequisite skills may leave different parts of this chain:

```
grill-with-docs
```
may leave
```
CONTEXT.md
```
,
```
CONTEXT-MAP.md
```
, and ADRs;
```
to-spec
```
publishes implementation decisions, agreed testing seams, and out-of-scope boundaries in an originating tracker issue;
```
to-linear
```
carries that origin into the target through a native parent or
```
Source
```
reference and may copy durable constraints into
```
Context
```
.

Missing optional artifacts do not block implementation. Explicit pointers do require resolution: read them, or report why they are unavailable.

Use this evidence hierarchy:

the target issue defines the deliverable and acceptance criteria;
the originating spec and
```
PLAN.md
```
explain intent, sequencing, and exclusions without expanding the target;
context files and ADRs constrain vocabulary, boundaries, and durable decisions;
the repository defines current implementation truth.

Surface material conflicts or stale evidence. Ask only when a conflict changes the intended behaviour, public interface, compatibility, or scope.

This step is complete when every explicit provenance pointer is resolved or reported unavailable, every applicable context artifact is read, and every target requirement is classified as implemented, partial, missing, contradicted, or blocked.

在进行其他仓库工作前，先确定仓库根目录并读取所有适用的

AGENTS.md

文件。

然后按以下顺序解析上下文。除非目标任务明确依赖，否则每个来源都是可选的：

源规范 —— 遵循目标任务中所有明确的
```
Source
```
路径或URL、规范链接、设计链接或承载需求的附件。当
```
to-linear
```
将规范表示为原生父任务时，通过团队和项目范围的查询找到该父任务，验证两个ID，然后读取其完整描述和评论。如果未记录来源信息，在
```
docs/
```
、
```
specs/
```
和
```
.scratch/
```
目录中搜索与目标任务标题、源名称或功能slug匹配的唯一清晰结果；若存在多个合理匹配项，请先询问用户再选择。当范围内的父任务、阻塞任务、里程碑或周期邻接任务以及重叠任务能够明确意图、依赖关系或偏差时，对其进行检查。
计划 —— 若根目录存在
```
PLAN.md
```
，请完整阅读。利用它了解整体成果、排序、依赖关系以及目标任务在计划中的位置。
领域上下文 —— 若根目录存在
```
CONTEXT.md
```
，请完整阅读。若根目录存在
```
CONTEXT-MAP.md
```
，也请完整阅读，并遵循所有适用于目标任务的上下文条目。上下文文件定义项目语言和领域边界，而非实现范围。
决策记录 —— 读取根目录
```
docs/adr/
```
下适用的ADR以及任何特定上下文的
```
docs/adr/
```
文件。遵循所选规范、计划、上下文文件、ADR和当前对话中的相关工件指针。
仓库实际情况 —— 检查相关代码、测试、文档、模式、迁移、生成的工件、配置和git状态。保留用户无关的更改。

前置技能可能会影响来源链的不同部分：

```
grill-with-docs
```
可能会涉及
```
CONTEXT.md
```
、
```
CONTEXT-MAP.md
```
和ADR；
```
to-spec
```
会在源跟踪器任务中发布实现决策、已商定的测试衔接点和范围外边界；
```
to-linear
```
会通过原生父任务或
```
Source
```
引用将来源信息带入目标任务，并可能将持久约束复制到
```
Context
```
中。

缺失可选工件不会阻碍实现。但明确的指针需要解析：读取它们，或报告无法获取的原因。

遵循以下证据优先级：

目标任务定义交付物和验收标准；
源规范和
```
PLAN.md
```
解释意图、排序和排除项，但不扩展目标任务范围；
上下文文件和ADR约束词汇、边界和持久决策；
仓库定义当前的实现实际情况。

指出实质性冲突或过时证据。仅当冲突会改变预期行为、公共接口、兼容性或范围时，才向用户询问。

当所有明确的来源指针都已解析或报告无法获取、所有适用的上下文工件都已读取、所有目标任务需求都被归类为已实现、部分实现、缺失、矛盾或阻塞时，此步骤完成。

3. Plan the delivery

3. 规划交付

Before editing, give the user:

the target outcome and assumptions;
the context sources consulted, including missing or unavailable expected artifacts;
material drift between Linear, the originating spec,
```
PLAN.md
```
, domain documents, and the repository;
a short vertical-slice plan with a verification check for each step;
the public testing seams already agreed in the spec, or the highest existing seams that fit the change.

Map every acceptance criterion and durable constraint to an implementation change or concrete verification. Existing behaviour counts only after verification. If choosing a seam would create or materially change a public interface, confirm it with the user when the upstream artifacts did not already settle it.

Move the target to the resolved In Progress state when implementation starts, unless it is already further along or the user asked to preserve its status.

This step is complete when every acceptance criterion has a delivery and verification path and every material design choice is settled.

在开始编辑前，向用户提供以下信息：

目标成果和假设；
已查阅的上下文来源，包括缺失或无法获取的预期工件；
Linear、源规范、
```
PLAN.md
```
、领域文档与仓库之间的实质性偏差；
简短的垂直切片计划，每个步骤都包含验证检查；
规范中已商定的公共测试衔接点，或最适合本次变更的现有衔接点。

将每个验收标准和持久约束映射到具体的实现变更或验证操作。现有行为仅在验证后才有效。如果选择衔接点会创建或实质性更改公共接口，且上游工件未明确确定该衔接点，请与用户确认。

开始实现时，将目标任务状态改为已解析的“In Progress（进行中）”，除非任务状态已更靠前或用户要求保留当前状态。

当每个验收标准都有交付和验证路径、所有实质性设计选择都已确定后，此步骤完成。

4. Implement in verified slices

4. 按已验证的切片实现

Implement the minimum coherent change that satisfies the whole target:

follow repository conventions and preserve unrelated work;
for testable behaviour, work red then green at the agreed public seams, one vertical slice at a time;
run the smallest relevant test and typecheck after each slice, then the broader relevant suite once near the end;
update required documentation, schemas, migrations, generated artifacts, and configuration;
keep required target work in the current change rather than deferring it to manufacture completion;
leave commits, pushes, pull requests, deployment, and release to an explicit user request.

When a test cannot reasonably be written or a full suite cannot run, use the strongest available verification and record the limitation.

Continue until every acceptance criterion passes or a genuine blocker remains.

实现满足整个目标任务的最小连贯变更：

遵循仓库约定，保留无关工作；
对于可测试行为，按照商定的公共衔接点，一次完成一个垂直切片，遵循红绿测试流程；
完成每个切片后运行最小相关测试和类型检查，接近完成时再运行更广泛的相关测试套件；
更新所需的文档、模式、迁移、生成的工件和配置；
将目标任务的必要工作保留在当前变更中，而非推迟以假装完成；
提交、推送、拉取请求、部署和发布操作需等待用户明确请求。

当无法合理编写测试或无法运行完整测试套件时，使用可用的最强验证方式并记录限制。

持续推进，直到所有验收标准通过或出现真正的阻塞问题。

5. Review and reconcile

5. 审核与协调

Inspect the complete diff before changing final Linear state:

Standards — check every changed area against applicable repository instructions, conventions, and ADRs.
Spec — check every target criterion and originating-spec constraint for missing work, incorrect behaviour, and scope creep.

Fix actionable findings and rerun affected checks. Re-fetch the target and every mutated related issue, then reconfirm the team/project boundary.

When every required outcome is implemented and verified:

Add a concise target comment mapping each acceptance criterion to implementation and verification evidence.
Move the target to In Review only when its current state is earlier.

Preserve completed, cancelled, archived, In Review, and other terminal or further-along states. When blocked, leave the target In Progress or use the resolved blocked state and record the unmet criterion, evidence, and dependency.

在更改Linear最终状态前，检查完整的差异：

标准 —— 对照适用的仓库说明、约定和ADR检查所有变更区域。
规范 —— 检查所有目标任务标准和源规范约束，确保无遗漏工作、行为错误和范围蔓延。

修复可操作的问题并重新运行相关检查。重新获取目标任务和所有已修改的相关任务，然后再次确认团队/项目边界。

当所有要求的成果都已实现并验证后：

添加简洁的目标任务评论，将每个验收标准映射到实现和验证证据。
仅当目标任务当前状态更早时，将其改为“In Review（审核中）”。

保留已完成、已取消、已归档、“In Review（审核中）”以及其他终端或更靠前的状态。若任务被阻塞，将其保留为“In Progress（进行中）”或使用已解析的阻塞状态，并记录未满足的标准、证据和依赖关系。

Related Linear work

Handoff

交接

Report:

target identifier, URL, and final status;
implemented outcome and changed surfaces;
verification commands and results;
acceptance-criteria coverage;
context sources used and unavailable explicit pointers;
material drift or conflicts found;
every related issue read that changed an implementation decision;
every issue created or modified, with reason, status, and URL;
blockers, limitations, and follow-up work.

Say explicitly when no related Linear issues changed.

报告以下内容：

目标任务的标识符、URL和最终状态；
已实现的成果和变更的界面；
验证命令和结果；
验收标准覆盖情况；
使用的上下文来源和无法获取的明确指针；
发现的实质性偏差或冲突；
所有影响实现决策的已读取相关任务；
所有已创建或修改的任务，包括原因、状态和URL；
阻塞问题、限制和后续工作。

当未修改任何相关Linear任务时，请明确说明。