Anthropic dev loop

Anthropic Dev Loop

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

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:

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.