Write Epic Technical Discovery

Decision Intent (mandatory)

• What specific decision will this discovery enable?
• What uncertainty are we reducing?
• Push back on open-ended exploration without a clear decision at the end
• A valid discovery always ends with: "after this, we will decide X"

Hypotheses & Exploration Areas

• What are the main technical directions or approaches to evaluate?
• What assumptions are we making?
• Offer alternative hypotheses if the user is too anchored on one option

Output Artifacts (mandatory)

• What concrete outputs will be produced? (e.g. ADR, technical proposal, benchmark results, proof of concept, architecture diagram)
• How will we know this is "done"?
• Force clarity — avoid vague outputs like "a proposal" or "some analysis"

Success Criteria

• What makes this discovery valuable?
• What would failure or inconclusive results look like?
• What is the time-box?

Scope & Non-Scope

• What is explicitly included in the investigation?
• What is explicitly excluded?

Risks & Unknowns

• What could invalidate this discovery?
• What are the biggest technical uncertainties going in?

Dependencies & Alignment (mandatory when there is cross-team impact)

• Which teams are involved or affected?
• Are there technical, decision, or capacity dependencies?
• Who owns each part?
• Who could unintentionally block this?

Facilitation behaviors

• Ask a few high-quality questions at a time
• Challenge vague, shallow, or ambiguous thinking
• Push for clarity of decision intent — a discovery without a decision is just research
• Detect when the user is jumping to solutions too early and redirect
• Surface implicit assumptions and make them explicit
• Introduce alternative technical angles when relevant
• Prefer depth over speed
• If key areas are underdeveloped, do not proceed — ask more questions

Step 2: Draft the epic

Only proceed when the thinking is solid across the relevant areas above. If anything is still vague, go back to questions instead of drafting.

Title

A concise, outcome-oriented title. Guidelines:

• Max ~10 words
• Make it clear this is a discovery/investigation, not an implementation
• Focus on the question being answered or the decision being enabled

Examples:

• "Discover multi-property inventory synchronization architecture"
• "Evaluate event sourcing for payment audit trail"
• "Investigate third-party loyalty platform integration feasibility"

Description format

## PROBLEM
[The technical uncertainty or risk being addressed, and why it matters now]

## DECISION INTENT
[The specific decision this discovery will enable — be explicit]

## SCOPE
[What is included in the investigation]

## OUT OF SCOPE
[What is explicitly excluded]

## HYPOTHESES / EXPLORATION AREAS
[Main technical directions, approaches, or assumptions to validate]

## OUTPUT ARTIFACTS
[Concrete deliverables: ADR, technical proposal, PoC, benchmark, architecture diagram, etc.]

## SUCCESS CRITERIA
[How we know this discovery delivered value — include time-box if relevant]

## RISKS & UNKNOWNS
[What could invalidate or block this investigation]

## DEPENDENCIES & ALIGNMENT
[Teams, decisions, or capacity dependencies — omit if none]

Step 3: Confirm with the user

Show the full draft (title + description) and ask:

1. Create as is
2. Edit
3. Cancel

Do not finalize until explicit confirmation is received.

Step 4: Save the epic

After the user confirms and before offering to create in Jira:

1. Save the epic to initiatives/[initiative-name]/output/epic-discovery-[slug].md.
2. If the initiative context is not clear, ask: "Which initiative does this epic belong to?" and list existing folders under initiatives/.
3. If the initiative folder does not exist, create the full structure (data/, tmp/, scripts/, output/).
4. Confirm the file path after saving.
5. Then ask: "Want me to create this epic in Jira?" — if yes, invoke the jira skill.

Quality checklist (run before showing the draft)

• The problem is a technical uncertainty — not a feature request
• Decision intent is explicit: "after this, we will decide X"
• Output artifacts are concrete and verifiable (not "a document" but "an ADR covering X")
• Time-box or success criteria are defined
• Scope and non-scope are clearly separated
• Dependencies are stated if cross-team impact exists
• Title signals investigation, not implementation

Style guidelines

• Be concise and sharp — no filler
• Reflect the user's specific technical context — no generic templates
• EM tone: practical, direct, focused on decisions and outcomes
• Do not hallucinate missing context