Estimate

---
name: estimate
description: Derive user stories and a day-based, uncertainty-aware effort estimate from a Requivo session's model, in this Claude session, and save both as tracked artifacts against one revision. Use when the user wants an effort estimate for the current scope.
allowed-tools: Bash(requivo doctor:*), Bash(requivo model show:*), Bash(requivo status:*), Bash(requivo schema:*), Bash(requivo artifact save:*), Read
---

# /requivo:estimate

Produce a **day-based effort estimate**, one entry per user story — stories first, because the
estimate is reasoned against them, and #519 (`decision: the-estimate-graduates`) saves both together
against one revision: the estimate's provenance is incomplete without the stories it rests on. **You**
do the estimation; Requivo tracks both documents. This mirrors
`src/requivo/assets/prompts/stories.md` + the `Stories` contract, and `assets/prompts/estimate.md` +
`EstimateDraft`, at commit `969cfd9` — the same two calls `requivo estimate` makes, restated here
because the plugin cannot import those files 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 estimate to find.

## 1. Load the model
```
requivo model show <slug>
requivo status <slug> --json
```
Note the `revision` — call it `N`. Both documents you write below are tied to this one revision, per
invariant 12: one snapshot, two files.

## 2. Reason → stories, then the estimate
**First, the stories.** Follow `/requivo:stories`'s own reasoning rules (3–8 stories, one shippable
slice each, traceable to the model's slots by their labels, honouring confidence and impact) —
this skill does not repeat them; the referenced skill is the source.

**Next, name the soft slots** — this is what the CLI's own `estimate` generator computes in Python
(`core/analysis.py:soft_slots`) and hands the model as ground truth, so name them the same way rather
than reasoning about uncertainty from scratch: a slot is **soft** when its `impact` is `medium` or
`high` **and** either its `completeness` is below 70 or its `confidence` is not `explicit`. Read these
off the model you loaded in step 1.

**Then, the estimate**, from those stories and the soft slots you just named:
- Estimate each story as a **day range** (`days_low`, `days_high`) plus a complexity label `S`/`M`/`L`:
  `S` ≈ up to ~1 day, `M` ≈ 1–3 days, `L` ≈ 3+ days. Use the range to express real spread, not
  padding — tight for a confident story, wide for a shaky one.
- **Widen the range** for any story resting on a soft slot: unresolved scope is real cost risk. A
  story resting only on explicit, complete slots gets a tight range.
- For each item, name the topics that most drive its effort (usually a subset of the story's own
  traces), in plain language — never the raw slot id.
- One terse note per item — what makes it S vs L, or which unknown widens it.
- 2–5 batch-level risks (dependencies, soft slots that could blow scope, regulatory, shared modules).
- Estimate **only** the stories you just wrote. Do not invent stories or scope. A story resting on a
  proposal (`proposed:` evidence) is estimated as proposed, its note tagged from REASONING.md's
  *Source tags*.
- `days_low` never exceeds `days_high` for an item — the low end is optimistic, not a floor error.
- **Total and confidence are computed, not judged** — the same formula the CLI applies in Python after
  its own call, so state it here rather than leaving it to a feel: `Total` sums `days_low` and
  `days_high` across every item. `Confidence` counts the soft slots (call the count `n`): `n ≤ 1` is
  `high`, `n ≤ 3` is `medium`, otherwise `low`.

**Voice.** No slot ids, percentages or confidence labels in the prose.

**Language — the one open edge.** Everything else this plugin saves anchors English regardless of the
request's language (`docs/requirements-model.md`, *The language of the outputs*). The estimate is the
one artifact this policy does not fully reach: `estimate.md`'s own prompt carries no language
sentence, so each item's `note` and the batch `risks` may legitimately come back in whichever language
you are reasoning in. This is a documented, deliberate gap (CLAUDE.md names `estimate` as one of two
open edges), not an inconsistency to silently fix — story titles and table structure stay stable
regardless, since they are copied from the English stories above.

Write the estimate as Markdown:
```
# Estimate

> Uncertainty-aware estimate — generated by Requivo

**Total:** <sum of days_low>–<sum of days_high> days across <n> stories · **Confidence:** <high|medium|low, from the formula above>

## Per story

| Story | Complexity | Days | Drives |
|---|---|---|---|
| S1 — <title> | M | 2–3 | <label>, <label> |

## Notes

- **<title>** — <note>

## Spread driven by unresolved topics

- <label>

## Risks and unknowns

- <risk>
```

## 3. Save both, stories first, against the same revision
```
requivo artifact save <slug> --type stories --file - --revision N --json
requivo artifact save <slug> --type estimate --file - --revision N --json
```
Both calls use the `N` you read in step 1 — not a revision either save might have moved to. Read
`stale` back from each: if either is `true`, the model moved while you were writing — say so plainly
and offer to redo both, since the estimate's basis (the stories) would need to move with it.

## 4. Point at the next step, once
An estimate over stale stories is a stale estimate: if the model changes later, `/requivo:status
<slug>` shows which of the two artifacts needs regenerating. Otherwise, `/requivo:criteria <slug>`
turns the same model into a recette checklist a client can sign off on.