Menu
Suggests the next GitHub issue to work on from a PRD breakdown, confirms it with the user, and initiates the pre-implementation discussion.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Triage GitHub issues through a label-based state machine. Use when user wants to create an issue, triage issues, review incoming bugs or feature requests, prepare issues for an AFK agent, or manage issue workflow.
Break a PRD into independent GitHub issues, with backend-first then frontend-linked workflow. Each issue is fully discussed before implementation. Use when converting a PRD to actionable work items.
Find deepening opportunities in a codebase, informed by the domain language in CONTEXT.md and the decisions in docs/adr/. Use when the user wants to improve architecture, find refactoring opportunities, consolidate tightly-coupled modules, or make a codebase more testable and AI-navigable.
Turn the current conversation context into a PRD and submit it as a GitHub issue. Use when user wants to create a PRD from the current context.
Extract a DDD-style ubiquitous language glossary from the current conversation, flagging ambiguities and proposing canonical terms. Saves to UBIQUITOUS_LANGUAGE.md. Use when user wants to define domain terms, build a glossary, harden terminology, create a ubiquitous language, or mentions "domain model" or "DDD".
Grilling session that challenges your plan against the existing domain model, sharpens terminology, and updates documentation (CONTEXT.md, ADRs) inline as decisions crystallise. Use when user wants to stress-test a plan against their project's language and documented decisions.
| name | start-next-issue |
| description | Suggests the next GitHub issue to work on from a PRD breakdown, confirms it with the user, and initiates the pre-implementation discussion. |
Select the next issue to work on from a PRD breakdown, confirm it with the user, and begin the discussion before implementation.
Present the suggested issue with:
Ask the user:
Wait for user confirmation before proceeding.
Once confirmed, start a structured pre-implementation discussion:
Interview the user relentlessly about every aspect of this plan until you reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. Prioritize decisions that block other decisions (e.g. data model before API shape, API shape before UI). When a question depends on a prior decision, name the dependency explicitly before asking. For each question, provide your recommended answer.
Ask the questions one at a time.
If a question can be answered by exploring the codebase, explore the codebase instead.
If the user is unsure how to answer, offer 2–3 concrete options and clearly label which one you recommend. Do not accept "I don't know" and advance.
The interview is complete when every major branch has a decision (or an explicitly noted open question) and you can state the full design back without gaps. At that point, stop asking and produce a wrap-up summary with three sections: decisions made (with brief rationale), assumptions accepted, and open questions still requiring resolution.
NEVER accept "I'll figure that out later" — require a decision or explicitly mark it as an open question before moving on. NEVER ask multiple questions in a single turn — one question, then wait for the answer. NEVER let the user redirect to implementation details until all design branches are resolved.
No coding begins until this step is fully completed and agreed upon.
