implementlisted

# Implement a change end-to-end Goal: take an implementation request (a GitHub issue, a described change, a bug fix, …) all the way from a fresh branch to a merged PR with green CI on `main`, without leaving stale local state behind. Work the phases in order; each one gates the next. **This ships code and touches the remote.** Pushing, opening a PR, and merging are outward-facing and hard to reverse — do them deliberately, never merge a PR your own review says isn't safe, and never merge without the user's explicit go-ahead (phase 6). If a phase's exit condition isn't met, stop and report rather than pushing ahead. First, be sure you understand the task. If it's a GitHub issue, read it: `gh issue view <N>` (this shows its assignees). If the request is ambiguous in a way that changes what you'd build, ask before writing code — not after. **Don't take over someone else's issue.** If the issue is assigned to a GitHub user *other than* the requesting user (`gh api user --jq .login`), stop and confirm with the user before doing anything — an assignee means someone has claimed it, and building it would collide with their work. Two cases are fine to proceed on without asking: an **unassigned** issue, and one **already assigned to the requesting user**. A foreign assignment is **reclaimable** once it has gone idle for long enough — and "long enough" scales with what waiting costs, rather than being one fixed timer: | What the issue is | Reclaimable after | |---|---| | A **live