Deliver Change

Todo List

1. in progress: Resolve the governing Change Issue, its verified plan, the base revision, and the in-scope boundary.
2. Run the planning phase with plan-issue, or confirm the plan already posted on the Issue, and record its URL.
3. Execute the plan with implement-issue and record per-task evidence.
4. Open and review the change with create-pr and review-pr, then rework with fix-pr until the review loop terminates.
5. Complete the list only when every phase artifact exists and one cohesive final report is delivered; hand off the Issue URL, Pull Request URL, and per-phase evidence.

Keep exactly one item in progress. Mark an item complete only after its stated evidence exists: a file, a command result, an Issue or Pull Request URL, or another observable artifact. Add or revise items when the agreed scope changes. Use the host's native Todo List when available; otherwise maintain this list as a Markdown checklist in the conversation.

Resolve and Guard

• Resolve the repository, the linked Change Issue, the verified plan, and the Issue-backed branch created from the upstream base. Do not guess a plan; when the Issue has no plan, derive the tasks from its Scope and Acceptance criteria only.
• Route every phase through its owning primitive. This entry point coordinates phases and tracks a single progress model; it never plans, implements, opens Pull Requests, or reviews by itself.
• Do not create the Issue: a governed Change Issue already exists by definition. If no Change Issue exists, stop and report instead of inventing one.
• Preserve approval boundaries: create-pr opens the Pull Request only after user confirmation, implement-issue edits only in-scope files from the verified plan, and fix-pr edits only what a review finding or that same boundary justifies.
• Stop and report when the plan, scope boundary, or branch is unavailable or when a phase cannot produce its artifact; never continue past an unverified handoff.

Route

Run the phases in order. A phase is complete only when its primitive's artifact exists with evidence.

State and authority contract

• One progress model: maintain one Todo List for the whole run and map each primitive's own progress into it; the user never tracks a separate list per phase.
• External mutation authority: only create-pr creates the Pull Request, pausing for user confirmation; fix-pr updates that Pull Request but never creates one. implement-issue edits only files inside the verified plan's in-scope boundary.
• Read-only phases: plan and review never change repository files, Git state, or work items. Plan posts only the plan-issue plan comment, whose marker lets the Project workflow move the Issue to Planned. Review posts only the review-pr findings on the Pull Request or in the linked conversation.
• Handoff rule: every phase hands its artifact to the next owning primitive; an incomplete artifact returns to its owning primitive for rework, never to the entry point's own logic.
• Loop termination: when review-pr returns findings, send them to fix-pr, which fixes, validates, and pushes on the same branch in one pass, then re-review. Terminate when review-pr reports no blocking findings, or after two complete rework passes; then stop and report the unresolved findings with evidence instead of continuing.

Validate and Handoff

• Run the target repository's prescribed checks after implementation and record every command and result; never describe an unrun check as passing. When the repository prescribes none, run its documented test and lint commands and report that no aggregate check exists. In the hidekitux/skills repository, run mise run validate:all, plus mise run validate:skill-creator when available.
• Deliver one cohesive final report: the achieved outcome, the plan URL, phase artifacts and their URLs, validation commands and results, the governing Issue's Project Status, and any remaining risks.
• Hand off only when the change is implemented, validated, and reviewed. Do not merge, release, or expand scope unless the user separately requests it.

Writing quality

Use plain, active, evidence-backed prose in the final handoff. Keep headings in sentence case and name the file, command, or output behind each repository claim.

Choose the plain word over an inflated or Latinate one: write use rather than utilize and is rather than serves as.