issue-feature-breakdown

name	issue-feature-breakdown
codex-short-description	Gather Jira/Confluence context + council pass into an actionable breakdown plan
description	Analyze a Jira ticket by gathering full context from Jira and Confluence, following linked tickets, then running a clarity-council to identify gaps and ambiguities. Produces an actionable breakdown plan. All actions are read-only. Use when user says "break down this feature", "analyze this ticket", "feature breakdown", or provides a Jira ticket key for analysis.
related-skills	["clarity-council","business-analyst"]
loop-eligible	false
compatibility	claude-code codex opencode

Feature Breakdown

Read-only analysis of a Jira feature ticket. Gathers context, consults the clarity-council, resolves ambiguities with the user, and produces an actionable breakdown.

All operations are read-only. Never create, update, or transition Jira tickets.

Input

A Jira ticket key (e.g. PROJ-123). Extract from the user's message using pattern [A-Z][A-Z0-9]+-\d+.

Workflow

Phase 1 — Gather Context

1. Fetch the root ticket via jira_get_issue — capture summary, description, acceptance criteria, status, priority, story points, fix version, and sprint.
2. Fetch comments via jira_get_comments.
3. Walk all linked tickets (issue links from the root ticket's issuelinks field):
   • For each link: fetch via jira_get_issue, note the link type (blocks / is blocked by / relates to / etc.).
   • If the root ticket belongs to an epic/feature: fetch sibling stories via jira_get_epic_issues.
4. Check for Confluence context:
   • Fetch remote links via jira_get_remote_links — read any linked Confluence pages via confluence_get_page.
   • Search Confluence via confluence_search with CQL: text ~ "TICKET-KEY" to find pages that reference this ticket.
5. Compile a Context Summary and present it to the user. Include:
   • Root ticket details
   • Linked ticket summaries (with link types)
   • Confluence page titles and key excerpts
   • Any acceptance criteria found

Gate: Ask the user if any additional tickets or documents should be included before proceeding.

Phase 2 — Council Analysis

Invoke /clarity-council in multi mode:

• user_problem: "Analyze this feature and identify what is being asked, what assumptions are being made, and what gaps or ambiguities exist."
• context: The full Context Summary from Phase 1.
• desired_outcome: "A clear understanding of the feature scope, identified gaps, risks, and open questions that need answers before implementation can begin."
• selected_personas: Researcher, Senior Architect, Product Owner, Tech Lead, QA Engineer, Devil's Advocate
• depth: standard

Persona focus:

• Researcher — owns evidence quality. Audits the Context Summary for missing source citations, unverified claims, and assumptions stated as facts. Surfaces the "what would we need to know to be confident?" questions that the other personas tend to skip past. Failure mode the researcher will catch: a council that confidently scopes a feature on top of an undocumented assumption.
• Senior architect — structural implications and integration seams.
• Product owner — scope, value, and acceptance criteria clarity.
• Tech lead — implementation risk and dependencies on other in-flight work.
• QA engineer — testability and edge-case enumeration.
• Devil's advocate — challenges the proposed scope; flags hidden assumptions.

Present the council's synthesis to the user: agreements, conflicts, risks/tradeoffs, and the questions each persona raised. Lead with the researcher's evidence-gap list — those questions usually need to be answered before any of the others can be productively closed.

Phase 3 — Clarify

Collect all unresolved questions from the council output and any gaps identified in Phase 1.

Ask the user one question at a time. For each question:

• State which persona raised it and why it matters.
• Offer a recommended answer if the gathered context suggests one.
• Wait for the user's response before asking the next question.

Continue until:

• All questions are resolved, OR
• The user says they have enough clarity to proceed.

Phase 4 — Breakdown Plan

Using the resolved context, produce a structured breakdown. See BREAKDOWN-FORMAT.md for the output template.

Each item in the breakdown should include:

• What: A concrete, implementable unit of work
• Why: How it connects to the feature goal
• Acceptance criteria: Testable conditions (derived from the ticket + council analysis)
• Dependencies: Which other items must complete first
• Risk/complexity: Flag from council analysis (if any)

Gate: Present the breakdown and ask:

1. Does this cover the full scope?
2. Are any items too large or too small?
3. Should any items be reordered or merged?

Iterate until the user approves.

Constraints

• Read-only: Never call jira_create_issue, jira_update_issue, jira_transition_issue, or any write operation on Jira or Confluence.
• Do not create files on disk unless the user explicitly asks to save the breakdown.
• If the Jira ticket key cannot be found, stop and ask the user to provide a valid key.

Quality Loop

Before returning the artifact, evaluate it and refine if it falls short.

1. Generate the artifact via the workflow above.
2. Self-evaluate against these criteria:
   • Breakdown items are vertical slices, not layers — each delivers observable value
   • Gaps and ambiguities from the council pass are listed explicitly, not silently resolved
   • Dependencies between items are stated
   • Every claim about the ticket is grounded in gathered Jira/Confluence context, not assumed
3. Loop — if two or more criteria fail, revise and re-check.
4. Exit when all criteria pass, or after two refinement passes (then note which criteria still fall short).

Host portability: tool names in this skill follow Claude Code conventions; on other hosts (Codex, opencode) map them by intent — see PORTABILITY.md.

Self-Evolve Loop

This skill learns across invocations — the full contract is SELF-EVOLVE.md. Start: read the learnings journal — ~/.ink-and-agency/learnings/issue-feature-breakdown.md and/or the workspace-local .ink-and-agency/learnings/issue-feature-breakdown.md — if present, and apply its guidance. End: self-evaluate the results; optionally ask the user for feedback (never block on it); append signal-bearing learnings to the journal (user-global when the sandbox allows writing there, workspace-local otherwise); route skill-improvement ideas per the contract's tiers — edit the canonical source when one is present, never the plugin cache.