work-on-issue

# work-on-issue Take a GitHub issue from "validated" to "PR open", autonomously and end-to-end: isolate the work in a fresh worktree, implement the fix to the codebase's conventions, verify it really works, commit and push, then open a pull request that closes the issue. The skill ends with the open PR — requesting review is the caller's job (work-on-issue-loop does it; standalone, the user decides). Don't stop to ask the user between steps — do the work and report at the end. **This is the natural follow-on to validate-issue** — when it ends with `→ Reply "work on issue"`, the user replying "work on issue" lands here. The skill is also valid standalone, without a prior validation pass. **Implement the issue, not your memory of it.** Re-read the issue and any validation findings before writing code; the description can be stale or wrong (that's what validate-issue exists to catch). Build the fix the traced code supports, not the one the prose suggests. ## Input The user provides one of: - Nothing — **default to the issue just validated this session**, else the latest open issue (`gh issue list --limit 1`). - `#<N>` / `<N>` / full URL / `owner/repo#N`. - `{ issue: <N>, baseRefs: [{ pr: <PR number>, ref: "<head branch>", sha: "<head commit>" }, ...] }` — orchestration-only form for hard dependencies. `baseRefs` is optional; when present, its order is authoritative and deterministic (upstream track order), and every entry pins a predecessor pull request's reviewed readiness...