update-github-issue

name	update-github-issue
description	Refine a GitHub issue title, description, and acceptance criteria through a planning conversation, then update the issue after explicit approval. Use when the user asks to update-github-issue, improve an issue, or rewrite issue acceptance criteria.
disable-model-invocation	true

Update GitHub Issue

Refine an existing GitHub issue's title, description, and acceptance criteria through a planning conversation, then update the issue after explicit approval.

Gather context first:

git remote get-url origin

Step 1 — Resolve the target issue

• Parse the git remote above to determine owner and repo. If ambiguous, ask the user.
• Ask the user for the issue number (if not already provided in the conversation).
• Fetch the current issue using GitHub MCP issue_read (method get) with owner, repo, and issue_number.
• Summarize the current title and body so the user has context.

Step 2 — Gather context

Ask the user 2-5 concise questions to understand:

1. Problem statement — What problem does this issue solve?
2. Desired outcome — What should be true when this is done?
3. Scope — What is in scope and what is explicitly out of scope?
4. Implementation approach — Any known technical direction or constraints?
5. Definition of done — How do we verify this is complete?

Use the AskQuestion tool to present these as structured questions when possible. Adapt or skip questions if the existing issue body already answers them clearly.

Step 3 — Explore the codebase (if needed)

If the issue involves code changes, briefly explore the relevant parts of the codebase to inform the description and acceptance criteria. Keep this lightweight — only do it if it improves the quality of the output.

Step 4 — Propose the updated issue

Present the following for the user's review:

• New title — Must follow conventional commits style: <type>(<scope>): <short description>. Use lowercase. Common types: feat, fix, refactor, chore, docs, perf, test, ci, style. Scope is optional but encouraged (e.g. feat(gallery): add session expiry warning banner).
• New description — Structured with:
  • Problem / Context — Why this issue exists.
  • Desired outcome — What the end result should look like.
  • Scope — What is in and out of scope.
  • Technical notes — Implementation hints, affected files/layers, or constraints (if applicable).
• Acceptance criteria — A numbered or bulleted checklist. Each item should be testable and scoped. Use checkbox format (- [ ]).

Format acceptance criteria as concrete, verifiable statements, for example:

• - [ ] User sees a warning banner 5 minutes before session expiry
• - [ ] Banner includes a "Refresh session" button that extends the session

Step 5 — Wait for approval

Do NOT update the issue until the user explicitly approves (e.g. "yes", "looks good", "update it", "approved").

If the user requests changes, revise the proposal and present it again.

Step 6 — Update the issue

After approval, call GitHub MCP issue_write with:

• method: update
• owner, repo, issue_number: from step 1
• title: the approved new title
• body: the approved new description including the acceptance criteria section

Confirm success and provide the issue URL.