How this skill is triggered — by the user, by Claude, or both
Slash command
/issuesmith:issuesmith-createThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Create a well-structured GitHub Issue from an idea or problem description. Guided conversation from idea to published Issue.
Create a well-structured GitHub Issue from an idea or problem description. Guided conversation from idea to published Issue.
IMPORTANT: Do NOT write any local files during this process. All intermediate content stays in the conversation context. Only the final Issue is persisted via gh issue create.
Input: The user's request should include a description of what they want to build, fix, or improve.
Steps
If the user provides a clear description, proceed. If vague, ask open-ended questions to understand:
From the user's description, detect the type. This affects the title prefix and internal guidance:
| Type | Title prefix | Guidance emphasis |
|---|---|---|
| Feature / Enhancement | [Feature]: | Capability description, user-facing behavior |
| Bug fix | [Bug]: | Reproduction steps, expected vs actual behavior, impact |
| Performance | [Perf]: | Current metrics, target metrics, measurement method |
| Documentation | [Docs]: | Gap description, coverage target, audience |
| Refactoring | [Refactor]: | Current pain points, target architecture, non-functional goals |
If the type is ambiguous, ask the user to confirm.
Based on the user's description and issue type, draft the Background section.
For each type, adapt the framing:
Continue to the next section.
Draft the Goal — a concise statement of what will change once the Issue is resolved.
Continue to the next section.
If the user mentioned explicit scope boundaries, or if the topic naturally invites scope creep, draft Non-goals. If nothing is clearly out of scope, skip this section (it's optional).
Ask the user: "Anything you want to explicitly mark as out of scope?" (Skip if user already mentioned boundaries — if nothing out of scope is apparent, skip this section entirely.)
Derive Acceptance Criteria from the Goal. AC must be a checklist of verifiable statements.
Derivation logic:
Format:
- [ ] User can <observable action>
- [ ] System <observable behavior>
- [ ] When <condition>, <expected outcome>
Example:
Goal: Add a dark mode toggle to settings.
- [ ] User can toggle between light and dark mode in Settings
- [ ] Theme preference persists across page reloads (localStorage)
- [ ] System respects prefers-color-scheme on first visit
- [ ] All existing pages render correctly in both themes
- [ ] Focus states and contrast ratios meet WCAG AA
Continue to the next section.
Derive a Task Checklist from the Goal and Acceptance Criteria.
Rules:
## 1. Infrastructure)- [ ]Example:
## 1. Theme Infrastructure
- [ ] 1.1 Create ThemeContext with light/dark state
- [ ] 1.2 Add CSS custom properties for theme colors
- [ ] 1.3 Implement localStorage persistence
## 2. UI Components
- [ ] 2.1 Create ThemeToggle component
- [ ] 2.2 Add toggle to Settings page
Continue to the next section.
If any technical decisions, trade-offs, or references emerged during the conversation, draft Notes / Decisions.
Combine all confirmed sections into the final Issue body:
### Background
...
### Goal
...
### Non-goals
(omit if empty)
### Acceptance Criteria
- [ ] ...
### Task Checklist
- [ ] 1. ...
### Notes / Decisions
(omit if empty)
Present the complete draft to the user. Ask:
Once the user confirms, create the Issue:
gh issue create \
--title "<prefix><title>" \
--body "<body>" \
--label "<labels>"
Labels by type:
| Type | Suggested labels |
|---|---|
| Feature | enhancement |
| Bug | bug |
| Perf | performance |
| Docs | documentation |
| Refactor | refactor |
Important:
gh is not authenticated, tell the user to run gh auth login.After creation, show:
CRITICAL: Don't ask pointless questions
Guardrails
gh CLI is required, no other external tools.npx claudepluginhub membphis/issuesmith --plugin issuesmithGuides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.