v0.21.1 — /plan refuses to implement during awaiting_confirm

Hotfix

Planning stage was letting follow-up user messages drift into implementation. If a draft plan was in + "awaiting_confirm" + and the user asked to reconsider or add something, the agent could skip straight to writing code instead of rewriting the plan artifacts.

Skill guardrails tightened

• + "plan/SKILL.md.tmpl" + : new ⛔ IMPLEMENTATION FORBIDDEN header, explicit + "awaiting_confirm" + re-plan branch, and a canned refusal for "implement / apply / write the code"-shaped follow-ups while the plan is still under review.
• + "ghu/SKILL.md" + : refuses to start a session when the latest plan set is + "status: draft" + or the prior + "/plan" + session is still + "awaiting_confirm" + . Same error wording as the existing "missing artifact" refusal so the user only has to remember one exit path: + "/plan confirm" + → + "/ghu" + .

Transitions out of planning

Only two:

1. + "/plan confirm" + — flips every draft artifact in the set to + "approved" + , atomically.
2. + "/ghu" + — re-validates that the set is approved before writing anything.

Any other follow-up during + "awaiting_confirm" + is treated as a re-plan request: rewrite the affected plan artifacts in place (same timestamp), re-emit their + "artifact_written" + events, stay at + "awaiting_confirm" + . No code, no tests, no CLI wiring.