decompose

decompose

You take a strategy-level JIRA issue — an RFE, Outcome, OCPSTRAT issue, or similar — gather deep context from it and all its linked issues, ask targeted interview questions to fill gaps, then create well-defined Feature or Initiative issues in the appropriate JIRA project.

Read these reference files now before proceeding:

• references/feature-definition.md — Feature template, project routing, custom field IDs, and acli creation pattern
• references/artifact-hierarchy.md — when to create a Feature vs. Initiative vs. Outcome, lifecycle statuses, and project routing
• references/artifact-templates.md — Initiative and Outcome body templates and acli JSON payloads
• references/wiki-markup.md — Jira wiki markup reference (for understanding existing issue descriptions; create new issues using ADF)

---

Phase 1: Gather Context

Step 1: Fetch the source issue.

Run `acli jira workitem view <KEY> --json` (or appropriate acli command) and parse the JSON output directly.

Step 2: Fetch linked issues.

Parse all linked issue keys from the output above. Fetch each one, prioritizing:

1. Parent issues (blocks, is blocked by, parent link)
2. RFE-type issues (Feature Request, RFE, Requirement)
3. Related issues

Cap at 10 linked issues. For each:

Run `acli jira workitem view <KEY> --json` (or appropriate acli command) and parse the JSON output directly.

Step 3: Synthesize context.

First, determine the artifact type for each piece of work using references/artifact-hierarchy.md:

• Is this customer-facing (new capability customers will use directly)? → Feature
• Is this architectural, infrastructure, or internal tooling (enables Red Hat associates)? → Initiative
• Does it represent a measurable business outcome spanning multiple releases? → Outcome (rarely; confirm with PM)

For each distinct artifact, assess the 9 required elements (from references/feature-definition.md for Features; references/artifact-templates.md for Initiatives/Outcomes):

• Overview / Goal: [known / partial / unknown]
• Goals / expected outcomes: [known / partial / unknown]
• Requirements / Success Criteria: [known / partial / unknown]
• Out of Scope: [known / partial / unknown]
• Target Release: [known / partial / unknown]
• Background / Strategic Fit: [known / partial / unknown]
• Customer or Stakeholder Considerations: [known / partial / unknown]
• Documentation Considerations: [known / partial / unknown]
• Interoperability Considerations: [known / partial / unknown]

Also note:

• How many distinct artifacts should be created? (separate RFEs → separate artifacts)
• What type is each artifact? (Feature / Initiative / Outcome)
• Which JIRA project(s) should own each? (see references/artifact-hierarchy.md project routing)

---

Phase 1.5: Duplicate & Existing Work Detection

Before drafting anything, search for existing Features and Initiatives that may already cover the work. Creating a duplicate wastes planning effort and fragments tracking.

Step 1: Search the target project for related Features/Initiatives.

Run `acli jira workitem view <KEY> --json` (or appropriate acli command) and parse the JSON output directly.

Step 2: Evaluate results.

Finding	Action
Exact or near-exact match (same capability)	Stop — link the RFE to the existing Feature; do not create a new one
Partial overlap (some RFEs are covered)	Note which RFEs the existing Feature covers; only create new artifacts for the uncovered gap
Adjacent work (related but distinct)	Note the relationship; plan to link the new artifact after creation
No matches	Clear to proceed to Phase 2

Report your findings to the user before continuing.

---

Phase 2: Generate & Ask Interview Questions

Compare your synthesis against the required Feature elements. Identify the most important gaps — things that would make the Feature incomplete or unactionable without answers.

Generate questions that target those gaps. Pre-fill partial answers from context where possible. Do not ask about things that are already clearly answered by the gathered context.

Ask up to 4 questions using AskUserQuestion, then ask a 5th separately if needed (the tool accepts max 4 at once).

Good question framing:

• "The source issue mentions X but doesn't clarify Y — what should the acceptance criteria be for Z?"
• "Should this be one Feature or two? The RFE covers both A and B, which seem separable."
• "This looks like it could be a Feature (customer-facing) or an Initiative (internal architectural work) — which is intended?"
• "Which project should own this — ROSA or XCMSTRAT? (The issue involves cross-cutting concerns.)"
• "What is the target release for this work? The source issue doesn't specify."

Poor question framing (avoid):

• Asking about things already stated clearly in the gathered context
• Generic questions that don't reflect the specific issue content
• More than one question about the same topic

---

Phase 3: Draft Features

Using all gathered context plus the interview answers, draft each artifact.

Apply the correct template:

• Feature → use the template from references/feature-definition.md
• Initiative → use the template from references/artifact-templates.md
• Outcome → use the template from references/artifact-templates.md

Fill every section with real content — no placeholders. If a section is explicitly not applicable, say so briefly.

Key quality bar:

• Market Problem must answer: who is affected, what pain, why now, what if we don't solve it
• Success Criteria must include quantified targets (%, time, deal count) — not just "feature is complete"
• Planned Epics must list 3–8 concrete work streams by name
• Timeline must include milestones by quarter/release
• All body text must use Jira wiki markup (h2., *, ||) — never Markdown (see references/wiki-markup.md)

Present the draft(s) to the user:

## Draft: [Artifact Title]
**Type:** [Feature / Initiative / Outcome]
**Project:** [ROSA / XCMSTRAT / HCMPE / etc.]
**Summary:** [one-line title]

[Full body in Jira wiki markup]

Ask the user to confirm or request revisions before proceeding to creation. Do not create until approved.

---

Phase 4: Create in JIRA

CRITICAL: Use acli jira workitem create --from-json for creation. Descriptions must be in ADF (Atlassian Document Format), not Jira wiki markup. Convert the template body content to ADF before writing the JSON payload. See references/feature-definition.md and references/artifact-templates.md for the required fields and JSON schema.

For each approved artifact:

Step 1: Create via acli

Write the issue payload to a temp JSON file (see references/feature-definition.md for the schema), then:

acli jira workitem create --from-json /tmp/artifact-payload.json --json

Note the new issue key from the JSON output.

Step 2: Link to source issue

acli jira workitem link create --out <NEW-KEY> --in <SOURCE-KEY> --type "Implements" --yes

Step 3: Link to parent Outcome (if known)

acli jira workitem edit --key <NEW-KEY> --from-json /tmp/parent-link.json --yes

Where parent-link.json sets additionalAttributes.customfield_12313140 to the Outcome key.

Step 4: Report results

## Created Artifacts

| Key | Type | Summary | Project | Link |
|-----|------|---------|---------|------|
| ROSA-456 | Feature | ... | ROSA | $JIRA_URL/jira/browse/ROSA-456 |
| ROSA-457 | Initiative | ... | ROSA | $JIRA_URL/jira/browse/ROSA-457 |

Links created:
- ROSA-456 Implements OCPSTRAT-2666
- ROSA-457 Implements OCPSTRAT-2666

---

Error Handling

• JIRA_API_TOKEN or JIRA_USER not set: Tell the user: "Set export JIRA_API_TOKEN=<your-token> and export JIRA_USER=<your-email> before running, or run /rfe:init."
• Project routing unclear: Ask the user which project to use rather than guessing.
• acli error / field errors: Show the error and ask the user whether to retry with modified fields or proceed manually.
• Issue not found: Report the key that failed and continue with the others.