plan-to-github-issue
This skill runs in two phases so plan approval never blocks on a question you won't see for an hour.
- Phase A — Defer (right after ExitPlanMode): record that a plan issue is pending, print one line, and hand control back so implementation starts immediately. No blocking question.
- Phase B — Resolve (before the first commit/PR, or on explicit request): that's when you're back at the keyboard, so that's when you ask how to save the plan, then do it.
Why: a blocking "save as issue?" right after plan approval freezes the session — the user walks away expecting work to begin and only sees the prompt much later. Deferring the question to commit/PR time removes the wait entirely while still capturing the issue at a natural checkpoint.
A plan isn't always a brand-new issue. It might hang off an existing issue you started work from, or be the second plan on a branch that already has one. Phase A only records context (which issue, if any, the plan came from); Phase B is where you and the user decide the disposition, because that's a judgement call best made with the user present.
Never edit an existing issue's body. When a plan started from / was loaded against an existing issue, that issue's body is the user's — clobbering it (overwrite, "replace body", "append section to body") is exactly what this skill must not do. A plan attaches to an existing issue only as a sub-issue or a comment. The only body this skill ever writes is one on a brand-new issue it creates itself.
Never post a plan as a pull-request comment. A PR's conversation belongs to review — people open it expecting feedback on the diff, and a design doc dropped in the middle buries that. A plan parked there also can't be closed, tracked, or referenced by Closes #N, so it's a dead end as a record of the work. What makes this a trap rather than a mistake you'd catch: GitHub stores pull requests in the same table as issues, so gh issue comment <pr-number> posts to the PR and exits 0 — no error to notice — and an option that reads "comment on #5" is easily heard as comment on an existing issue when #5 is actually the PR. So don't offer it, and if the user proposes it, say the plan belongs in an issue and offer to create one. A plan's only homes are its own new issue, a sub-issue, or a comment on a real issue.