jira-driven-planning
This Jira-driven planning skill transforms Jira ticket requirements and Confluence documentation into structured implementation roadmaps organized across Frontend, Backend, and Infrastructure domains. Use it when you need to break down project requirements into actionable task divisions, establish technical approaches with architectural justification, identify dependencies and blockers, and surface risks with mitigation strategies. The skill assumes Jira ticket metadata and relevant Confluence documents have already been retrieved upstream.
git clone --depth 1 https://github.com/breaking-brake/cc-wf-studio /tmp/jira-driven-planning && cp -r /tmp/jira-driven-planning/.claude/skills/jira-driven-planning ~/.claude/skills/jira-driven-planningSKILL.md
# Jira Driven Planning Jiraチケットの要件とConfluenceの関連ドキュメントを入力として、Frontend / Backend / Infrastructure に分割した実装計画を策定する。 ## Workflow 1. 前段で取得されたJiraチケット情報（タイトル、説明、受け入れ基準、優先度）を確認 2. 前段で取得されたConfluenceドキュメント（設計書、仕様書、アーキテクチャ図）を確認 3. [planning-template.md](references/planning-template.md) に従って実装計画を策定 4. 計画をユーザーに提示し、レビューを依頼 ## Output Requirements - 要件サマリーは箇条書きで簡潔に - 技術的アプローチはアーキテクチャ判断の根拠を含める - タスク分割は Frontend / Backend / Infrastructure の3軸で整理 - 依存関係はブロッカーを明示 - リスクは重大度と対策をセットで記載 ## Constraints - 既存のコードベースやアーキテクチャパターンを尊重する - 不明確な要件がある場合はユーザーに確認を求める - 過度に詳細な実装レベルまで踏み込まず、計画レベルに留める
AI workflow editor for CC Workflow Studio. Create and edit visual AI agent workflows through interactive conversation using MCP tools (get_workflow_schema, get_current_workflow, apply_workflow, update_nodes). Use when the user wants to create a new workflow, modify an existing workflow, or edit the workflow canvas in CC Workflow Studio via the built-in MCP server.
Use the `ccwf` CLI (from @cc-wf-studio/cli) to render, validate, preview, export, or run cc-wf-studio workflow JSON files from the terminal. Apply whenever the user mentions viewing, visualizing, checking, executing, or converting a workflow under `.vscode/workflows/` (or any `*workflow*.json`), wants a Mermaid diagram of a workflow, asks to "see" / "preview" / "open" a workflow, or wants to run a workflow as a Claude Code Skill without opening VSCode.
Run one unattended IDEATION iteration of the autonomous value-creation loop — invent improvements a user of cc-wf-studio would notice, judge them against the value bar, and file the winners as locked `idea` issues. Never implements anything; the next-task skill builds from the queue this skill fills. Use when the user says "アイデア出して", "next idea", or wants proposals without implementation.
Run one unattended iteration of the QUALITY-ASSURANCE loop — steward any in-flight QA PR, then build ONE queued `qa` issue (test infrastructure, unit tests, regression tests for known bugs) on a branch off auto-qa and open a PR that squash-merges on green CI. Adds tests and tooling only; never edits product source. Use when the user says "QAタスク", "next qa", "テストを進めて", or wants autonomous progress on the quality track.
Run one unattended IDEATION iteration of the quality-assurance loop — find the highest-value untested behavior in the codebase, judge it against the QA value bar, and file ONE locked `qa` issue specifying the test to write. Never writes code or tests; the next-qa skill builds from the queue this skill fills. Use when the user says "QAアイデア", "next qa idea", or wants the QA backlog refilled without implementation.
Run one unattended IMPLEMENTATION iteration of the autonomous value-creation loop — steward any in-flight PR, fix interrupts (red CI / security / human bugs), or else build ONE queued `idea` issue on a branch off auto-dev and open a PR that squash-merges on green CI. Ideation lives in the next-idea skill; this skill consumes its queue. Use when the user says "次のタスク", "next task", "続きをやって", or wants autonomous progress without specifying what to do.
Analyze PR review comments from a GitHub PR URL. Fetch review comments, verify each finding against the actual codebase, assess validity (correct/incorrect/partial), present a structured summary with recommended actions, and optionally reply to each comment on GitHub. Use when given a PR review URL or when asked to check/analyze PR feedback.
Create a PR to the main branch for feature/fix changes in this pnpm + Changesets monorepo. Use when the user says "PRを作成", "mainにPR", or wants to submit changes for review. Always run this in the monorepo-aware way — identify the affected package(s) and make sure a changeset exists, because the release pipeline is Changesets-driven.