| name | issue-creation |
| description | Structured workflow for drafting NEW GitHub issues with codebase research, duplicate detection, and testing approach. Always asks clarifying questions and shows the draft for approval before creating. For searching, listing, viewing, or updating existing issues, use the "issues" skill instead. |
Issue Creation
Create well-researched, problem-focused GitHub issues for mckinsey/agents-at-scale-ark.
When to use this skill
Use when the user asks to create an issue, report a bug, request a feature, or track work. This skill enforces a research-first approach before creating any issue.
Process
Follow these steps in order. Do NOT skip steps.
Step 1: Ask clarifying questions
ALWAYS ask clarifying questions before doing any research or drafting. Never assume you have enough context. Use AskUserQuestion to gather:
- What exactly is the problem? (Get specifics, not just a vague description)
- Who is affected and how severely?
- How is the problem reproduced? (for bugs)
- What is the motivation or trigger? (for features)
- Is there any urgency or deadline?
- Are there any constraints the user already knows about?
Do NOT proceed to Step 2 until the user has answered your questions. If the user's initial description is detailed, still confirm your understanding by summarizing back and asking if anything is missing.
Step 2: Research the codebase
Before writing anything, investigate the relevant code:
- Find the files, modules, and components involved
- Understand the current behavior and architecture
- Identify the scope and blast radius of the problem
- Note relevant file paths and code references
Use Grep, Glob, Read, and the Explore agent as needed. Include key findings in the issue's Context section so reviewers can orient themselves without re-doing the research.
The purpose of research is to understand the problem's scope and surface area — NOT to prescribe a solution. Do not let research findings leak into prescriptive implementation steps. Knowing which files are involved helps the implementer orient; telling them what to change in those files anchors them on a path that may be wrong.
