spec-to-issue
Skill3 starsChanged 9 days agoMITView on GitHub
Create GitHub Issue from spec documents — Auto-generate structured Feature Issues from specifications.
2 other projects use a version of this.
Adopted by
Most recently taken up by
- jwrobes/skillstheir own version, first seen Oct 9, 2026
- buemura/claude-code-skillstheir own version, first seen Sep 9, 2026
Other versions2 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 2
- buemura/claude-code-skills★ 1same name
- jwrobes/skills★ 1same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository24 other files it gives its agents.
- AGENTS.mdAGENTS.md
- agent-delegateSkill
- cmux-delegateSkill
- cmux-forkSkill
- cmux-second-opinionSkill
- handoverSkill
- harness-initSkill
- harness-loopSkill
- harness-planSkill
- ja-humanizerSkill
- magiSkill
- mcp-convertSkill
- skill-suggestSkill
- spec-codeSkill
- spec-evaluateSkill
- spec-generatorSkill
- spec-implementSkill
- spec-inspectSkill
- spec-orchestrateSkill
- spec-reviewSkill
- spec-rules-initSkill
- spec-testSkill
- spec-workflow-initSkill
- spec-writingSkill
The file
We split this skill into the rules it gives an agent
6 rules. About 0 are common, 5 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈5
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 56
If either is missing, continue only when the remaining documents still define concrete scope and acceptance criteria.
- Distinctive: line 62
Treat the spec files as candidate sources, not as sections to copy.
- Distinctive: line 79
Do not copy phase headings, task headings, estimates, or technology lists by default
- Distinctive: line 82
Keep a candidate only when removing it would change an implementation decision or completion judgment.
- Very specific: line 156
After spec-generator's full phase completes, suggest:
- Distinctive: line 163
If yes, run spec-to-issue on the same directory.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
spec-to-issue — Spec to GitHub Issue
Auto-generate GitHub Issues from spec directories (.specs/{feature}/).
Language Rules
- Auto-detect input language → output in the same language
- Japanese input → Japanese issue, use
references/issue-template.ja.mdas template reference - English input → English issue, use
references/issue-template.mdas template reference - Explicit override takes priority
Reference file selection: Based on the detected output language, use the corresponding template:
- English →
references/issue-template.md - Japanese →
references/issue-template.ja.md
Execution Flow
1. Locate Spec Directory
With argument: spec-to-issue auth-feature → use .specs/auth-feature/
Without argument: Scan .specs/ and present a list → ask user to select
Spec directories found in .specs/:
1. auth-feature (requirement.md, design.md, tasks.md)
2. member-management (requirement.md, tasks.md)
Which spec do you want to create an issue from?2. File Validation
Required: requirement.md must exist. Otherwise, exit with error.
Recommended: design.md and tasks.md.
If either is missing, continue only when the remaining documents still define
concrete scope and acceptance criteria; report the missing source before issue
creation.
3. Spec Analysis
Treat the spec files as candidate sources, not as sections to copy. Extract and select:
requirement.md:
- Title: First
#line, strip suffixes like "Requirements", "要件定義書" - The problem and observable completed state
- Current and expected behavior
- Included and excluded scope
- Requirement-level acceptance criteria
design.md:
- Decisions constrained by compatibility, security, external contracts, or another requirement, including the reason
- Open questions that the implementer cannot safely decide alone
tasks.md:
- Supporting implementation detail and additional completion evidence
- Do not copy phase headings, task headings, estimates, or technology lists by default
Keep a candidate only when removing it would change an implementation decision or completion judgment. See the selected language's issue-template reference for the complete selection procedure.
4. Resolve Project Settings
Determine defaults in this priority order:
Command arguments > .specs/.config.yml > CLAUDE.md > Built-in defaultsFrom CLAUDE.md:
- Branch name: PR target branch from Git Workflow section →
--branchdefault - GitHub Organization: Inferred from repository URL
.specs/.config.yml (optional):
default-branch: develop
default-labels: [feature, spec-generated]
project-number: 7
assignee: username5. Resolve the Project Template and Compose the Issue Body
Inspect the repository's Issue forms, Issue templates, contribution rules, and required fields before composing the body. A project template takes priority: preserve its headings, order, fields, and checkboxes, and map the selected information into it.
See template details in the appropriate reference file (based on Language Rules):
- English: references/issue-template.md
- Japanese: references/issue-template.ja.md
Without a project template, compose an execution contract that identifies the problem, completed state, current and expected behavior, included and excluded scope, acceptance criteria, binding decisions, and open questions. Link to the spec files for task decomposition and supporting detail.
6. Create Issue
Without --preview (default): Show a brief summary and execute gh issue create
Creating Issue:
Title: [Feature] Member Management
Labels: feature, spec-generated
Outcome: Members can be invited and assigned a repository role
Acceptance criteria: 4
→ Running gh issue create...
Issue #42 created: https://github.com/org/repo/issues/42With --preview: Display the full issue body, confirm, then execute
7. Additional Actions (optional)
--label: Apply specified labels--project: Add to GitHub Project board viagh project item-add--assignee: Set assignee
Options
| Option | Description | Default |
--preview | Display issue body for confirmation | OFF |
--label <labels> | Comma-separated labels | .config.yml value or none |
--project <number> | Add to GitHub Project | .config.yml value or none |
--branch <name> | Base branch for spec links | CLAUDE.md or main |
--assignee <user> | Set assignee | .config.yml value or none |
Integration with spec-generator
After spec-generator's full phase completes, suggest:
All three spec documents have been generated.
→ Create a GitHub Issue from them? (Y/n)If yes, run spec-to-issue on the same directory.
Error Handling
| Situation | Response |
.specs/ does not exist | Error: Spec directory not found |
requirement.md missing | Error: requirement.md is required |
design.md or tasks.md missing | Continue only if concrete scope and acceptance criteria remain; otherwise stop and report the missing source |
gh CLI not authenticated | Error: Guide user to gh auth login |
| Concrete acceptance criteria missing | Stop before issue creation; do not invent generic completion checks |
| Project template found | Preserve its required headings and fields instead of appending the built-in template |
Usage Examples
# With argument
/spec-to-issue auth-feature
# Auto-detect and select
/spec-to-issue
# With preview
/spec-to-issue auth-feature --preview
# With labels and Project
/spec-to-issue auth-feature --label "feature,priority:high" --project 7
# After spec-generator
"Create full spec for todo-app" → done → "Turn this into an issue"
# Japanese
「仕様書を全部作って」→ 完了 →「これをIssueにして」Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

