ع
Learn Tracks Reference Guides Saved
playbook

Take requirements from draft to full sign-off

Draft the requirements doc from stakeholder input, circulate it, track who has and hasn't responded, resolve conflicting feedback, and land a version every named stakeholder has actually signed off on before build starts.

advanced ~half a day, spread over the review window
when to reach for this

Requirements rot the moment they leave the draft stage: a doc goes out for review, three people reply and two go quiet, feedback arrives contradicting itself, and build starts anyway because the deadline doesn't wait for the last signature. This system runs the full pipeline — draft, circulate, chase, reconcile, sign off — as one governed workflow instead of five disconnected steps, so nothing proceeds to build without a named owner attached to every requirement. It's the traceability guardrail as an operating system: the stakeholder map tells you who to circulate to, the requirements doc is the artifact under governance, and any gap-analysis or options-analysis work that fed the draft carries through to the final, signed version.

gather this first
  • Your stakeholder-map output, or at minimum a list of who needs to review and who has final sign-off authority for each requirement area.
  • A first-pass requirements-doc (from the keystone playbook), or the raw stakeholder interview notes and meeting transcripts it would be built from.
  • Any gap-analysis or options-analysis artifacts that already informed scope, so the doc doesn't contradict decisions already made.
  • The build deadline and who's blocked waiting on sign-off — this sets how aggressively you chase.
the workflow

  1. Draft or import the requirements doc

    Open the folder with your stakeholder notes (and stakeholder-map, gap-analysis, or options-analysis, if they exist) in Claude Desktop and ask in the chat — no terminal needed. If a requirements-doc draft already exists, import it instead of redrafting from scratch.

    you ask
    Using stakeholder-notes.md and stakeholder-map.md, draft a requirements-doc.md: one numbered requirement per row, each with a plain-language description, the stakeholder it traces to by name, priority (must/should/could), and an open 'owner sign-off' field left blank. Flag any requirement you inferred rather than heard directly.

    what you get back A numbered requirements doc where every row names the stakeholder it came from and has a blank sign-off field — the traceability guardrail built into the document's shape from row one.

    Inferred requirements get flagged, not silently smoothed over. An unflagged guess is exactly what breaks traceability later.

  2. Build the circulation and tracking list

    Turn the stakeholder map into a live tracking sheet: who reviews what, and the current status of each. This is what makes 'who hasn't responded' a lookup instead of a memory exercise.

    you ask
    From stakeholder-map.md and requirements-doc.md, build a circulation-tracker.md: one row per stakeholder, which requirement numbers are theirs to review, a status column (not sent / sent / reviewed / signed off / conflicting), and the date last contacted. Tell me who has final sign-off authority versus who's consulted only.

    what you get back A tracker with every stakeholder's scope, status, and authority level laid out — the single source of truth for who owes you a response.

  3. Circulate and draft the chase messages

    Send the doc out, and let Claude draft the follow-ups so chasing stays polite and specific instead of a vague nag.

    you ask
    Draft a short circulation email for requirements-doc.md tailored to each stakeholder group in circulation-tracker.md — only the requirements relevant to them, with a clear deadline and what 'sign-off' means. Then draft a one-line follow-up message I can send to anyone still 'not sent' or 'sent' after 3 business days.

    what you get back A tailored circulation message per stakeholder group plus a ready-to-send chase line — so following up costs you a copy-paste, not a fresh draft each time.

  4. Log responses and update status as they arrive

    Each time a stakeholder replies — in a meeting, an email, a comment — feed it back in and keep the tracker current. This step repeats through the review window.

    you ask
    Here's Priya's feedback on requirements 4, 7, and 12: [paste feedback]. Update circulation-tracker.md to mark her status, and tell me whether her feedback is a sign-off, a requested change, or a conflict with anyone else's feedback already logged.

    what you get back An updated tracker row plus an explicit call on whether this is a clean sign-off, a change request, or a conflict — so contradictions surface immediately instead of at the end.

  5. Resolve conflicting feedback

    When two stakeholders want different things on the same requirement, don't average their answers — surface the conflict and force a resolution with a named decision-maker.

    you ask
    Requirements 7 and 12 have conflicting feedback: [paste both]. Lay out the conflict plainly — what each stakeholder wants and why it matters to them — and tell me who has final authority on this requirement per the stakeholder map. Draft the question I need to put to that person to resolve it.

    what you get back A plain-language conflict summary, the named decision-maker per the stakeholder map, and a ready-to-send question — conflicts get escalated to an owner, never silently split down the middle.

    Never let a requirement's wording drift toward 'whatever's easiest to agree on.' The named owner decides; that decision gets recorded against the requirement, not smoothed into vague language.

  6. Check completeness before closing the round

    Before calling the round done, verify every requirement actually has what the guardrail demands: a name and a status.

    you ask
    Audit requirements-doc.md and circulation-tracker.md together: list any requirement that doesn't yet have a named stakeholder, or any stakeholder with sign-off authority whose status isn't 'signed off.' Nothing should be missing from this list before we close the round.

    what you get back A gap list — requirements or stakeholders still unresolved — or, ideally, confirmation that every requirement traces to a name and every required signature is in.

  7. Lock the signed-off version

    Once every required signature is in, freeze the doc as the version of record and make the sign-off trail visible in the document itself, not just in your head.

    you ask
    Produce requirements-doc-signed-v1.md: the full requirements doc with a sign-off log appended — each requirement's stakeholder, sign-off date, and status. Mark it 'locked for build' at the top. Anything not signed off gets called out at the bottom as a known open item.

    what you get back A locked, version-of-record doc with a visible sign-off log per requirement and any open items called out explicitly — the artifact build can start from, with the paper trail built in.

make it your own
  • Fast-track for a small change: collapse steps 2–4 into a single round-robin review meeting when there are fewer than 5 stakeholders and the change is low-risk — still log sign-off in writing afterward, even if the discussion was verbal.
  • Feed from workshop-synthesis: if requirements came out of a workshop, start at step 1 with the workshop-synthesis output instead of raw notes — the synthesis already groups themes by participant, which speeds up the stakeholder-tracing.
  • High-stakes or regulated scope: add a formal approval-matrix column (RACI) to the tracker and require sign-off to be a dated, named reply in writing — no verbal-only sign-offs for anything that touches compliance or external commitments.
  • Recurring change requests post-signoff: once locked, route any new ask through a lightweight requirements-doc addendum with its own sign-off row, rather than editing the locked v1 — keeps the paper trail intact.
watch out for
  • Don't let build start on a doc with any unsigned 'must' requirement. A single unnamed owner is exactly the gap that turns into a rebuilt feature three weeks later — the whole point of this system is that it doesn't happen.
  • Don't resolve a conflict by picking the answer that's easiest to write down. Every conflict escalates to the person with named authority over that requirement — Claude drafts the escalation question, it doesn't make the call.
  • Don't treat 'no response' as implicit sign-off. Silence goes in the tracker as 'not responded,' stays off the signed list, and gets chased — it never quietly becomes a yes.
  • Claude tracks and drafts; it doesn't own the relationship. A human still has the actual conversations with stakeholders who are dragging their feet — use this system to know exactly who that is and what to ask them, not to replace asking.

you'll end up with A requirements doc that went from stakeholder input to a locked, version-of-record artifact where every requirement traces to a named stakeholder, every conflict was escalated and resolved rather than smoothed over, and every required signature is logged — build can start on solid ground.

Questions people ask

What happens if a stakeholder just never responds?
They stay logged as 'not responded' in the tracker and get chased with the follow-up message — silence never converts into an implicit sign-off. If they have final authority over a requirement, that requirement can't be marked locked until they either respond or a named delegate signs off in their place.
How do you resolve two stakeholders wanting contradictory things?
You don't split the difference. The conflict gets laid out plainly for both positions, then escalated to whoever has final authority over that requirement per the stakeholder map — Claude drafts the escalation question, but a named person makes the actual call, and that decision gets recorded against the requirement.
Can build start before every requirement is signed off?
Only if the unsigned items are explicitly called out as known open items in the locked doc, and ideally only for lower-priority ('should'/'could') requirements — not a 'must.' The completeness check in step 6 exists specifically to catch this before it becomes a silent gap.
How is this different from just running the requirements-doc playbook once?
The keystone `requirements-doc` playbook produces the artifact. This one runs the artifact through its full lifecycle — circulation, tracking, conflict resolution, and a locked sign-off — so it's not just written, it's governed. That's the orchestration layer on top of the single document.