| name | open-issue |
| description | Analyze a change request, ask clarifying questions, and create a well-structured GitHub issue with acceptance criteria. Use this skill whenever the user wants to create an issue, write a ticket, log a bug, propose a feature request, or capture requirements — even if they say "let's track this" or "add this to the backlog". |
| user-invocable | true |
| argument-hint | <description> |
Open GitHub Issue
You are creating a GitHub issue for the Claude Session Dashboard — a read-only local observability app that scans ~/.claude to display session data. No database. No auth. Filesystem reads only.
Step 1: Explore
Before asking anything, read relevant code to understand what exists today:
- Read
CLAUDE.md for project conventions
- Find the affected feature slice(s) in
apps/web/src/features/ (sessions, session-detail, stats)
- Check
apps/web/src/lib/ for relevant scanner/parser/utils code
- Look at related routes in
apps/web/src/routes/
- Skim recent commits:
git log --oneline -10
This groundwork means your clarifying questions will be sharper and the issue will reference real file paths.
Step 2: Ask Clarifying Questions
Use AskUserQuestion to fill gaps. Focus on what's genuinely ambiguous — don't ask about things you can infer from the code or the description. Typical areas:
- Scope: What should change? What should stay the same?
- UX: How should this look or behave from the user's perspective?
- Edge cases: Empty states, missing data, large datasets, parse errors
- Priority: Must-have or nice-to-have?
One round is usually enough. Skip questions you can answer from the code.
Step 3: Draft & Confirm
Draft the issue using this template, then show it to the user for approval before creating:
## Summary
<1-2 sentences: what changes and why it matters>
## Context
<Current state — what exists today, why it's insufficient, relevant code locations>
## Affected Areas
<List slices and files, e.g.:
- `apps/web/src/features/sessions/` — session list UI
- `apps/web/src/lib/scanner/` — file scanner
- `apps/web/src/routes/_dashboard/` — route>
## Requirements
1. <Specific, testable requirement>
2. ...
## Acceptance Criteria
- [ ] <Binary pass/fail condition>
- [ ] <Another condition>
- [ ] Quality gates pass (typecheck, lint, test, build)
## Out of Scope
<What this explicitly does NOT cover>
## Technical Notes
<Implementation hints — relevant patterns, file paths, gotchas.
Remember: no database, no auth, no external APIs. Data comes from ~/.claude filesystem reads via createServerFn → React Query → UI.>
Ask: "Does this look right? Any changes before I create it?"
Step 4: Create
Once approved:
gh issue create --title "<title>" --body "<body>"
Report the issue URL and number.
Tips for good issues
- Acceptance criteria should be things you can check off with a yes/no — avoid "should feel fast" or "looks good"
- Reference actual file paths from your Step 1 exploration — it saves the implementer time
- If it's a bug, include reproduction steps
- Keep "Out of Scope" honest — it prevents scope creep later
