implementkit

implementkit

完成度の高い計画、仕様、またはイシューを動作するコードに変換し、そこで止まります。implementkit は、確定した計画からクリーンなコミットに至るまでのビルド工程です。明示された入力を読み取り、どのように構築するか（そのまま実装、テストを後から追加、またはテスト駆動）を判断し、コードを書き、リポジトリ独自のテストとビルドのゲートで検証してから作業完了とします。コミットはしません。それは commitkit の役割です。また、設計もしません。入力が不十分な場合は推測せず、plankit/grillkit に差し戻します。

特徴はモードの解決です。同じ依頼でも、リポジトリ（またはユーザー）がテストを必要としているか、いつ必要としているかによって構築方法が変わります。implementkit はむやみに既定の方法を選ばず、決められた優先順位に従って判断します。

実行されるタイミング

ユーザーから、具体的な作業を引き継いだときに実行されます。「この計画を実装して」「イシュー #42 を構築して」「docs/plans/0007-plan-sso-2026-07-23.md のコードを書いて」「この仕様を実装して」「TDD でやって」「構築してテストも追加して」「この失敗するテストをパスさせて」などです。すでに動作していて、これまでテストされていなかったコードにテストを追加するのは後付けであり、testkit がインストールされている場合は testkit の役割です。これは、plan → grill → file → build → commit のワークフローにおける implementkit の工程です。

越えてはならない境界が 2 つあります。

• コミットもステージングもしません。 完了した作業は未ステージの変更として残し、実施内容を報告します。変更の整理とコミットは commitkit が行います。
• 設計はしません。 設計を創作しなければ構築できないほど入力が不十分な場合は、作業を止めて grillkit/plankit に差し戻します。implementkit は確定した意図をコードに変換します。意図を確定させることはしません。

手順

1. 明示された入力を受け取る

ユーザーに、構築する対象を指定してもらいます。対象は、計画ファイル（docs/plans/NNNN-plan-<slug>-YYYY-MM-DD.md、または NNNN- の連番がない旧形式のファイル）、イシュー（#42、または gh で取得できる URL/ID）、プロンプトに記述された自由形式の仕様、または修正ラウンドです。修正ラウンドは、次のいずれかの形式です。問題点とその箇所をそれぞれ示した、レビューで見つかった具体的な指摘事項の一覧（例：レビュー工程で見つかったブロッカー）、または原因を証明する失敗する再現テスト（例：debugkit によるもの）です。入力を探し回ってはいけません。対象が指定されていない場合は、作業を止めて何を実装するのか尋ねます。指定された入力を最後まで読みます（イシューの場合は gh issue view <n> で取得します。gh が使えない場合は、ユーザーに貼り付けてもらいます）。入力全体を読み終えたとき、または入力を求めて実行を停止したときに、この工程は完了です。

計画やイシューでは、1 つのフェーズに対象を絞ることができます（「0007-plan-sso-2026-07-23.md のフェーズ 3 を実装して」「#42 のフェーズ 2 を実装して」など）。どちらも見出しでフェーズが分かれているため、対象を絞った実行では指定されたフェーズだけを構築し、残りはそのままにします。いずれの場合も文書全体を読みます。指定されたフェーズより前のフェーズから、コードがすでに前提としてよいことが分かり、後のフェーズから、コードが前提としてはならないことが分かるためです。

2. 実装可能性を評価し、内容が不十分なら差し戻す

何かを書く前に、設計を勝手に補うことなく実装できるほど入力が具体的か判断します。十分に練られた計画、または詳細に記述された課題であれば合格です。

計画が十分に練られているかを示すシグナルを確認します。 タイトルの直下に Grilled: YYYY-MM-DD という行があれば、その計画はグリルを経ています。行がない場合は、グリルを一度も受けていないか、重要な編集を経ているため未グリルです。重要な編集があると、この行は削除されるためです。次に ## Open questions セクションを確認します。計画が未グリルである場合、またはそのセクションに項目がある場合は、ユーザーに警告し、未解決の質問をそれぞれ示します。対象フェーズが依存する未解決の質問はギャップとなるため、差し戻します。それ以外は警告として残し、ビルドを続けます。タイトルだけのもの、1行の依頼、または中核となる決定事項が未解決の仕様は合格しません。作業を止め、まず grillkit（決定事項を掘り下げるため）または plankit（適切な計画を作成するため）を使って十分に練るようユーザーに伝え、見つかった具体的なギャップを示します。不十分な仕様を仮定で補ってはいけません。ここで誤った推測をするより、差し戻すほうがよいからです。

別の理由で不十分な場合は、別の経路に進みます。 設計作業を誰も見ていないために入力が固まっていない場合（状態モデルは机上では問題ないが、画面レイアウトがまだ作られていないなど）、不足しているのは決定事項ではなく証拠なので、どれだけ問い詰めても解決しません。prototypekit がインストールされていればそれを使い、そうでなければ意図的に使い捨てのスパイクを実施します。疑問が解消されたら、この段階に戻ります。

修正ラウンドはこの基準を満たします。 調査結果や失敗するテストが欠陥を特定しているため、考案すべき設計はありません。内容が不十分だとして差し戻してはいけません。基準を満たすことは、作業の合格を意味しません。修正ラウンドも、ほかの実行と同様に、完了ゲートをすべて実行します。また、以下のモード解決はスキップし、指定された修正を周囲のコードにすでに示されているスタイルで直接適用します。

再現テストを伴う修正ラウンドでは、そのテストを証拠として維持します。 まずテストを実行し、予測された原因によって失敗することを確認します。修正前にテストが通った場合は、そこで止め、問題を再現しなくなったことを報告します。テストを削除したり、スキップしたり、弱めたりしてはいけません。完了ゲートでそのテストが、残りのテストスイートとともに通った時点で修正完了です。

このステップは、警告をすべて明示したうえで入力が合格するか、ギャップをそれぞれ示して差し戻した時点で完了です。

3. モードを決定する

次の優先順位に従って、最初に答えが得られた段階の straight-through、tests-after、または TDD を選びます。

1. プロンプト。 ユーザーが指定した場合（「TDDでやって」「実装してからテストを追加して」「実装だけして、テストはいらない」など）は、常にその指定を優先します。
2. エージェント向け指示。 リポジトリのエージェントガイドファイル（CLAUDE.md または同等のファイル）でモードやテストファースト方針が指定されている場合は、それに従います。
3. リポジトリの慣習。 コードベースから判断します。次の両方を満たす場合に限り、TDD と結論付けます。（a）テストを実行する基盤（jest、vitest、pytest、go test、rspec、cargo test などのランナーや設定）が実際に存在すること、かつ（b）リポジトリで機能追加とともにテストも実際に追加されており、最近のコミットでテストファイルとソースファイルが一緒に変更され、テストとソースの比率も健全であること。基盤があっても慣習がなければ（孤立した設定ファイルだけがある、テストがコードより大きく遅れているなど）、TDD ではありません。
4. 一度だけ尋ねます。 まだ決まらず、ユーザーが回答できる場合は、どのモードにするか一度だけ尋ねます。対話できない場合（回答者のいない委任・自律実行など）は、両方のテストモードは負荷が高く、黙って適用してはいけないため、デフォルトで straight-through を選びます。どのモードに決定したか、その理由とともに伝えます。

4. 解決したモードで実装する

ストレートスルー。 入力を満たすように本番コードを実装します。新しいテストは追加せず、ゲートの一環として既存のテストスイートを実行します（完了ゲートを実行する）。この場合、新しいコードがテスト対象外である可能性があるため、ビルド／型チェックが実質的な安全網になります。

テスト後。 ストレートスルーと同様に、まず本番コードを実装します。その後、入力で指定された動作ごとに、対象を絞ったテストを1つずつ作成します。テストを残す前に、失敗することを確認してください。 対象コードに小さな意味上の変更を加え（比較演算を反転する、戻り値を変えるなど）、テストを実行して失敗することを確認し、その変更を元に戻します。変更を加えても成功するテストは何も検証していないため、書き直すか削除してください。変更を元に戻すときは、自分が加えた編集を取り消してください。他の変更も含むファイルを復元してはいけません。

TDD。 動作の単位ごとに、厳密にレッド → グリーン → リファクタリングの順で進めます。

1. レッド。 次に実装する動作の範囲について、対象を絞った失敗するテストを1つ作成し、実行して失敗することを確認します（コードが存在する前に成功するテストは何も検証していないため、続行する前に修正してください）。
2. グリーン。 テストを通す最小限の本番コードを実装し、実行して成功することを確認します。
3. リファクタリング。 テストスイートが成功した状態を保ちながら、コードとテストを整理します。

入力の内容をすべて実装するまで、動作の範囲ごとに繰り返します。どのモードでも、既存のものを再発明せずに再利用し、周囲のコードの規約、命名、構造に合わせてください。

対象範囲のすべての要件にコードがあり、テスト後とTDDでは、指定されたすべての動作について失敗を確認したテストがあるとき、このステップは完了です。

UIを含む作業は委任します。 作業にUI（ページ、コンポーネント、画面）が含まれ、uikitがインストールされている場合は、何も確認せずに直接書くのではなく、対象ファイルにはuikitを適用してください。uikitはプロジェクトのデザイン制約を適用し、独自のビジュアル事前チェックを実行します。uikitがなければ、UIを直接実装してください。どちらの場合も、それ以外はimplementkitが担当します。つまり、入力の契約、上記で解決したモード、以下の完了ゲートです。このゲートが唯一のゲートです。uikitは独自の引き継ぎを行わずにimplementkitに戻るため、ユーザーが目にする引き継ぎはimplementkitの引き継ぎだけです。

最後だけでなく、作業中も確認します。 実装中はフィードバックループを短く保ち、範囲ごとに型チェックと影響を受ける単一のテストファイルを実行してください。問題を修正しやすいうちに検出できます。テストスイート全体とビルドは、完了ゲートまで実行しないでください。TDDのレッド→グリーンではすでにテストを1つずつ実行します。これにより、最後まで何の結果も得られないストレートスルーモードとの同じ隔たりも解消できます。

5. 完了ゲートを実行する

「完了」とは、コードを書き終えただけでなく、リポジトリのチェックがすべて成功している状態を指します。コマンドは推測せず、リポジトリ自体（package.jsonのスクリプト、Makefile、pyproject.toml、justfile、CI設定）から確認して、次を実行します。

• テストコマンド
• ビルド／型チェックコマンド（リポジトリで実行している場合はlintも）

完了を宣言する前に、すべて成功しなければなりません。コマンドが実際に存在しない場合（テストスクリプトやビルド手順がない場合）は、その旨を伝え、存在するものを活用してください。コマンドをでっち上げてはいけません。

チェックの成功だけでは不十分です。 新しい要件がテストされていなくても、既存のテストスイートが成功することはあります。入力にある各受け入れ項目を列挙してください。たとえば、計画フェーズのDone when:行、課題の受け入れ基準、各レビュー指摘、再現テストです。それぞれに、テスト名、コマンドとその出力、ファイルと行番号などの証拠を示してください。証拠のない項目は完了とせず、未検証と報告してください。

すべてのコマンドを実行して成功させ、受け入れ項目すべてに証拠または未検証の印が付いたとき、このステップは完了です。

6. 失敗時は、範囲を定めて修正する

ゲートに失敗した場合は、自分の出力を修正して再実行します。ただし、試行はおよそ3回までにとどめてください。それでも失敗する場合は停止します。ゲートに失敗したまま完了を宣言してはならず、無期限に繰り返してもいけません。失敗内容、試したこと、問題が残っていると考える箇所を報告し、引き継いでください。

7. 入力が計画ファイルだった場合は、計画にスタンプを付ける

入力が計画ファイルであり、ゲートに合格した場合を除き、この手順は完全に省略します。その後、構築した内容を記録し、計画に残作業を示します。

フェーズに Done when: の行がある場合は、まず確認します。 そこに記載された観測可能な項目を実行または確認し、結果を報告します。観測可能な項目が成立した場合にのみ、フェーズにスタンプを付けます。成立しない場合は、見出しにスタンプを付けず、そのフェーズは構築済みだが完了していないと報告します。ここでは確認できない場合（デプロイや人による確認が必要な場合）は、フェーズにスタンプを付け、観測可能な項目は未確認と報告します。

完了した各フェーズの見出しに、今日の日付を使って (built YYYY-MM-DD) を追記します。

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

スタンプを正確に付けるため、次の4つのルールを守ります。

• 実際に構築したフェーズにのみスタンプを付けます。 1つのフェーズに絞った実行では、そのフェーズにスタンプを付け、ほかの見出しはすべてそのままにします。スキップしたフェーズにはスタンプを付けず、ほとんど完了しているからといって計画全体にスタンプを付けないでください。
• ゲートに合格し、Done when: の確認項目が成立した後にのみスタンプを付けます。 決してその前に付けないでください。スタンプは作業が合格したことを示すため、証明されていないコードに付けると、その記録のために存在する計画に、まさに記録すべき内容について嘘をつかせることになります。
• 既存の (#41) は残し、その後ろに自分のスタンプを追加します。 2つの注釈は併存します。番号はフェーズの追跡先を示し、スタンプは完了を示します。
• ほかの変更と同様に、編集内容はステージングしないでください。 そうすることで、commitkit が計画を、それを実装するコードと一緒に取り込めます。

プロジェクトのトラッカーにかかわらず、実行のたびにスタンプを付けます。GitHub issue を使うプロジェクトでは、両方の注釈を含む計画が作成され、何も使わないプロジェクトでは、計画自体が作業リストになります。どちらの種類のプロジェクトかを判断する必要はありません。implementkit がその判断をする必要はなく、するべきでもありません。

8. commitkit に引き継ぐ

このセクションは手順を示す文体で記述してください。1文につき指示を1つにし、能動態、現在形を使い、比喩は使わないでください。

すべての変更をステージングしないでください。git add を実行せず、コミットせず、コミットメッセージの下書きも作成しないでください（それは commitkit の役割であり、事前のステージングは変更のグループ化を妨げます）。次の内容を簡潔に報告します。

• 使用したモードと、どの優先順位の階層で決定したか
• 作成および変更したファイル
• ゲートの結果（実行したコマンドと、それらが合格したこと）
• 各受け入れ項目とその根拠、および unverified とマークされた各項目
• 再現テストによる修正の反復を行った場合は、修正前に失敗し、修正後に成功したテストパス
• 未調査の項目や未解決の質問など、ビルドが先に進むにあたり残った計画上の警告
• スタンプを付けたフェーズ、各 Done when: の結果、そしてその計画でまだ構築していないフェーズ

次のアクションを1つだけ最優先として示します。commitkit がインストールされている場合は commitkit で作業をコミットすること、そうでない場合は次の手順が変更をグループ化してコミットすることだと明記します。自分では実行しないでください。次点のアクションは、次の順で示します。

1. commitkit がインストールされている場合は、コミットする前に reviewkit でエージェントの作業をレビューします。そうでない場合は、自分で差分を確認します。
2. ビルドで UI を変更した場合は、verifykit がインストールされていれば show で確認し、そうでなければアプリを開いて確認します。

計画に残りのフェーズがある場合は、次のフェーズを示します。残りがない場合は、計画全体が構築済みであると伝えます。

注意事項

• ビルドのみです。 コミット、ステージング、PR は行いません。それらは commitkit と prkit の担当です。implementkit の役割は、コードを作成し、テストが成功した状態で、未ステージのまま終えることです。
• 既存コードへのテスト追加は testkit の担当です。 テスト追加は、この実行で作成するコードを対象にします。テストなしで既にリリースされたコードのテストは、testkit が導入されている場合、testkit の担当です。
• Skill がここにあるのは uikit への委任のためであり、無料ではありません。 UI の作業で uikit を呼び出すと、すでに大きくなっているビルドコンテキストに大きなドキュメントが追加され、実行中にその後ツールを使うたびに料金が再度発生します。その代わり、プロジェクト固有の実際のデザイン制約に基づき、独自の事前確認を経て UI を構築できます。これは、より安価に画面の仕様を確認せず実装する場合とのトレードオフです。UI の作業でのみ利用してください。それ以外では利用しないでください。implementkit が呼び出すスキルは他にありません。また、最後に commitkit へ案内するのは次の手順を示しているだけで、commitkit を呼び出しているわけではありません。
• デザインを決して推測しないでください。 情報が不十分な依頼を grillkit／plankit に差し戻すのは失敗ではなく、成功です。これが、このスキルの誠実さを保つ境界です。
• テストの成功を偽装しないでください。 「完了」と宣言する場合は、必ず実際にゲートを通過している必要があります。範囲を限定した修正後も失敗している場合は、失敗として報告してください。
• ここに示した既定値より、リポジトリの指示を優先してください。 コードベースに独自のテスト／ビルドコマンド、レイアウト、または明示されたワークフローがある場合は、それに従い、その旨を伝えてください。
• ファイルシステムやシェルを利用できない場合（例：ブラウザベースのエージェント）、ファイルの書き込みやゲートの実行はできません。その場合は、完成したコードをファイルごとに、パスを付けたフェンス付きコードブロックで出力し、ユーザーが保存できるようにしてください。使用するモードを記し、ユーザー自身が実行すべきゲートコマンドを列挙してください。