メニュー
Use when the user has a spec, architecture doc, implementation plan, or feature description and wants to break it into Jira tickets for distribution to people or agents. Also triggered by "create tickets from this plan" or "file tickets for this spec".
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | jira-decompose |
| description | Use when the user has a spec, architecture doc, implementation plan, or feature description and wants to break it into Jira tickets for distribution to people or agents. Also triggered by "create tickets from this plan" or "file tickets for this spec". |
Reads a source document, proposes a ticket hierarchy, gets user approval, then creates all tickets with proper parent/child relationships.
Accept input as:
Analyze the document and propose a hierarchy — one epic for the overall effort, stories/tasks as children scoped to independently deliverable chunks.
Each ticket gets: summary, description with acceptance criteria, suggested assignee if mentioned in the source.
Present for approval:
Proposed breakdown for "Auth System Redesign":
Epic: AUTH-??? "Auth System Redesign"
├── Task: "Migrate session store to Redis" — assignee: alice@...
├── Task: "Implement JWT refresh flow" — assignee: bob@...
├── Task: "Add rate limiting to auth endpoints" — unassigned
└── Task: "Update auth integration tests" — unassigned
Create these 5 tickets? (You can adjust before I create them)
Always propose before creating. Bulk ticket creation is hard to undo. Wait for explicit user approval.
On approval, create in order:
Epic first:
acli jira workitem create --summary "Epic title" --project "PROJ" --type "Epic" --description "..." --yes
Children with parent linkage:
acli jira workitem create --summary "Task title" --project "PROJ" --type "Task" --parent "EPIC-KEY" --description "..." --assignee "user@email.com" --yes
Repeat for each child ticket. Capture the returned key for each.
Created 5 tickets in PROJ:
| Key | Summary | Type | Assignee |
|-----|---------|------|----------|
| PROJ-100 | Auth System Redesign | Epic | — |
| PROJ-101 | Migrate session store to Redis | Task | alice@... |
| PROJ-102 | Implement JWT refresh flow | Task | bob@... |
| PROJ-103 | Add rate limiting to auth endpoints | Task | unassigned |
| PROJ-104 | Update auth integration tests | Task | unassigned |
If ACLI returns exit code != 0:
acli jira auth login --web --site <site>.atlassian.netbrew tap atlassian/homebrew-acli && brew install acliUse when needing to understand a Jira ticket before acting on it — pulling context for an agent, reviewing a ticket's full picture, loading ticket details for decision-making, or when asked to "show me" or "what's in" a ticket.
Use when work on a ticket has reached a stage boundary — started working, sent for review, completed, blocked, or reopened. Handles status transition, comment, and field updates in one pass.
Use when the user mentions Jira, issues, tickets, sprints, work items, or any project management task involving Atlassian. Routes to workflow skills or delegates to jira-agent subagent.
Use when the user assigns a ticket to the agent, says "work on this ticket", "pick up this item", or wants the agent to claim a ticket and execute against it. Procedural harness that wraps any work with Jira discipline.
Use when a project's workflow statuses need to be configured for the first time, or refreshed. Triggered automatically by jira-progress when a project is missing from config/workflows.json, or manually via "configure workflow", "set up statuses for X", "refresh workflow for X".
This skill should be used when the user asks to "refresh Todoist", "sync Todoist", "list my projects", "show my labels", "update Todoist structure", "show my Todoist sections", or when a todoist-agent operation fails with a not-found error for a project, label, or section name. Fetches and caches Todoist structure for name-to-ID resolution.