From specpilot
Start from a feature idea or bug report, run it through speckit, and create the GitHub ticket automatically. Use this when the user runs /specpilot.specify or describes a feature they want to build.
How this skill is triggered — by the user, by Claude, or both
Slash command
/specpilot:specpilot.specifyThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Start from a feature idea or bug report, run it through speckit to produce a full spec, then create the GitHub ticket and subtasks automatically — ready for `/specpilot.implement` to pick up.
Start from a feature idea or bug report, run it through speckit to produce a full spec, then create the GitHub ticket and subtasks automatically — ready for /specpilot.implement to pick up.
Spec-first flow: you drive from an idea, Claude creates the ticket. Use
/specpilot.refineinstead if you want to pick up an existing ticket from the board.
$ARGUMENTS may contain:
--dry-run — run speckit and show what ticket would be created, but don't create it/specpilot.specify "add dark mode toggle") — skip the promptRead .specpilot.json from the project root. If missing, tell the user to run /specpilot.setup first and stop.
Identify:
role: "spec" → speckit writes artifacts herespeckit.workspaceDir → where speckit slash commands run fromgithub.owner, github.projectNumber → where to create the ticket$ARGUMENTS, use itAnalyze the description to determine whether it is:
Classification signals (check in order):
If Bug → go to Step 2b (Bug routing) If Feature → go to Step 3 (Run speckit — full pipeline)
Bugs belong in existing specs, not in new spec folders. Route the bug to the correct parent spec:
List existing specs: Read all spec.md files in the specs directory (speckit.specsDir), scanning recursively to support both flat structures (specsDir/005-foo/spec.md) and app subfolders (specsDir/member/005-foo/spec.md). For each spec, note:
005-recurrent-transactions)member)spec.md)Match the bug to a spec: Compare the description against each spec's scope. Look for:
Confirm with user: Present the match:
"This looks like a bug in [spec name]. I'll add it to
[spec-folder]/spec.mdas a bug fix entry. Correct?"
Write the bug into the existing spec: Append to the "Bug Fixes" section of the matched spec.md:
BUG-R09, BUG-047)Update the plan: If plan.md exists for the matched spec, append a bug fix design section with root cause analysis and fix strategy (run /speckit.plan for the matched spec). If the bug is simple enough (clear fix, no design decisions), this step can be skipped.
Update tasks: If tasks.md exists for the matched spec, append a new phase with implementation tasks for the bug fix (run /speckit.tasks for the matched spec). Follow the existing task format (task IDs, file paths, test tasks).
Go to Step 4b (Create bug ticket)
Run all four speckit commands sequentially from speckit.workspaceDir, using the feature description as input.
App subfolder detection → Before running specify, check if speckit.specsDir contains app subfolders (directories like member/, admin/ that themselves contain numbered spec folders). If multiple app subfolders exist, ask the user which app this feature targets:
"I found multiple app folders in specs: member, admin. Which app is this feature for?" Store the chosen app name for passing to the create-new-feature script via
-App <name>.
specify → Run /speckit.specify "<feature description>". If an app subfolder was selected, the create-new-feature script will receive the -App parameter to create the spec in the correct subfolder.
clarify → Run /speckit.clarify. When clarify has questions:
plan → Run /speckit.plan
tasks → Run /speckit.tasks
Read the generated spec.md and tasks.md. Extract:
tasks.md becomes a GitHub sub-issue or task checklist itemBoth feature and bug flows need the project ID and status field for setting ticket status.
gh project list --owner <owner> --format json, find the project whose number matches config.github.projectNumber, extract its idgh project field-list <projectNumber> --owner <owner> --format json, find the field named Status, extract its id and the option IDs for each status value--dry-run, print the ticket title, body, and subtasks — stop hererole: "feature" repo from config. If none, use the spec repo.--project — linking is done separately to avoid issues with special characters in project titles):
gh issue create --repo <owner>/<repo> --title "<title>" --body "<body>"
This returns the issue URL.- [ ] ...) to the issue bodygh project item-add <projectNumber> --owner <owner> --url <issue-url> --format json
This returns the item ID needed for status updates.gh project item-edit --project-id <projectId> --id <itemId> --field-id <statusFieldId> --single-select-option-id <readyOptionId>config.github.owner for the --owner flag, NOT the current user's login. The project belongs to the org/owner, not the individual user.--dry-run, print what would be created and stoprole: "feature" repo from config. If none, use the spec repo.bug label exists in the target repo:
gh label list --repo <owner>/<repo> --json namebug label is missing, create it: gh label create bug --repo <owner>/<repo> --color "d73a4a" --description "Something isn't working"--project):
gh issue create --repo <owner>/<repo> --title "<short description>" --body "<body>" --label "bug"
[BUG] prefix. The bug label is the canonical marker.Part of spec: [spec-name]), and the bug ID assigned in the spec (e.g. BUG-R09)gh issue create with --label fails (e.g. permissions), fall back to creating without label and add [BUG] prefix to the title insteadgh project item-add <projectNumber> --owner <owner> --url <issue-url> --format jsongh project item-edit --project-id <projectId> --id <itemId> --field-id <statusFieldId> --single-select-option-id <readyOptionId>config.github.owner for the --owner flagFeature flow: In the spec location (speckit.specsDir):
013-feature-name)git push origin <branch>gh pr create --title "<ticket title>" --body "Spec for <ticket title>"Bug flow: Commit the spec/plan/task updates to the current branch (or main) and push:
git add <modified spec files>git commit -m "Add bug fix <BUG-ID> to <spec-name>"git pushPrint:
<owner>#<projectNumber> — <title><branch-name>, Subtasks: N tasks added<spec-folder>/spec.md as <BUG-ID>/specpilot.implement to build itProvides behavioral guidelines to reduce common LLM coding mistakes, focusing on simplicity, surgical changes, assumption surfacing, and verifiable success criteria.
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
npx claudepluginhub eduardo-caua/cogloop --plugin specpilot