gh-reopen

Bring a closed issue back into the lifecycle when its work regresses or needs additional follow-up. Closes the gh-pms loop's missing reverse arrow.

When to use

• User says "reopen #N", "X regressed since release", "we need to fix #N again"
• A done feature surfaced a bug that's actually a regression of the original work, not a new defect
• Post-release rework that should re-use the original issue's history rather than spawn a duplicate

Inputs

gh-reopen <issue-number> --reason "<text>" [--force] [--no-branch]

Flag	Required	Effect
<issue>	yes	Closed issue number to reopen.
--reason	yes	Short why-text. Becomes part of the reopen comment + audit trail.
--force	no	Bypass the WIP-limit guardrail (assignee already has an in-progress issue).
--no-branch	no	Skip auto-creating a fresh feature branch. Use only when continuing work in an existing branch.

What it does

Step 1 — Pre-flight

1. Verify the issue is currently closed:

   bash

   If OPEN, refuse: "Issue #${N} is already open. Use /gh-pms:gh-current to start work on it."

2. Verify WIP guardrail unless --force:

   bash

   Refuse if non-empty: "You already have an in-progress issue (#${other}). Finish it or pass --force."

Step 2 — Reopen on GitHub

Step 3 — Reset status

Use the unified setter so label + Project v2 field stay atomic:

This swaps status:done for status:in-progress AND updates the Project board's Status field.

Step 4 — Audit comment

Pull the previous close timestamp and the closing PR (if any) for context:

Post:

Step 5 — Create a fresh feature branch (unless --no-branch)

Same template as gh-current, with kind_short derived from the issue's type:* label:

Append the branch name to the audit comment so future visitors see where the rework happened.

Step 6 — Update local state file

Step 7 — Report

If reopen_count >= 3, also surface a warning: this issue has reopened ≥3 times — consider splitting it or filing a follow-up chore to address the underlying instability.

Cross-skill contract

• A reopened issue starts fresh from in-progress — it does NOT skip Gates 1-5 just because they passed pre-close. The gates are the source of truth for "is the new work also done".
• gh-status and gh-context should both surface reopened issues distinctly (e.g. 🔁 #N) so the team sees recurrence at a glance.
• If the regression is severe (production impact), prefer filing a fresh gh-bug linked to the original via /gh-pms:gh-relate related_to. Reopen is for "this issue's work needs more iteration", not "this issue caused a critical incident".

Notes

• Out of scope: reopening a closed-as-not-planned (rejected) issue — for those, file a fresh issue if the user changed their mind. Reject means reject.
• Out of scope: re-running gates already passed pre-close. The lifecycle restarts cleanly.