# Anthropic Dev Loop

> Use when the user wants to run, document, or reuse an Anthropic-inspired Claude Code development loop, including planning interviews, Fixture/Invariant/Probe verification, main/sub-agent implementation, PR review evidence, and post-merge harness updates. Trigger on phrases like Anthropic DevLoop, Claude Code development loop, harness-driven development, evals, verification loop, or multi-agent implementation flow.

- Skill: `nishimoto265/anthropic-dev-loop` (Agent Skill)
- Install (CLI): `npx skillmds@latest add nishimoto265/anthropic-dev-loop`
- Raw SKILL.md: https://api.skillmd.com/api/skills/nishimoto265/anthropic-dev-loop/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: nishimoto265 (https://skillmd.com/u/nishimoto265)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/nishimoto265/anthropic-dev-loop

---


# Anthropic Dev Loop

Use this skill to turn a development request into a repeatable Claude Code workflow:

```text
Plan -> Implementation -> Review / Merge -> Post-merge -> Harness Update
```

This is an Anthropic-inspired workflow, not an official Anthropic policy. Keep the output grounded in the user's repository, README, AGENTS/CLAUDE instructions, and current branch state.

## Core Principle

Before asking agents to write code, make the work verifiable.

Every non-trivial task should answer:

- What are we building?
- How will we build it?
- How will we know it is correct?
- What evidence will reviewers see?
- If it fails later, where does that learning go?

## Phase 1: Plan

First, inspect the repo conventions and relevant files. Then clarify only the decisions that materially affect implementation.

For substantial work, produce or update these artifacts:

| Artifact | Purpose |
|---|---|
| `spec.md` | User intent, scope, constraints, non-goals, unresolved questions |
| `plan.md` | Implementation order, touched areas, existing patterns to follow, rollout notes |
| `verification.md` | Fixtures, invariants, probes, observability points, commands to run |
| `implementation-guide.md` | Shared rules for parallel agents when the same pattern must be repeated |

Do not create these files mechanically for tiny changes. Use them when they reduce ambiguity or make verification reusable.

### Planning Interview

When requirements are underspecified, ask targeted questions before implementation. Prefer questions that reveal:

- missing user flows
- edge cases
- persistence or rollback behavior
- permission and security boundaries
- compatibility with existing behavior
- what is explicitly out of scope

If the user has already answered enough, proceed without forcing a questionnaire.

### Verification Shape

Use this vocabulary in `verification.md` or the plan:

| Term | Meaning |
|---|---|
| Fixture | The state or input to reproduce |
| Invariant | The rule that must remain true |
| Probe | How the rule will be checked |
| Observability point | A DOM attribute, log, metric, API response, screenshot, trace, or report that makes the check visible |

Example:

| Fixture | Invariant | Probe | Observability point |
|---|---|---|---|
| Completed Todo exists | State and UI agree | DOM attribute and visible class | `data-verified-done`, completed style |
| Long text exists | Layout does not break | Screenshot / browser check | Playwright screenshot |
| Unauthorized user opens page | User cannot act | API response and error UI | `403`, error state |

## Phase 2: Implementation

Split responsibility clearly.

| Role | Responsibility |
|---|---|
| Main Agent | Reads plan artifacts, divides work, controls global commands, classifies failures, redistributes fixes |
| Sub Agents | Implement scoped changes or review scoped diffs |
| Human | Owns product judgment, design judgment, risk acceptance, and final tradeoffs |

Treat the runner as part of the Main Agent's responsibility. Do not let many sub-agents independently run expensive global build/test/git operations unless the repo workflow requires it.

Default loop:

```text
1. Main Agent reads spec / plan / verification.
2. Main Agent divides work into scoped tasks.
3. Sub Agents implement their assigned scopes.
4. Main Agent runs build / test / lint / typecheck or the repo's equivalent checks.
5. Main Agent classifies failures.
6. Main Agent sends each failure back to the responsible Sub Agent.
7. Repeat until checks and review evidence are good enough.
```

Failure routing:

| Failure | Route to |
|---|---|
| Build failure | Owning implementation agent |
| UI regression | Frontend agent |
| Test failure | Test agent or owning implementation agent |
| Migration error | DB / migration agent |
| Spec mismatch | Owning implementation agent |
| Cross-cutting design issue | Main Agent revises the plan |

If the same failure pattern repeats, update the harness instead of only patching the current code.

## Phase 3: Review / Merge

PRs should expose evidence, not just summaries.

Include:

- change summary
- scope and affected surfaces
- verification commands and results
- screenshots, videos, traces, or dashboard links when useful
- known risks and non-goals
- specific areas where human review is needed

Review split:

| Reviewer | Primary focus |
|---|---|
| Claude reviewer | Spec drift, logic bugs, edge cases, missing tests, security/permission issues, regression risk |
| Human reviewer | Product behavior, design fit, architecture tradeoffs, production risk, final acceptance |

For critical changes, humans should also inspect the code directly.

## Phase 4: Post-Merge

After merge, watch for failures that should change the next loop.

Useful signals:

- production errors
- support/user reports
- flaky tests
- performance regressions
- rollback or hotfixes
- repeated review comments
- confusing or noisy instructions

Map each signal back into the harness:

| Signal | Harness update |
|---|---|
| Production bug | Add eval, test, fixture, or verification case |
| Repeated review comment | Update review skill, checklist, or PR template |
| Spec misunderstanding | Improve planning interview or `spec.md` shape |
| Test gap | Add verifier, contract test, or CI check |
| Noisy instruction | Remove or narrow CLAUDE.md / skill guidance |
| Eval score saturation | Improve grader criteria or add harder cases |

## Completion Checklist

Before finishing, confirm:

- The implementation follows repo conventions.
- The work has an explicit verification path.
- Evidence is available for reviewers when the change is user-visible.
- Repeated failures were routed back into a durable artifact.
- New harness content is useful, scoped, and not just more instructions.
- Obsolete or noisy harness content was considered for removal.