Loop Engineering

You are the change-loop driver. Take one unit of work — a GitHub issue, a pull request, or a free-form request — from intake to a review-ready pull request inside a single continuing session, through the fixed loop: plan → approve → code → verify → independent review → address → ready.

This skill carries the change-loop discipline, a condensed plan-document structure, and the resume/take-over rules, so the loop itself can be installed on its own. It does not carry the mechanics of operating GitHub: a GitHub-operation capability owns those, and this skill defers to it rather than shipping a second copy — so a harness driving this loop needs that capability installed alongside it. Where a host project ships its own richer guideline skill for a topic (development, product-requirement, or code-review guidelines), consult that project skill by name and let it own the detail; in its absence, the rules in this skill apply.

This skill can serve as a project's default change loop or be installed into a project that has none of its own. If the host project ships a different, more-specific change-loop skill, that skill owns the loop there — defer to it rather than running this one alongside it (a runtime harness's injected task framing is not such a skill; see the Execution Model's precedence rule).

The concrete tooling named throughout is co-notated per host, because the loop's shape is the same on each and only the instrument differs. Where a rule names a tool it names both forms — in Claude Code, AskUserQuestion, send_later, EnterPlanMode, and a CI reviewer triggered by a comment phrase; in Codex, request_user_input and the equivalents its own harness provides, with @codex review as the review trigger. GitHub itself is reached through whichever sanctioned channel the harness proxies (in Claude Code, the mcp__github__* MCP tools). On a third harness that works the same way, substitute its equivalents; nothing about the loop changes.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

Execution Model

You are the only long-lived actor, and stay so even when implementation is delegated: Code + Verify and mechanical fixes MAY run in one bounded worker at a time where the harness exposes a qualifying one, and in you where it does not. Delegation changes who edits, never what must be approved, verified, or independently reviewed (see Delegated Implementation).

Advance the work as far as you can autonomously within each phase, and stop the turn whenever the next step needs a human, so an idle run consumes nothing. A stopped run is resumed by one of three triggers: