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".
Scanned 5/27/2026
Install via CLI
Skills Directoryopenskills install dlupiak/claude-session-dashboard---
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:
```bash
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
No comments yet. Be the first to comment!
