Epic

---
name: epic
description: Turn a Requivo session's model into a delivery epic — a work breakdown a dev team can track and ship — in this Claude session, and save it as a tracked artifact. Use when the user wants an epic with trackable issues from the model.
allowed-tools: Bash(requivo doctor:*), Bash(requivo model show:*), Bash(requivo status:*), Bash(requivo artifact save:*), Read
---

# /requivo:epic

Turn the model into a **delivery epic** — one feature, broken into the implementable issues a dev team
would track and ship. This is the work breakdown, not user stories: issues are dev-facing units of
work. **You** do the breakdown; Requivo tracks the document. This mirrors
`src/requivo/assets/prompts/epic.md` and the `Epic` contract in `core/contracts.py`, at commit
`969cfd9` — the same rules the CLI's `requivo epic` gives its own reasoning call, restated here
because the plugin cannot import that file at runtime (`decision:
plugin-skills-mirror-a-pinned-cli-commit`). Read `${CLAUDE_PLUGIN_ROOT}/REASONING.md` unless you already hold it from an earlier
`/requivo:*` in this conversation — and read it again whenever you are unsure you still do.

## 0. Preflight
Run the shared **preflight** from REASONING.md before anything else: `requivo doctor --json`, checking
whether the command ran *at all* rather than what it reported. If it could not run, the `requivo` CLI
is not installed — follow REASONING.md's missing-CLI flow. Nothing has been saved at this
point, so there is no half-written epic to find.

## 1. Load the model
```
requivo model show <slug>
requivo status <slug> --json
```
Note the `revision` — call it `N`. It is the model this epic will rest on, and you will state it when
you save.

## 2. Reason → write the epic
- `title`: the epic name — the feature as a whole. `goal`: one or two sentences, the outcome in
  business terms. `business_value`: why it's worth building now.
- `in_scope` / `out_of_scope`: draw the delivery boundary; put low-impact or deferred work out of
  scope. `milestone`: one short label ("Pilot", "v1").
- **Issues** are the work breakdown — a mix of user-facing and technical/setup work as the model
  implies (data model, integration, permissions, migration, QA are all legitimate issues, not just
  user-facing ones). Each has an id (`#1`, `#2`, … in build order), a concrete imperative title, a
  1–3 sentence description a dev could pick up, 1–3 labels from `feature`/`backend`/`frontend`/
  `config`/`integration`/`migration`/`permissions`/`qa`/`spike`, and `depends_on` (ids of issues that
  must ship first, empty if none — every id must name an issue in this same epic, and nothing depends
  on itself).
- **Sequence and size by information value.** Front-load risky, high-impact work; a `spike` issue is
  right where the model is genuinely uncertain but the answer moves the build. Don't manufacture
  filler issues for well-understood, low-impact work.
- Honour `confidence` and `impact`: `explicit` → a firm issue; `inferred` → the description must flag
  the assumption to confirm, not present it as decided; `empty` + high impact → a `spike` issue that
  dependent work `depends_on`, never an asserted feature issue; `empty` + low impact → an
  `open_question` or leave it out.
- **Never assert a decision the model hasn't made.** Where two behaviours are both plausible, that is
  a `spike` or `open_question`, not a behaviour described as settled in an issue. A design the model
  holds as a proposal or a domain fact (`proposed:` or `domain:` evidence) is a firm issue, tagged from
  REASONING.md's *Source tags*; a new one of yours is an `open_question` with your recommendation,
  for `/requivo:prd` to write back.
- Fold in the model's reasoning layer: `decisions` build for the decided path (tradeoff in the
  description); an unresolved `challenges` entry becomes a `spike` issue dependent work depends on, or
  an `open_question` — never a side described as settled; `opportunities` go in `out_of_scope` or a
  clearly-labelled follow-up issue.

**Voice.** Write for a dev team and a client — no slot ids, completeness percentages, or confidence
labels in the prose. Say the business thing; the calibration above is invisible to the reader.

**Language.** The epic anchors English whatever language the request arrived in — it feeds a dev team
and a tracker, unlike the mirrored conversation (`docs/requirements-model.md`, *The language of the
outputs*).

Write it as Markdown:
```
# Epic: <title>

> Delivery epic — generated by Requivo

**Milestone:** <milestone>
**Goal:** <goal>
**Business value:** <business_value>

## In scope

- <item>

## Out of scope

- <item>

## Issues

### [ ] #1 — <title>

**Labels:** `feature`, `backend` · **Depends on:** #2

<description>

## Open questions

- <open question>
```

## 3. Save it as a tracked artifact
```
requivo artifact save <slug> --type epic --file - --revision N --json
```
`--revision N` is the revision you read in step 1. Read `stale` back from the save output: if it is
`true`, the model moved while you were writing — say so plainly and offer to redo it.

**Tracker exports stay CLI-only, and re-reason rather than re-use.** `requivo epic <slug>
--export-json`/`--github`/`--gitlab` writes a tool-neutral export or an issue-creation plan for GitHub
or GitLab — but that verb always reasons the epic again through the CLI's own (optional, API-keyed)
mode; there is no command that exports the epic you just saved here without a fresh generation. Say so
if the user asks for a tracker export: it needs a terminal, the `requivo[anthropic]` extra, and an
Anthropic API key — not needed for this skill — and the epic it exports may differ slightly from the
one saved here.

## 4. Point at the next step, once
Once the epic is agreed, `/requivo:release <slug>` writes the client-facing announcement for the same
scope. If the breakdown surfaced something the model should record, `/requivo:run <slug>` is where
that goes back in.