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:

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:

Example:

Phase 2: Implementation

Split responsibility clearly.

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:

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:

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:

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.