Distill Requirements

Overview

Turn noisy, unstructured input into crisp, decision-ready requirements.

Meeting notes, STT transcripts, voice memos, and casual user narratives contain requirements buried in filler, repetition, digressions, and half-formed thoughts. This skill extracts those requirements, sharpens them until they are concrete and unambiguous, then sorts them into three categories:

• Fixed — the requirement is specific enough to act on. Write it into docs.
• Pending — the requirement needs confirmation from a stakeholder who is not present. Output structured data ready for waat-create-issue.
• Excluded — the requirement was explicitly decided against or scoped out. Write it into docs with status: excluded, so the decision is on record and not rediscovered later as a "missing requirement."

Concreteness over coverage: A requirement that cannot be acted on is not a requirement — it is a question. Refuse to write vague items into docs; instead, surface them as pending items with the specific question that needs answering.

Who and What are mandatory: Every requirement must identify who wants it and what they want. When, Where, and Why are valuable but optional — include them when the source material provides them.

REQ-ID assignment: IDs are integers starting from 1, auto-incrementing. When writing to existing docs, scan all existing requirement files for the highest REQ-ID in use and continue from that number +1. Never reuse or skip IDs.

Challenge ambiguity on sight: When a requirement is abstract or could mean multiple things, the agent must not silently pick one interpretation. The agent must ask the user to clarify, or flag it as pending with the ambiguity explicitly stated.