Client Ready Requirements

Client-Ready Requirements

Transforms an internal requirements document (output of the requirements pipeline) into a client-safe version. Removes internal process scaffolding without touching any functional content. The requirement statements themselves are never changed.

Inputs Required

If Stage 1 file cannot be found: Ask the user to point to it. If unavailable, proceed and use raw filenames in the Sources section rather than display names.

Step 1: Read Both Files

Read the requirements document and the Stage 1 intake file in full.

From Stage 1, build a source registry — every SRC code mapped to its display name, date, and type:

Type classification:

• Meeting Record — team meeting summaries, product working sessions, TL syncs
• Discovery Session — discovery readouts, deep dive sessions, client calls
• Client Document — client-provided requirement docs, written client communications
• Design Reference — Figma designs, FigJam boards, design descriptions
• Existing Draft — prior requirement drafts used as baseline input

Only register SRC codes that actually appear in the requirements document. Discard the rest.

Step 2: Collect All SRC Codes Referenced

Before transforming, scan the document and record every unique SRC code cited anywhere. This is your working list for the Sources section in Step 5.

Step 3: Transform the Document

Work section by section and apply every rule below. Never change requirement content — only strip or reframe metadata.

Transformation Rules

Step 4: Clean Open Questions Table

For each row in the Open Questions table:

• Remove internal codes from the question text (e.g. remove (H2, C9) but keep the plain English question)
• Keep columns: #, Question, Priority, Stakeholder, Target Date
• Stakeholder names like "Pat MacArthur (WFM)" or "Lauren / UX" are fine — these are real people clients recognize

Step 5: Build Sources Section

At the end of the document, after all other sections, add:

---

## Sources & Reference Materials

The following inputs were used to develop this requirements document.

### Meeting Records
- [Display Name] (Meeting Record, [Day Month Year])

### Discovery Sessions
- [Display Name] (Discovery Session, [Day Month Year])

### Client Documents
- [Display Name] (Client Document, [Day Month Year if known])

### Design References
- [Display Name] (Design Reference, [Day Month Year if known])

Section order: Meeting Records → Discovery Sessions → Client Documents → Design References → Related Feature Documents

Omit any section that has no entries.

Design references (Figma links) belong in Related Documents (§11), not in Sources. They are active references for implementers, not just research inputs. Do not list Figma links in the Sources section.

Formatting rules per entry:

• Full info available → [Display Name] (Type, Day Month Year) e.g., (Meeting Record, January 7, 2026)
• Date not available → [Display Name] (Type)
• Type not determinable → [Display Name] (Day Month Year)
• Use the exact date from the Stage 1 Date column — do not round to month/year if a full date is present
• Never use raw filenames if a display name is available from Stage 1
• Never include internal stage artifact files (Stage 1–8 pipeline outputs) here

Step 6: Quality Check

Before saving, verify each section against all four quality dimensions:

• Accuracy: Content matches source. No additions, no misattributions, no distortions.
• Clarity: A reader unfamiliar with the internal doc understands without ambiguity.
• Completeness: Full scope of the source material for that section is represented. Nothing significant omitted.
• Format: Section adheres to the transformation rules and structural conventions.

Then verify cleanup:

• Zero remaining SRC-N codes anywhere in the document
• Zero remaining (Source: Implicit) markers
• Zero remaining internal stage file references in body text
• Zero struck-through text
• Zero Engineering Notes (> **Engineering Note:**) in FR sections
• Zero stakeholder direction attribution blocks (> **Direction (Name):**) in FR sections
• Zero inline annotation tags ([Display layout, ...], [Design Decision]) in business rules
• Audience: field in header updated to client stakeholder types
• Sources section present at end of document
• Change history rows contain only: version, date, author, plain summary
• Related Documents retains only external links and sister features

Fix any failures before saving.

Step 7: Determine Output Folder

The pipeline defines that client-ready documents live in a client-ready/ folder parallel to Internal/. This skill is responsible for checking and creating that folder.

1. Let input_dir = the directory containing the input document.
2. If basename(input_dir) is Internal:
   • Set output_dir = input_dir/../client-ready/ (sibling of Internal).
3. Otherwise:
   • Set output_dir = input_dir/client-ready/.
4. If output_dir does not exist, create it (mkdir -p).

Step 8: Save and Report

Save the transformed document as:

[output_dir]/Client-Requirements-[Feature].md

Report the transformation summary:

✅ Client-ready document saved: Client-Requirements-[Feature].md

Transformations applied:
- Removed N source citations (SRC codes)
- Removed N "Implicit" source markers
- Removed N inline assumption/constraint codes
- Reframed N risk/blocker items
- Cleaned change history to N entries
- Sources section: N documents across N categories

Critical Rules

1. Never change requirement content. Strip citations and codes only. Requirement statements must be word-for-word identical to the source.
2. Never remove [TBD] items. These are still open — clients need to see them.
3. Never fabricate display names. If a SRC code has no Stage 1 entry, use the filename as-is.
4. Keep document structure. Same section numbers and headings as the input. Do not reorganize.
5. One pass. Apply all transformations before saving. Do not create intermediate versions.
6. No em dashes. Do not use "—" anywhere in the output. Replace with a comma, colon, or rewrite the sentence. Exception: if the source document contains an em dash inside a quoted string (e.g., notification text like "Your schedule was updated — check now"), preserve it exactly as written since that is requirement content.