60 lines
2.3 KiB
Markdown
60 lines
2.3 KiB
Markdown
---
|
|
description: Interactive issue creation for the current project board. Gathers context, checks code, builds wireframes or code examples, then files the issue.
|
|
---
|
|
|
|
The user invoked `/issue` with argument: `$ARGUMENTS`
|
|
|
|
You are collecting issues for a project board related to the repo and work in the current session. Follow this workflow:
|
|
|
|
## 1. Gather the idea
|
|
|
|
If `$ARGUMENTS` is empty, ask the user what they want to file — use the Question tool with a text input.
|
|
|
|
Otherwise, use `$ARGUMENTS` as the starting point.
|
|
|
|
## 2. Clarify with interactive questions
|
|
|
|
Ask the user clarifying questions using the Question tool:
|
|
- Which repo does this belong to?
|
|
- What type? (Bug / Feature / Task)
|
|
- Priority? (P0 critical / P1 high / P2 normal)
|
|
- Size estimate? (XS / S / M / L / XL)
|
|
- Which board? (Madcat / Campus OS) — default to whichever board matches the current project context.
|
|
|
|
Skip questions where the answer is obvious from context or user input.
|
|
|
|
## 3. Check the code
|
|
|
|
Search the relevant codebase to understand the current state:
|
|
- Find the files, controllers, views, services, or components related to the issue.
|
|
- Note file paths and line numbers for reference in the issue body.
|
|
- Understand what exists vs what needs to change.
|
|
|
|
## 4. Follow-up questions
|
|
|
|
If the code review reveals ambiguity or design choices, ask the user using the Question tool before proceeding.
|
|
|
|
## 5. Build visual or code context
|
|
|
|
### Frontend work
|
|
- Use the Browse tool to navigate to the relevant page/view.
|
|
- Take a screenshot of the current state.
|
|
- If useful, create a simple wireframe sketch (HTML page rendered in browser) showing the proposed change, screenshot it.
|
|
- Upload screenshots to CDN and embed the markdown URL in the issue body.
|
|
|
|
### Backend work
|
|
- Write a concise code example (pseudocode or real) showing the proposed change — keep it short, 5-15 lines max.
|
|
- Include in the issue body as a fenced code block.
|
|
|
|
## 6. Compose and file the issue
|
|
|
|
Use appropriate issue templates and fill them in with the gathered context.
|
|
|
|
Follow the title convention: plain descriptive language, NO prefixes like `[BUG]`, `P1`, `M1`.
|
|
|
|
Write the full issue body to a temp file and use `gh issue create --body-file <path>` via Bash to preserve markdown formatting.
|
|
|
|
## 7. Confirm
|
|
|
|
Present the created issue URL and a one-line summary to the user.
|