How do I install the Open Issue skill?

Run npx skillmds add majiayu000/open-issue-2 in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Open Issue safe to use?

This skill has not completed SkillMD's automated safety review yet. Capability flags: docs only. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Open Issue?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Open Issue free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Open Issue?

majiayu000 (@majiayu000) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Open Issue by majiayu000 — Agent Skill

Name: Open Issue
Rating: 4.666666666666667 (3 reviews)
Author: majiayu000

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

majiayu000 c0a784c 2 files · 4.0 KB Updated Sep 9, 2026 567 repo stars

File contents

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

---name: open-issue-2description: 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".--- # 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

Frequently asked questions