Back to Details

implementkit

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

implementkit

implementkit

Turn a hardened plan, spec, or issue into working code, and stop there. implementkit is the build step between a settled plan and a clean commit: it reads an explicit input, resolves how to build (straight-through or test-driven), writes the code, and proves it with the repo's own test and build gate before it calls the work done. It never commits, because that's commitkit's job, and it never designs, because an underspecified input is bounced back to plankit/grillkit, not guessed at.
Its defining feature is mode resolution: the same request builds differently depending on whether the repo (or the user) wants test-driven development, and implementkit works that out by a fixed precedence rather than defaulting blindly.
将成熟的计划、规格说明或需求工单转化为可运行代码，在此步骤停止。implementkit是从确定的计划到干净提交之间的构建环节：它读取明确的输入，确定构建方式（直通式或测试驱动），编写代码，并在宣布工作完成前通过代码库自身的测试与构建校验来验证成果。它绝不提交代码，因为这是commitkit的工作；它也绝不负责设计，因为规格不明确的输入会被退回给plankit/grillkit，不会自行猜测。
它的核心特性是模式解析：根据代码库（或用户）是否需要测试驱动开发，同一个请求会以不同方式构建，implementkit会通过固定的优先级来确定模式，而非盲目默认。

When this fires

触发场景

The user hands off something concrete to be built: "implement this plan", "build issue #42", "write the code for 
docs/plans/plan-sso-2026-07-23.md
", "implement this spec", "do this the TDD way". It is the 
implementkit
step of the plan → grill → file → build → commit workflow.
Two hard boundaries:
  • It does not commit or stage. It leaves the finished work as unstaged changes and reports what it did; commitkit groups and commits.
  • It does not design. If the input is too thin to build without inventing the design, it stops and points back to grillkit/plankit. implementkit turns a settled intent into code; it doesn't settle the intent.
用户交付具体的待构建内容：“实现这个计划”“构建工单#42”“为
docs/plans/plan-sso-2026-07-23.md
编写代码”“实现这个规格”“用TDD方式做这个”。它是计划 → grill → 文件 → 构建 → 提交工作流中的
implementkit
环节。
两个明确边界：
  • 不提交或暂存代码。它将完成的工作保留为未暂存的变更，并报告所做的操作；commitkit负责分组和提交。
  • 不负责设计。如果输入内容不够具体，需要自行设计才能构建，它会停止并引导用户使用grillkit/plankit。implementkit是将确定的意图转化为代码，而非确定意图本身。

Procedure

流程

1. Take an explicit input

1. 接收明确输入

Require the user to name what to build. The options are a plan file (
docs/plans/plan-<slug>-YYYY-MM-DD.md
), an issue (
#42
, or a URL/id 
gh
can fetch), a freeform spec written in the prompt, or a fix round: a concrete list of review findings (e.g. the blockers from a review pass), each naming what's wrong and where. Do not hunt for an input: if nothing is named, stop and ask what to implement. Read the named input in full (for an issue, fetch it with 
gh issue view <n>
; if 
gh
isn't available, ask the user to paste it).
A plan or an issue may be narrowed to one phase ("implement phase 3 of 
plan-sso-2026-07-23.md
", "implement phase 2 of #42"). Both carry their phases as headings, so a narrowed run builds that phase and leaves the rest alone. Read the whole document either way: the phases above the named one say what the code may already assume, and the ones below say what it must not.
要求用户指定待构建的内容。可选输入包括计划文件（
docs/plans/plan-<slug>-YYYY-MM-DD.md
）、工单（
#42
，或
gh
可获取的URL/ID）、提示信息中的自由格式规格说明，或修复轮次：一份具体的评审结论列表（例如评审过程中发现的问题），每条结论指出问题所在及位置。不要主动寻找输入：如果用户未指定内容，停止并询问要实现什么。完整读取指定的输入（对于工单，使用
gh issue view <n>
获取；如果
gh
不可用，要求用户粘贴内容）。
计划或工单可限定为某一阶段（“实现
plan-sso-2026-07-23.md
的第3阶段”“实现#42的第2阶段”）。两者都将阶段作为标题，因此限定范围的运行仅构建该阶段，其余部分保持不变。无论如何都要读取整个文档：指定阶段之前的内容说明了代码可预先假设的条件，之后的内容则说明了代码不得涉及的部分。

2. Assess implementability, bounce if thin

2. 评估可实现性，若内容过简则退回

Before writing anything, judge whether the input is concrete enough to build without inventing the design. A hardened plan or a fleshed-out issue passes. A bare title, a one-line ask, or a spec with unresolved core decisions does not. Stop and tell the user to harden it first with grillkit (to interrogate the decisions) or plankit (to draft a proper plan), naming the specific gaps you hit. Don't paper over a thin spec with assumptions; a wrong guess here costs more than the bounce.
Thin for a different reason gets a different route. When the input is unsettled because nobody has seen the design work (the state model looks fine on paper, the screen has never been laid out), no amount of interrogation settles it, because the missing input is evidence rather than a decision. That routes to prototypekit when it's installed, or to a deliberate throwaway spike otherwise; it comes back here once the question is answered.
A fix round passes this bar by construction, because the findings name the defects, so there is no design to invent; never bounce one as thin. It also skips mode resolution below: apply the named fixes directly in the style the surrounding code already shows, and let the done-gate prove them.
在编写任何代码之前，判断输入内容是否足够具体，无需自行设计即可构建。成熟的计划或详细的工单可以通过。仅包含标题、一行请求或核心决策未明确的规格说明无法通过。停止并告知用户先使用grillkit（梳理决策）或plankit（起草正式计划）完善内容，指出具体存在的空白。不要用假设填补内容过简的规格说明；此处的错误猜测比退回的成本更高。
因不同原因导致内容过简的处理方式不同。当输入内容不确定是因为没人验证过设计是否可行（状态模型在纸上看起来没问题，但界面从未布局过），无论如何梳理都无法确定，因为缺失的输入是验证结果而非决策。这种情况下，如果已安装prototypekit则转向该工具，否则进行专门的一次性探索；待问题解决后再回到此处。
修复轮次默认符合要求，因为结论已指出缺陷，无需自行设计；绝不能以内容过简为由退回。它还会跳过下面的模式解析：直接按照现有代码的风格应用指定的修复，通过完成校验来验证修复效果。

3. Resolve the mode

3. 解析模式

Pick straight-through or TDD by this precedence, taking the first tier that gives an answer:
  1. Prompt. The user said so ("do this TDD", "just write it, no tests"). Explicit always wins.
  2. Agent instructions. The repo's agent-guide file (
    CLAUDE.md
    or an equivalent) declares a mode or a test-first policy. Honor it.
  3. Repo habit. Infer from the codebase. Conclude TDD only when both are true: (a) real test infrastructure exists (a runner/config like jest, vitest, pytest, 
    go test
    , rspec, cargo test), and (b) the repo actually ships tests with features, so recent commits touch test and source files together, and the test-to-source ratio is healthy. Infra with no habit (a lonely config, tests that lag far behind the code) is not TDD.
  4. Ask once. Still unresolved and a user is there to answer? Ask a single time which mode to use. Non-interactive (a delegated/autonomous run with no one to answer)? Default to straight-through, since TDD is the heavier mode and is never imposed silently. State which mode you resolved and why.
通过以下优先级选择直通式或TDD模式，取第一个能给出答案的层级：
  1. 提示信息。用户明确指定（“用TDD方式做”“直接写代码，不要测试”）。明确指令始终优先。
  2. Agent指令。代码库的agent指南文件（
    CLAUDE.md
    或等效文件）声明了模式或测试优先策略。遵循该指令。
  3. 代码库习惯。从代码库推断。只有同时满足以下两个条件时才判定为TDD：(a) 存在真实的测试基础设施（如jest、vitest、pytest、
    go test
    、rspec、cargo test等运行器/配置），且(b) 代码库实际随功能一起交付测试，因此近期提交同时修改测试和源文件，且测试与源文件的比例合理。仅有基础设施但无习惯（孤立的配置、测试严重滞后于代码）不属于TDD。
  4. 询问一次。仍未确定且有用户在场可回答？询问一次使用哪种模式。非交互式（无人应答的委托/自主运行）？默认使用直通式，因为TDD模式更繁琐，绝不会静默强制使用。说明解析出的模式及原因。

4. Build in the resolved mode

4. 按解析出的模式构建

Straight-through. Implement the production code to satisfy the input. Write no new tests; run the existing suite as part of the gate (Run the done-gate). Here the build/typecheck is the real safety net, since new code may be uncovered.
TDD. Strict red → green → refactor, per unit of behavior:
  1. Red. Write one focused failing test for the next slice of behavior, run it, and confirm it fails (a test that passes before the code exists is testing nothing, so fix it before continuing).
  2. Green. Write the minimal production code to make it pass; run it and confirm green.
  3. Refactor. Clean up code and test while the suite stays green.
Repeat per slice until the input is fully implemented. Match the surrounding code's conventions, naming, and structure in either mode, reusing what exists rather than reinventing it.
Visual surfaces delegate. When the work includes UI (a page, a component, a screen) and uikit is installed, apply it to those files instead of writing them blind; it carries the project's design constraint and runs its own visual pre-flight. Without it, write the UI directly. implementkit keeps everything else either way: the input contract, the mode resolved above, and the done-gate below, which remains the only gate.
Check as you go, not only at the end. Keep the feedback loop tight while building: typecheck and run the single affected test file as each slice lands, so breakage surfaces where it's cheap to fix. Save the full suite and the build for the done-gate. TDD's red→green already runs one test at a time; this closes the same gap in straight-through mode, which otherwise gets no signal until the end.
直通式。编写生产代码以满足输入要求。不编写新测试；作为校验环节的一部分运行现有测试套件（运行完成校验）。此处构建/类型检查是真正的安全网，因为新代码可能未被覆盖。
TDD。严格遵循红→绿→重构流程，针对每个行为单元：
  1. 红。为下一部分行为编写一个聚焦的失败测试，运行它并确认失败（在代码编写前就通过的测试没有任何意义，因此继续之前要修复它）。
  2. 绿。编写最少的生产代码使其通过；运行并确认测试通过。
  3. 重构。在保持测试套件通过的前提下清理代码和测试。
重复上述步骤直到输入内容完全实现。无论使用哪种模式，都要匹配现有代码的约定、命名和结构，重用现有内容而非重新发明。
可视化界面委托处理。当工作包含UI（页面、组件、屏幕）且已安装uikit时，将这些文件委托给uikit处理，而非盲目编写；uikit承载了项目的设计约束并运行自身的视觉预检查。如果未安装uikit，则直接编写UI。无论哪种情况，implementkit都保留其他所有内容：输入约定、上面解析的模式以及下面的完成校验，这是唯一的校验环节。
边构建边检查，而非仅在最后检查。构建时保持短反馈循环：每完成一部分就进行类型检查并运行单个受影响的测试文件，这样可以在成本较低时发现问题。将完整的测试套件和构建留到完成校验环节。TDD的红→绿流程已经每次运行一个测试；这填补了直通式模式的空白，否则直通式模式直到最后才能获得反馈。

5. Run the done-gate

5. 运行完成校验

"Done" means the repo's checks are green, not just that code was written. Discover the commands from the repo itself (
package.json
scripts, 
Makefile
, 
pyproject.toml
, 
justfile
, CI config) rather than guessing, and run:
  • the test command, and
  • the build / typecheck command (and lint, if the repo runs one).
All must pass before you declare done. If a command genuinely doesn't exist (no test script, no build step), say so and lean on what does exist; don't fabricate a command.
“完成”意味着代码库的检查全部通过，而非仅仅编写了代码。从代码库本身（
package.json
脚本、
Makefile
、
pyproject.toml
、
justfile
、CI配置）获取命令，而非猜测，然后运行：
  • 测试命令，以及
  • 构建/类型检查命令（如果代码库运行lint，则还包括lint命令）。
所有命令必须通过才能宣布完成。如果某个命令确实不存在（无测试脚本、无构建步骤），说明情况并依赖现有可用的命令；不要编造命令。

6. Fix on red, bounded

6. 失败时修复，限制次数

If the gate fails, try to fix your own output and re-run, but stay bounded to roughly three attempts. If it's still red after that, stop: never declare done on a failing gate, and never loop indefinitely. Report the failure, what you tried, and where you think it's stuck, and hand it back.
如果校验失败，尝试修复自己的输出并重新运行，但限制在大约三次尝试以内。如果三次后仍然失败，停止：绝不能在校验失败时宣布完成，也不能无限循环。报告失败情况、已尝试的修复措施以及认为卡住的地方，然后交回给用户。

7. Stamp the plan, when the input was one

7. 标记计划（当输入为计划文件时）

Skip this step entirely unless the input was a plan file and the gate passed. Then mark what you built, so the plan says what is left.
Append 
(built YYYY-MM-DD)
to the heading of each phase you finished, using today's date:
markdown
undefined
除非输入是计划文件且校验通过，否则完全跳过此步骤。然后标记已构建的内容，以便计划显示剩余未完成的部分。
在每个已完成阶段的标题后追加
(built YYYY-MM-DD)
，使用当前日期：
markdown
undefined

Phase 2: auth (built 2026-08-20)

Phase 2: auth (built 2026-08-20)

Phase 3: session refresh (#41) (built 2026-08-20)

Phase 3: session refresh (#41) (built 2026-08-20)


Four rules keep the stamp honest:

- **Stamp only the phases you actually built.** A run narrowed to one phase stamps that phase and leaves every other heading untouched. Never stamp a phase you skipped, and never stamp the whole plan because most of it is done.
- **Stamp after the gate is green**, never before. The stamp is a claim that the work passed, so writing it on unproven code makes the plan lie about the exact thing it exists to record.
- **Keep an existing `(#41)` and add yours after it.** The two annotations coexist: the number says where the phase is tracked, the stamp says it is done.
- **Leave the edit unstaged**, like every other change in the run, so commitkit picks up the plan alongside the code that implements it.

Stamp on every run, whatever the project's tracker is. A project filing GitHub issues gets a plan that carries both annotations, and one filing none gets a plan that is its own work list. Deciding which kind of project this is would be a judgment implementkit does not need and should not make.

四条规则确保标记真实可信：

- **仅标记实际构建的阶段**。限定为单个阶段的运行仅标记该阶段，其余标题保持不变。绝不要标记跳过的阶段，也不要因为计划大部分已完成就标记整个计划。
- **在校验通过后再标记**，绝不要提前标记。标记是对工作已通过校验的声明，因此在未经验证的代码上标记会使计划记录的信息失实。
- **保留现有的`(#41)`并在其后添加标记**。两种注释可以共存：编号表示阶段的跟踪位置，标记表示阶段已完成。
- **将编辑内容保持为未暂存状态**，就像本次运行中的其他所有变更一样，以便commitkit将计划与实现它的代码一起处理。

每次运行都要标记，无论项目使用哪种跟踪工具。使用GitHub工单的项目会得到包含两种注释的计划，不使用工单的项目则会得到作为工作清单的计划。判断项目属于哪种类型是implementkit不需要也不应该做出的决策。

8. Hand off to commitkit

8. 移交至commitkit

Write this section in the procedural register: one instruction per sentence, active voice, present tense, no metaphor.
Leave every change unstaged. Do not 
git add
, do not commit, do not draft a commit message (that's commitkit's job, and pre-staging fights its grouping). Report a short summary:
  • the mode used and which precedence tier decided it,
  • the files created and changed,
  • the gate result (which commands ran and that they passed),
  • the phases stamped, and which phases of that plan are still unbuilt.
Then point the user to commitkit when installed, or say plainly that the next step is to group and commit the changes. Don't run it yourself.
Name the next phase of the plan when one is left. Say the plan is fully built when none is.
本节使用流程式表述：每句一条指令，主动语态，现在时，无比喻。
将所有变更保持为未暂存状态。不要执行
git add
，不要提交，不要起草提交信息（这是commitkit的工作，预先暂存会干扰它的分组）。报告简短摘要：
  • 使用的模式以及决定该模式的优先级层级，
  • 创建和修改的文件，
  • 校验结果（运行了哪些命令且全部通过），
  • 标记的阶段，以及该计划中仍未构建的阶段。
如果已安装commitkit，则引导用户使用该工具；否则明确告知下一步是分组并提交变更。不要自行运行commitkit。
如果计划还有未完成的阶段，指出下一个阶段。如果计划已全部完成，说明计划已完全构建。

Notes

注意事项

  • Build only. No commit, no staging, no PR; those are commitkit and prkit. implementkit's job ends at green, unstaged code.
  • Skill
    is here for the uikit delegation, and it is not free.     Invoking uikit on visual work pulls a large document into an already-large build context, and every later tool use in the run re-bills it. That is the trade: a UI surface built against the project's actual design constraint, with its own pre-flight, versus a cheaper run that writes the screen blind. Take it on UI work and nowhere else. implementkit invokes no other skill, and routing to commitkit at the end is naming a next move, not calling one.
  • Never guess the design. Bouncing a thin input back to grillkit/plankit is a success, not a failure; it's the boundary that keeps this skill honest.
  • Never green-wash. A declared "done" always means the gate actually passed. Red after the bounded fixes is reported as red.
  • Follow the repo over these defaults. If the codebase has its own test/build commands, layout, or a stated workflow, follow that and say you did.
  • No filesystem or shell (e.g. a browser-based agent)? Then you can't write files or run the gate. Instead print the finished code as fenced blocks (one per file, with its path) for the user to save, note the mode you'd use, and list the gate commands they should run themselves.
  • 仅负责构建。不提交、不暂存、不创建PR；这些是commitkit和prkit的工作。implementkit的工作在代码通过校验且未暂存时结束。
  • Skill
    仅用于uikit委托，并非免费    。在可视化工作中调用uikit会将大型文档拉入本已庞大的构建上下文，运行中的后续工具使用会再次产生开销。这是一种权衡：根据项目实际设计约束构建UI界面并进行预检查，与盲目编写界面的低成本运行之间的选择。仅在UI工作中使用该方式，其他场景不使用。implementkit不调用其他skill，在结束时引导至commitkit是指明下一步操作，而非调用工具。
  • 绝不猜测设计。将内容过简的输入退回给grillkit/plankit是成功，而非失败；这是保持该工具可靠性的边界。
  • 绝不粉饰结果。宣布“完成”始终意味着校验实际通过。经过限定次数修复后仍失败的，如实报告失败情况。
  • 遵循代码库的规则而非默认设置。如果代码库有自己的测试/构建命令、布局或规定的工作流，遵循这些规则并说明已遵循。
  • 无文件系统或Shell（例如基于浏览器的Agent）？则无法写入文件或运行校验。改为将完成的代码打印为代码块（每个文件一个块，包含路径）供用户保存，说明会使用的模式，并列出用户应自行运行的校验命令。