mcpField
I
incremental-implementation

incremental-implementation

github.com/alexbrunoその他09 回インストール今日更新
リポジトリ

incremental-implementation について

大規模で未検証のコードを一度に書くのではなく、小さく検証済みの垂直スライスで機能やリファクタリングを実装します。`workflow/PLAN.md` または `workflow/TASKS.md` の実行、複数ファイルの変更、約 100 行を超える見込みの変更の実装に使います。

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/alexbruno/dev-skills --skill incremental-implementation

インストール後、Claude Code で/incremental-implementationを入力して読み込まれたか確認します。

README(原文)English

プロジェクトの README より

この README の日本語訳はまだありません。以下は英語の原文です。日本語の紹介はページ上部をご覧ください。

Incremental Implementation

Deliver changes in thin, verifiable increments—one working slice at a time. Never write an entire multi-file feature in a single unverified pass.

Core Rule

One slice, one verification cycle. Do not start the next slice while the current slice has failing tests, type errors, or a broken build.

When to Apply

  • Executing steps from workflow/PLAN.md or tasks from workflow/TASKS.md.
  • Any change touching two or more files or exceeding ~100 lines of code.
  • Refactoring existing modules where behavior must remain intact at every step.

The Increment Loop

For each step in workflow/PLAN.md (or task in workflow/TASKS.md):

  1. Scope the Slice: Pick the smallest cohesive unit that delivers testable progress toward workflow/SPEC.md.
  2. Implement Minimally: Write only the code required for this slice—avoid speculative scaffolding for future slices.
  3. Test & Verify Immediately: Run targeted unit/integration tests, typecheck, and linter to confirm the slice works and introduces no regressions.
  4. Checkpoint: Update status in workflow/PLAN.md or workflow/TASKS.md (e.g., mark done), and create a clean commit/checkpoint when appropriate so rollback is effortless.
  5. Repeat: Advance to the next slice only after the current one is green.

Slicing Strategies

Choose the slicing strategy that best fits the work:

  • Vertical Slices (Default): Implement one thin end-to-end capability across layers (e.g., schema -> service -> endpoint -> test) rather than building all backend files first and all frontend/test files last.
  • Risk-First Slicing: Tackle the highest-uncertainty assumption, integration, or performance bottleneck in the earliest slice so surprises surface immediately.
  • Contract-First Slicing: Define types, interfaces, and test assertions first, verify they compile/fail as expected, then implement the concrete behavior.

Guardrails

  • No stacked brokenness: Fix failing checks in the current slice before moving on.
  • Keep diffs reviewable: If a slice grows too large, split it into smaller sub-slices before continuing.
  • Stay aligned with SPEC.md: Do not add unrequested features while implementing a slice.

コメント