一键导入
speckit-taskstoissues
Convert existing tasks into actionable, dependency-ordered GitHub issues for the feature based on available design artifacts.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Convert existing tasks into actionable, dependency-ordered GitHub issues for the feature based on available design artifacts.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | speckit-taskstoissues |
| description | Convert existing tasks into actionable, dependency-ordered GitHub issues for the feature based on available design artifacts. |
| argument-hint | Optional filter or label for GitHub issues |
| compatibility | Requires spec-kit project structure with .specify/ directory |
| metadata | {"author":"github-spec-kit","source":"templates/commands/taskstoissues.md"} |
| user-invocable | true |
| disable-model-invocation | false |
$ARGUMENTS
You MUST consider the user input before proceeding (if not empty).
Check for extension hooks (before tasks-to-issues conversion):
Check if .specify/extensions.yml exists in the project root.
If it exists, read it and look for entries under the hooks.before_taskstoissues key
If the YAML cannot be parsed or is invalid, skip hook checking silently and continue normally
Filter out hooks where enabled is explicitly false. Treat hooks without an enabled field as enabled by default.
For each remaining hook, do not attempt to interpret or evaluate hook condition expressions:
condition field, or it is null/empty, treat the hook as executablecondition, skip the hook and leave condition evaluation to the HookExecutor implementationWhen constructing slash commands from hook command names, replace dots (.) with hyphens (-). For example, speckit.git.commit → /speckit-git-commit.
For each executable hook, output the following based on its optional flag:
Optional hook (optional: true):
## Extension Hooks
**Optional Pre-Hook**: {extension}
Command: `/{command}`
Description: {description}
Prompt: {prompt}
To execute: `/{command}`
Mandatory hook (optional: false):
## Extension Hooks
**Automatic Pre-Hook**: {extension}
Executing: `/{command}`
EXECUTE_COMMAND: {command}
Wait for the result of the hook command before proceeding to the Outline.
If no hooks are registered or .specify/extensions.yml does not exist, skip silently
.specify/scripts/bash/check-prerequisites.sh --json --require-tasks --include-tasks from repo root and parse FEATURE_DIR and AVAILABLE_DOCS list. All paths must be absolute. For single quotes in args like "I'm Groot", use escape syntax: e.g 'I'''m Groot' (or double-quote if possible: "I'm Groot").git config --get remote.origin.url
[!CAUTION] ONLY PROCEED TO NEXT STEPS IF THE REMOTE IS A GITHUB URL
[!CAUTION] UNDER NO CIRCUMSTANCES EVER CREATE ISSUES IN REPOSITORIES THAT DO NOT MATCH THE REMOTE URL
Check for extension hooks (after tasks-to-issues conversion):
Check if .specify/extensions.yml exists in the project root.
If it exists, read it and look for entries under the hooks.after_taskstoissues key
If the YAML cannot be parsed or is invalid, skip hook checking silently and continue normally
Filter out hooks where enabled is explicitly false. Treat hooks without an enabled field as enabled by default.
For each remaining hook, do not attempt to interpret or evaluate hook condition expressions:
condition field, or it is null/empty, treat the hook as executablecondition, skip the hook and leave condition evaluation to the HookExecutor implementationWhen constructing slash commands from hook command names, replace dots (.) with hyphens (-). For example, speckit.git.commit → /speckit-git-commit.
For each executable hook, output the following based on its optional flag:
Optional hook (optional: true):
## Extension Hooks
**Optional Hook**: {extension}
Command: `/{command}`
Description: {description}
Prompt: {prompt}
To execute: `/{command}`
Mandatory hook (optional: false):
## Extension Hooks
**Automatic Hook**: {extension}
Executing: `/{command}`
EXECUTE_COMMAND: {command}
If no hooks are registered or .specify/extensions.yml does not exist, skip silently
Verify Linear backlog tickets against the actual codebase before anyone implements them — extract each ticket's checkable claims, grep the code to confirm or refute, classify by scope, and leave an evidence-backed triage comment. Use when the user says "triage the backlog", "comb through Linear tasks", "verify these tickets", "/linear-triage", or on a schedule. Not for implementing fixes (use linear-to-pr on tickets triaged valid), and never changes ticket state beyond commenting unless explicitly told to.
Verify any UI-affecting change end-to-end before declaring it done — boot the app, interact with the change via Playwright, capture before/after screenshots (light/dark, desktop/phone), check console errors, and attach the evidence. Use after implementing or reviewing any change to components, routes with visible output, layouts, styling, or theming. Triggers include "verify this UI change", "did the banner/button/layout change work", or finishing any *.tsx edit that alters rendered markup or classes. Not for server-only changes (models, API routes, env plumbing), docs, or pure test edits.
Explore the running Iridium app like a curious, destructive user and file GitHub issues for confirmed bugs. Picks an exploration charter (auth, notes, chat, settings, admin, mobile), drives the app with Playwright, reproduces every finding twice, dedupes against open qa-explorer issues, and files structured reports with repro scripts. Use when the user says "qa sweep", "explore the app for bugs", "run the qa explorer", "hunt for bugs", or "do some exploratory testing". Not for implementing fixes (use github-issue-to-pr on the filed issues), not for deterministic regression tests (those live in tests/), and never against production.
Drive a GitHub issue to an open pull request. Fetches the issue with gh, self-assigns, creates a linked branch via gh issue develop, implements the change, runs validation plus targeted Playwright e2e tests, captures screenshots of UI changes and links them from the PR body, and opens the PR with a closing "Fixes
Drive a Linear issue to an open GitHub pull request. Fetches the issue, branches using Linear's suggested branch name, implements the change, runs validation plus targeted Playwright e2e tests, captures screenshots of UI changes and links them from the PR body, opens the PR with gh, and moves the issue to a review status. Use when the user says "work on ABC-123" (any Linear issue identifier), "take this Linear issue to a PR", "implement this ticket", "linear to pr", or pastes a linear.app issue URL to be implemented. Not for creating or triaging Linear issues, and not for reviewing or merging existing PRs.
MANDATORY color usage rules for daisyUI 5