Product Requirement Delivery

Turn a lightweight requirement card into one confirmed business baseline and three aligned handoff artifacts. Keep the product manager in the decision/review role; let agents perform discovery and drafting.

Required workflow

1. Audit the intake

Extract: requirement name, related pages, problem, urgency, target users, desired outcome, known defaults, and any reference document.

Read references/intake-card.md. Fill missing non-critical details with labeled recommendations. Ask only questions whose answers materially change business behavior; do not make the user write a full PRD.

2. Investigate the real product

Open every related page and inspect visible fields, filters, states, operations, navigation, terminology, and constraints. Use the user's signed-in Chrome session when their login state is relevant. Follow the applicable Chrome/browser skill before controlling a browser.

Capture current-page evidence and screenshots. Distinguish:

• Observed: directly verified on the live page.
• User stated: supplied in the requirement card.
• Recommended: proposed by the requirement Agent.
• Unverified: could not be inspected because data/state/access was unavailable.

Read and obey references/ui-evidence-rules.md. Never invent a generic interface and present it as the product. If a target state is unavailable, document the interaction requirement and mark placement unverified.

3. Draft the single source of truth

Create <requirement-name>-统一需求事实源-v0.1.md using references/fact-source-schema.md. Include stable requirement IDs (REQ-01...) and acceptance IDs (AC-01...). Separate observed facts from recommendations and technical unknowns.

Run:

python scripts/validate_fact_source.py <fact-source.md> --expected-status draft

4. Stop for product confirmation

Present only the decisions that require product judgment, with one recommended default for each. Do not generate final development or test packages before confirmation.

Typical decisions: user-facing names, default value, editable states, permission reuse, relationships to existing fields, historical-statistics behavior, and audit requirements.

5. Freeze the confirmed baseline

After explicit confirmation:

• change status to 已确认（可进入研发与测试）;
• set version to v1.0 or later;
• record confirmation date and decisions;
• remove tentative wording from confirmed rules;
• preserve unverified technical/page-placement facts as unverified.

Run the validator with --expected-status confirmed.

6. Generate the delivery set

Read references/deliverable-contract.md. Produce:

1. <requirement-name>-产品评审与交付基线.docx
2. <requirement-name>-研发Agent任务包.docx
3. <requirement-name>-测试Agent任务包.docx
4. confirmed single-source Markdown

Use the documents skill for DOCX creation and its render/inspection workflow. If the user supplied a reference DOCX, treat it as the design authority. Otherwise, assets/human-review-reference.docx may be used as the default human-review style reference; use a compact business-reference style for Agent packages.

For screenshots, annotate the actual product capture. scripts/annotate_screenshot.py can draw labels, boxes, and arrows from a JSON spec. Clearly label annotations as proposed changes. Redact or crop sensitive data when it is not necessary for review.

7. Enforce downstream boundaries

The development package must require repository reconnaissance before implementation. It may propose semantic names but must not state database fields, APIs, file paths, permissions, events, migrations, or architecture as existing facts unless verified in the repository.

The test package must derive every test from a REQ or AC; it must not invent business rules. Include data preparation, normal/negative/state/permission/migration/regression coverage, stop conditions, evidence format, and exit criteria.

8. Verify consistency and visual quality

Create a small audit manifest from references/audit-manifest.example.json, then run:

python scripts/audit_delivery.py --manifest <manifest.json> --fact <confirmed.md> --docx <human.docx> <dev.docx> <test.docx>

Render every final DOCX to PNG and inspect every page when the document toolchain supports it. Fix clipping, broken tables, unreadable text, misleading visuals, and awkward page breaks. If rendering is unavailable, perform structural/a11y checks and explicitly disclose the skipped visual gate.

Non-negotiable gates

• One confirmed fact source governs all artifacts.
• No final downstream packages before product confirmation.
• No fabricated product UI; use real screenshots or mark the state unverified.
• No inference of one business field from another without a confirmed rule.
• No unverified technical implementation presented as fact.
• Human, development, and test documents must use identical names, enums, defaults, editability, permissions, and historical behavior.
• Preserve the user's existing files and unrelated workspace changes.

Handoff

Lead with the outcome. Link the confirmed fact source and each final DOCX. State the confirmation version, notable assumptions, unverified items, and whether visual rendering passed. Do not expose internal work files unless requested.