incremental-implementation

incremental-implementation の概要

incremental-implementation スキルは、大きな変更を一気に完成させようとするのではなく、動作する小さな断片に分けてコードを出荷するのに役立ちます。複数ファイルにまたがるタスク、テストが必要なタスク、あるいは一度の大きな編集ではデバッグしづらいリスクの高いタスクでは、Code Editing ワークフローにおける incremental-implementation として特に向いています。

機能を前に進めながら、正しさは落としたくないときに使うと実用的です。やるべきことはシンプルで、作業を implement-test-verify の連続に分解し、各スライスをレビュー可能・テスト可能・障害時に復旧しやすい状態に保つことです。

向いているケースと、その理由

このスキルは、機能追加、リファクタリング、そして最初の下書きが一度に確実に検証できる範囲を簡単に超えてしまうような変更に強く適しています。一方で、単一ファイルの小さな修正にはあまり向きません。その場合は、分割のためのオーバーヘッドが価値よりも大きくなりがちです。

何が違うのか

よくある「反復しながら進める」系のプロンプトと違い、incremental-implementation は具体的な実行パターンを与えます。つまり、最小の完全な変更を入れ、検証し、それから次へ進むという流れです。この規律によって隠れた結合が減り、回帰が局所化され、フィードバックが来る前に作り込みすぎるのを防げます。

ユーザーが最も気にすること

読者が気にするのは、実際にリスクを下げられるのか、どれだけ計画が必要なのか、そして速度を落とさないのか、という点です。答えはこうです。スライスの境界を決めて各ステップを検証する意思があるなら、手戻りを防ぐことで難しいタスクはむしろ速く進みます。ただし、境界を切らずに進めようとすると効果は出ません。

incremental-implementation スキルの使い方

スキルをインストールして、ソースを確認する

incremental-implementation install パッケージは次のコマンドでインストールします。

npx skills add addyosmani/agent-skills --skill incremental-implementation

次に、まず SKILL.md を読みます。この repo ではこれが主な信頼できる情報源であり、追いかけるべき追加の rules/、references/、補助スクリプトはありません。最短でオンボーディングしたいなら、「いつ使うか」と「increment cycle」のセクションから始めるのが最適です。

あいまいなタスクをスライスに分ける

incremental-implementation usage の出発点として理想的なのは、最初から成果物ごとに分解されたタスクです。大きすぎる一つの依頼ではありません。よい入力例は次のようなものです。

• 「ユーザープロフィール編集を3スライスで追加する。フォーム描画、保存 API、バリデーション/エラー状態の順で。」
• 「パーサーを段階的にリファクタする。既存動作を維持しつつ、ロジックを移す前にテストを追加する。」
• 「ダッシュボードのフィルターを、まず動く UI、その次に永続化、最後にエッジケースの順で実装する。」

弱い入力はこうです。「アプリがプロフィールをサポートするようにして。」これではスライス境界をスキル側が推測するしかなくなり、そこで実装品質が落ちやすくなります。

機能全体ではなく、ループに従う

強い incremental-implementation guide は、最小の完全なスライスを実装し、関連するテストかビルドを実行し、挙動を確認してから次のスライスへ進む、というものです。テストできないスライスは、さらに小さくしてください。検証できないなら、たいてい範囲が広すぎます。

Code Editing での実践ワークフロー

incremental-implementation for Code Editing では、各ステップ後に動作状態を維持し、大規模な書き換えを避けるようエージェントに求めるのが有効です。たとえば、次のようなプロンプト構成が役立ちます。

Use incremental-implementation. Break this task into 3-5 slices. For each slice, change only the necessary files, explain the test or verification step, and stop if the slice would leave the app broken.

この形が効くのは、スコープを絞り、チェックポイントを強制し、コードを触りすぎる前にトレードオフを表に出させられるからです。

incremental-implementation スキル FAQ

incremental-implementation は大きな機能だけのものですか？

いいえ。いきなり全部を直すとリスクが上がる変更なら、どんなものにも使えます。incremental-implementation skill は、テストが必要なとき、ファイルをまたぐ依存があるとき、最初の試行で未知の要素が出ると予想されるときに特に役立ちます。

ワークフロー全体を変える必要はありますか？

いいえ。今のスタックはそのままで、実行順だけを変えれば十分です。つまり、スライスする、検証する、続ける、の順です。このスキルは新しいフレームワークやツールチェーンではなく、実装の規律を支えるものです。

使わないほうがいいのはどんなときですか？

単一関数や単一ファイルで、すでに素直に直せる修正には使わなくてかまいません。タスクが小さく、内容も十分に分かっているなら、段階設計はかえって不要な儀式になります。

初心者にも向いていますか？

はい。機能を基本レベルで説明でき、段階的な進行を受け入れられるなら問題ありません。経験豊富な開発者にも有用です。「ほぼ完成」状態のコードが検証されないまま溜まっていくのを防げるからです。

incremental-implementation スキルを改善するには

スライス境界をもっと明確にする

品質を最も大きく引き上げるのは、各スライスの終点を明示することです。「各ステップ後にアプリをビルド可能に保つ」「UI が動くまで schema changes はしない」「API レイヤーに触る前にテストを追加する」といった制約を入れてください。こうした境界があるほど、incremental-implementation usage はずっと安定します。

事前に必要なコンテキストを渡す

エントリーポイント、現在のファイル、そして厳しい制限を共有してください。たとえば framework version、test commands、migration constraints、変更してはいけないファイルなどです。これらの制約を途中で探索させると、技術的には段階的でも、結合しづらいスライスを選んでしまうことがあります。

よくある失敗パターンを見極める

主な失敗は、検証しきれないほど大きいスライスです。最初の出力が広すぎると感じたら、次の一手をもっと小さくするか、テスト計画をより厳密にするか、対象ファイルを絞ってください。多くの場合、良い結果はコード編集の後ではなく、編集前にスコープを狭めることで得られます。

各スライスの後で反復する

最初の出力は完成形ではなく、計画として扱ってください。各スライスのあとで、何が通り、何が壊れ、何がまだ危険に見えるかをエージェントに伝えます。このフィードバックループこそが incremental-implementation スキルの真価です。一度きりの依頼を、制御されたコード編集の連続に変えてくれます。