单-slice 持续开发循环 V6：多agent 治理、停机收敛、协议化续跑。

SKILL.md

---
name: "continuous-dev-loop"
description: "单-slice 持续开发循环 V6：多agent 治理、停机收敛、协议化续跑。"
---

# Continuous Dev Loop

Use when the user wants a code project advanced in repeated, bounded engineering rounds that can be continued by one coding agent or a supervised multi-agent worker set without relying on chat memory alone.

## Use This For

- Ongoing development where one verified slice should land before the next begins.
- Repositories where continuity should come from repo-native state or supervisor-owned state, not conversational recollection.
- Sessions where each round should end with a machine-readable continuation contract.
- Background or supervisor-driven workflows that should keep moving until a real stop condition is hit.
- Projects where one round may benefit from explicit multi-agent role separation.

## Core Model

Treat one round as exactly:

`governance -> development -> verification -> optimization -> handoff -> stop/continue decision`

One round still means one slice.

Each round must:

- pursue exactly one slice
- have exactly one coordinator that owns final convergence
- verify the slice concretely
- decide whether the mainline should continue, stop cleanly, or downgrade
- leave one and only one next slice when continuing
- emit a supervisor-readable footer
- write continuity into repo-native or supervisor-owned state

## Non-Negotiables

- One round, one slice.
- Continue from explicit repo evidence first.
- Verification is mandatory:
- one build/typecheck-style check
- one smallest behavior proof tied to the slice
- Only the coordinator may publish final continuation truth.
- Automatic continuation must not rely on chat memory.
- Contract drift is stop-worthy: supervisors should detect stale loop contracts and refuse silent continuation.

## Priority Order

When choosing what to continue, prefer:

1. explicit user priority for the current turn
2. previous round's `NEXT_SLICE`
3. repo-native continuation evidence such as loop state files, progress docs, tasklists, or verification scripts
4. the current mainline ladder already established for the project

## Multi-Agent Rule

Multi-agent support does not relax the single-slice invariant.

Use the smallest role set that improves throughput without losing control.

Allowed roles:

- `coordinator`
- `implementer`
- `verifier`
- `investigator`
- `reviewer`

Hard rules:

- exactly one coordinator per round
- helper scopes must be bounded
- parallel read is cheap; overlapping writes are not
- if write scopes overlap, serialize through the coordinator
- helper outputs are evidence, not continuation truth

For role, topology, and merge details, read:

- [references/multi-agent-governance.md](references/multi-agent-governance.md)

## Round Workflow

1. Identify the current mainline from explicit repo evidence.
2. Choose one slice.
3. Choose execution mode:
- `single-agent`
- `multi-agent-read-heavy`
- `multi-agent-split-write`
4. Establish governance and repo policy profile.
5. Develop the slice.
6. Verify the slice.
7. Optimize only the completed slice.
8. Evaluate whether continuation is still healthy.
9. Write continuity into repo-native or supervisor-owned state.
10. Emit the handoff.

## Repo Policy Profiles

Every unattended loop should behave as if the repository has an explicit safety profile.

Recommended labels:

- `strict-clean`
- `warning-dirty`
- `commit-required`
- `push-required`
- `local-proof-heavy`

For profile semantics and when to use them, read:

- [references/repo-policy-profiles.md](references/repo-policy-profiles.md)

## Stop/Continue Governance

A good continuous loop is not just good at continuing. It must also stop cleanly when continuation quality degrades.

Use these concepts:

- blocker recurrence
- mainline exhaustion
- topology downgrade before blind retry
- clean stop when the next tiny slice is no longer credible

Read before applying stop/continue judgment in unfamiliar repos:

- [references/stopping-governance.md](references/stopping-governance.md)

## Continuation Protocol

Treat the next slice as a contract, not a suggestion.

Allowed `LOOP_STATUS` values:

- `continue`
- `blocked`
- `milestone_reached`
- `needs_human`
- `repo_broken`
- `exhausted`

`continue` means the supervisor should immediately start the next round from `NEXT_SLICE`.

`exhausted` means the current mainline no longer yields a credible next tiny slice under current constraints.

For footer fields, blocker buckets, and contract semantics, read:

- [references/loop-contract-v6.md](references/loop-contract-v6.md)

## Repo-Native Continuity Preference

Continuity should survive process restarts.

Prefer writing handoff state into existing surfaces such as:

- tasklists
- progress logs
- loop state docs
- `.claude-orchestrator/current-next.txt`
- `.claude-orchestrator/current-round.json`
- round ledgers and deterministic verification scripts

Do not create noisy state files if the repo already has a clear continuity surface.

## Human Summary Shape

End each round with:

`Done`
- what changed

`Verified`
- exact checks and what they proved

`Risks`
- remaining uncertainty or blocker notes

`Next`
- one next slice only, or `none` when stopping

If helper agents were used, also include:

`Agents`
- coordinator and helper roles actually used
- any serialized write boundary or integration note

## Required Footer

After the human-readable summary, emit this exact footer shape:

Rules:

- `NEXT_SLICE` must be one concrete slice when `LOOP_STATUS=continue`
- `NEXT_SLICE` must be `none` when `LOOP_STATUS=exhausted`
- `BLOCKER_BUCKET` must be `none` on successful continuation
- `STOP_REASON` must be `none` when `LOOP_STATUS=continue`

## Anti-Patterns

- broad milestone disguised as one slice
- overlapping write scopes without a merge strategy
- multiple incompatible next steps under `NEXT_SLICE`
- silent continuation after broken verification, repo drift, or contract drift
- fake tiny slices used to hide mainline exhaustion

Continuous Dev Loop

SKILL.md

related skills