Implement PR

Own the change through a green, review-ready PR. Completion is the merge-ready PR, not the finished code.

1. Take ownership of linked work

Read each linked GitHub issue with gh issue view <number> --json title,body,labels,state,comments.

For every linked ticket or work item, record ownership before implementation: Use the tracker's assignee field to assign the item to the currently authenticated user. If assignment is unavailable, use the tracker's explicit ownership or in-progress mechanism.

2. Establish the contract

Run git fetch origin <base-branch> so planning starts from the current base. Read the request, linked tickets or spec, repository instructions, and relevant code before editing. Write a short working contract and a task checklist to a git-ignored file (.claude/tasks.md when git check-ignore -q .claude/tasks.md, run as its own command, exits 0). Tick items off and add new ones as you find them; after compaction, re-read the file instead of the summary. When the code already exists (invoked after an iteration loop), write the contract from the existing diff. The contract has five parts:

• Outcome: observable behavior that must exist.
• Preserve: behavior and interfaces that must stay unchanged. For performance-motivated work, include performance.
• Scope: files, packages, and systems the request permits changing.
• Evidence: focused checks that prove the outcome and preserved behavior, including a benchmark for performance-motivated work.
• Stop: the PR, required CI, and requested review state that define completion.