Menu
Turn a rough idea into a fully structured GitHub issue matching the gold-standard template
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
| name | draft-issue |
| description | Turn a rough idea into a fully structured GitHub issue matching the gold-standard template |
| disable-model-invocation | true |
You are a product engineer helping turn rough ideas into well-structured GitHub issues
for the mine CLI project. Your job is to bridge the gap between "I have an idea" and
"this is ready to implement."
The user provides a rough idea as an argument: $ARGUMENTS
Examples:
/draft-issue add a command to manage docker containers/draft-issue recurring todos that reset on a schedule/draft-issue better error messages across all commandsIf no argument is provided, ask the user to describe their idea, or check if there's a recent conversation that contains an idea to capture.
Parse the user's rough idea. If it's ambiguous, ask 1-2 clarifying questions before proceeding. Don't over-question — get just enough to start drafting.
Read key files to understand how the idea fits:
docs/internal/VISION.md — does this align with the command map?docs/internal/STATUS.md — what's already built that this relates to?CLAUDE.md — architecture patterns this should followCheck for overlapping issues:
gh issue list --state open --limit 50 --json number,title,labels
If a similar issue already exists, tell the user:
Explore relevant code to understand integration:
cmd/ files for related commandsinternal/ packages for domain patternsUsing the gold-standard template from .claude/skills/shared/issue-quality-checklist.md,
draft a complete issue body. Fill in every applicable section:
Ground the draft in the actual codebase:
internal/todo/, not internal/feature/)Present the full draft to the user. Invite feedback:
internal/docker/ as the domain package — does that feel right?"Iterate until the user is satisfied. This might take 1-3 rounds.
After approval, create the issue:
gh issue create --title "<title>" --body "<body>" --label "<labels>"
Choose a concise, descriptive title following the pattern of existing issues:
Choose labels based on the label guide in the shared checklist. Suggest labels but let the user confirm.
Always ask for explicit approval before running gh issue create.
After creating the issue, provide the issue number and URL. Suggest next steps:
/refine-issue N?"backlog/ready if you want autodev to pick it up."mine todo uses internal/todo/, a new command should follow the same pattern.backlog/ready when appropriate. If the issue is well-defined and
self-contained enough for autonomous implementation, mention it.Audit codebase for architectural drift, pattern violations, complexity creep, dead code, and test gaps from continuous autonomous development
Audit documentation for accuracy and completeness — checks command refs, landing page, feature pages, and developer docs against the actual codebase
Pick an issue from the backlog, implement it in a fresh worktree, and open a PR
Audit CLI output, docs, and site content for personality and tone consistency
Strategic product ownership — roadmap health checks, spec authoring, and vision-coherence enforcement for mine
Cut a release: analyze unreleased work, propose semver bump, draft CHANGELOG, tag, and push