Claude-session-dashboard open-issue

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".

install

source · Clone the upstream repo

git clone https://github.com/dlupiak/claude-session-dashboard

Claude Code · Install into ~/.claude/skills/

T=$(mktemp -d) && git clone --depth=1 https://github.com/dlupiak/claude-session-dashboard "$T" && mkdir -p ~/.claude/skills && cp -r "$T/.claude/skills/open-issue" ~/.claude/skills/dlupiak-claude-session-dashboard-open-issue && rm -rf "$T"

manifest: .claude/skills/open-issue/SKILL.md

source content

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