無料GitHub で公開

incremental-implementation

Deliver multi-file changes in thin vertical slices — implement, test, verify, commit, repeat. Load when implementing a feature from a plan, building across more than one file, refactoring, or when tempted to land a large change in one pass. Also triggers on "incremental implementation", "vertical slice", "thin slice", "one slice at a time", "don't do it all at once". Routes single-file fixes to direct execution. Pairs with test-driven-development and git-workflow-and-versioning.

dvy1987/agent-loom

インストール方法を見る

含まれるファイル（2）

SKILL.md5.1 KB
references/examples.md2.4 KB

SKILL.md（原文）

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Incremental Implementation

You ship multi-file work as a sequence of small, working slices. Each slice leaves the repo buildable and tests green.

Hard Rules

Never write more than ~100 lines without running the project's test command. Never mix unrelated concerns in one slice (feature + refactor + deps = separate slices). Never expand scope beyond the current task — note adjacent issues; do not fix them. Never skip verify because "you'll test at the end." After each slice: test → verify → commit (see git-workflow-and-versioning).

Workflow

Step 1 — Confirm slice plan

Read the approved plan or task. Pick one slice: the smallest end-to-end path (vertical slice preferred). State what's in scope and explicitly out of scope for this slice.

Step 2 — Implement one slice

Build only that slice. Prefer the simplest thing that could work — no abstractions before the third real use case.

Step 3 — Test and verify

Run the project's test command. Run build/typecheck/lint if the change could affect them. Do not re-run the same command on unchanged code.

Step 4 — Commit and pick next slice

Commit with a descriptive message (git-workflow-and-versioning). If the slice came from a saved plan, tick its checkbox in the plan file before moving on — the plan is the durable progress record across sessions. Repeat Steps 2–4 until the task is done.

Step 5 — End-to-end check

Identify the exact verify command (test/build/lint), run it fresh, and read its actual output — never report "done" or "tests pass" from memory or assumption. Full test suite, build clean, feature matches spec/plan. Report slices completed and commits made.

Slicing strategies

Strategy	When
Vertical slice (default)	One complete path through stack (e.g. create → API → UI)
Contract-first	Parallel FE/BE — define API contract first, then implement each side
Risk-first	Prove the riskiest integration before surrounding code

Gotchas

A bug in slice 1 invalidates slices 2–5 — test each slice.
"While I'm here" refactors belong in a separate commit, not this slice.
Feature flags beat long-lived branches for incomplete user-visible work.
Agents that skip verify to save time usually cost more time in debugging.

Common Rationalizations

Excuse	Reality
"I'll test everything at the end"	Failures compound; you won't know which slice broke.
"Faster to do it all at once"	Until one of 500 lines is wrong and you can't bisect.
"Too small to commit"	Small commits are free; giant commits are expensive to revert.
"I'll add the feature flag later"	Incomplete features must not be user-visible without a flag.
"Let me run tests again for reassurance"	Re-run only after code changed since last green run.
"It should pass now"	Claims of done require a fresh command run and read output — not a prediction.

Output Format

## Incremental implementation — [task/slug]

Slices planned: N | Completed: N
Current slice: [name] — [in scope / out of scope]

Verification:
- Tests: [command] → [pass/fail]
- Build: [command] → [pass/fail/skip]

Commits: [list or "pending user commit policy"]

Next slice: [one line] | Done

Examples

<examples> <example> <input>Implement task creation from the plan — DB, API, and UI.</input> <output> Slice 1 only: POST /tasks + migration + minimal form. Out of scope: list/edit/delete. After `npm test` passes → commit `feat: add task creation endpoint and form`. Next slice: list tasks. </output> </example> </examples>

Verification

Slice scope stated before coding
Tests run for slice
Commit advised after verification
Traceability to plan tasks

Red Flags

Slice shipped without tests while later slices depend on it
While-I-am-here refactor bundled into feature slice
Long-lived branch used instead of flag for partial UX
Slice boundary unclear — spans unrelated subsystems

Prune Log

Last pruned: 2026-07-09

Added evidence-before-claims verify gate + plan-checkbox ticking (agent-loom Phase 4, obra/superpowers)

Impact Report

Task: [slug] | Slices: N/M | Last verify: [pass/fail]
Commits: [count] | Scope expansions noted: [count]

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

ログインしてレビューを書く

同じリポジトリのスキル

概要と使いどころ

adversarial-hat

無料

Put on the adversarial hat and systematically attack any document, plan, strategy, or idea to expose its weakest points before commitment. Structured devil's advocate with red team rigour — not pessimism, but evidence-based critique across three phases: diagnostic (are claims accurate?), creative (is the problem artificially constrained?), challenge (are solutions robust?). Load when the user asks to stress test a document, red team this plan, poke holes in this, devil's advocate this, challenge my assumptions, or when product-soul, brainstorming, prd-writing, or inversion calls for adversarial review. Also triggers on "what am I missing", "what could kill this", "find the flaws", or "critique this rigorously".

日本語の概要は準備中です。原文の説明を表示しています。