paqad-ai/runtime/base/skills/requirement-enrichment/SKILL.md

Spec-driven development framework — AI agents that think before they type

---
name: requirement-enrichment
description: "Phrases the pipeline's clarification questions as plain-language two-layer question objects. Use when the label step rated the request vague or okay, unlocked a question budget, and the touched area is grounded."
metadata:
  model_tier: fast
  cacheable: 'false'
  output_format: json
  paqad-meta: skill.meta.yaml
---

## What It Does

Turns the open decisions an incomplete request leaves behind into the pipeline's S2 clarification batch: a set of FR-4 two-layer question objects, each phrased in the project's own words so a non-technical owner can answer it. This is the S2 question-phrasing step of the spec pipeline, it phrases, it does not judge clarity and does not re-run the plain-language check.

## Use This When

When the spec pipeline's `label` step rated the request `vague` or `okay` and unlocked a question budget, and the touched area has been grounded (S0). It is for phrasing genuine ambiguities as answerable questions, not for restating a request that is already clear.

## Inputs

- Read the S0 grounding terms and references for the touched area: they are the first-priority vocabulary.
- Read the raw request, tracker notes, and any linked issue or spec: the user's own wording is the second-priority vocabulary.
- Read `references/enrichment-checklist.md` and walk `assets/operational-checklist.txt` to find the dimensions the request leaves undecided.

## Procedure

1. Walk `assets/operational-checklist.txt` (permissions, auditability, rollback, data-retention, i18n, a11y, observability, docs, feature-flags) and `references/enrichment-checklist.md`; for every dimension the request touches but leaves undecided, hold a candidate question.
2. Keep only genuine ambiguities, within the question budget the `label` step unlocked. Drop anything the grounding or the prompt already answers.
3. Phrase each question as a two-layer object. `business_text` and every `options[]` entry draw vocabulary in priority order: (1) the S0 grounding terms, (2) the user's own prompt, (3) plain English. Given a documented term ("archived invoices"), use it, never a from-the-model synonym ("soft-deleted records").
4. Phrase `options[]` as OUTCOMES, never mechanisms: "keep trying quietly for an hour, then notify someone", never "exponential backoff". Give at least two options.
5. Where current behaviour is documented, cite it in the question ("Today, exports include hidden columns: keep that, or leave them out?").
6. Write one plain sentence of `why_it_matters`. Set `grounded_in` to the doc/glossary ref the wording came from, or `null` when it cannot be tied to project evidence. Put any internal mechanism note in `technical_note` (never shown to the user).
7. Emit the batch per `assets/output.template.md`; validate the shape with `scripts/lint-output.sh` (exit 0). Hand the file to `paqad-ai spec pipeline record questions <file>`, which runs the ledger auto-answer pre-step and persists the surviving batch.
8. These questions are not asked on their own. They join the change's one question round at the spec questions step, together with every pending packet `paqad-ai spec pipeline round` lists for this change (expert picks, the deferred module attribution, the fix proof method, the visual-evidence readiness pause). The owner is asked once, up to 4 questions per call, back to back.

## Output Contract

- A JSON object matching `assets/output.template.md`: `{ "questions": [ ... ] }`, where each question has `business_text` (plain string), `why_it_matters` (one sentence), `options[]` (>=2 outcome strings), `grounded_in` (a ref string or `null`), and an optional internal `technical_note`.
- `questions[]` is the only hard-required field, so the raw batch validates against the pipeline's `questions` step even before auto-answer enrichment.
- Do NOT re-implement the plain-language check here: the pipeline's `checkPlainLanguage` guards the wording (FR-4.3). Phrase for it.
- Output must pass `scripts/lint-output.sh` (exit 0).

## Escalate / Stop Conditions

- Ask when business rules, permissions, or data-retention expectations are absent but clearly required: phrase the ask as one of these questions rather than guessing.
- Warn when the request conflicts with canonical docs or previously approved behavior.
- Do not guess regulatory, billing, or irreversible-data requirements; surface them as questions with `grounded_in` set to the governing doc.

## Resources

- `references/enrichment-checklist.md`
- `scripts/lint-output.sh`
- `assets/output.template.md`
- `assets/operational-checklist.txt`
- `runtime/capabilities/coding/checklists/edge-cases-coding.md`
- `agents/openai.yaml`