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.

1. 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.

1. 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 using council-multi-persona agent:

• 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.