Implement and publish

Take a specification through implementation and an independent local review, then publish it as exactly one pull request. Publishing means pushing the reviewed branch and creating or updating its pull request, never merging or deploying. review-code-publish owns the published review.

Implementation method, investigation, sequencing, tools, and additional verification are yours to choose within the user's instructions, any implementation skill they name, and repository conventions.

Resolve the delivery

Resolve the forge, source and target repositories, base branch, and every issue, ticket, and written specification the change addresses, including those inferred from the request, branch, and commits. Use repository tracker configuration such as docs/agents/issue-tracker.md where present. Settle consequential ambiguity before any external write, continuing independent local work meanwhile.

If the review-code skill is not installed, report missing-dependency: review-code before implementing.

Work on a branch suitable as a pull-request head, never the base. Leave issue status, labels, and assignees alone.

Implement and keep evidence

Complete the requested behavior and commit it. Run the repository's documented checks for affected behavior and its dependents. Choose further checks and acceptance exercises by the change's risks, verifying more broadly where impact is uncertain.

Keep a compact evidence summary under the Supplied checks section of review-code's references/rubric.md, which owns its form and reuse rules. Add each acceptance exercise's criterion, method, and observation, and any required work that is missing and why. After a change, update it with which evidence still applies and which was replaced. Never rerun a check only to fill the summary.