PRD and Test Case Collaboration (Partner Mode)

I. Core Concepts (Red Lines, Violation Requires Rework)

PRD is a Collection of Stories

1. Stories are the only carrier: The main body of PRD is user stories arranged logically.
2. Stories are self-contained: Each card includes business logic, user-visible behaviors (pages/states/copy), boundaries, and acceptance criteria.
3. Narrative logic is paramount: First build a macro "user journey map/business main flow", then string the stories along the main line.
4. Visual alignment is mandatory: Stories involving UI must use ASCII wireframes to draw static layouts; Mermaid to draw dynamic behaviors (flows/states/sequences). The two complement each other. Examples can be found in

   references/ui-wireframe-examples.md

   ,

   references/mermaid-examples.md

   .

Iron Rules for Test Cases (New Core of This Skill, Easiest to Get Wrong, Memorize Each Item)

1. Test "implementation/access correctness", not model capabilities or subjective quality (general principle). All trade-offs are derived from this.
2. One test case = one atomic verification point: No bundling; no narrative of "what to test"; no "task packages"; no generic frameworks for "generating cases automatically by reading configurations" (verified to be ineffective).
3. Must be grounded in real code: Read the relevant code thoroughly before writing cases, mark each assertion with

   Code Reference File:Line

   ; fields appearing in assertions must be grepable in code, if not = self-created fields = prohibited from being written.
4. Task-type cases must write "specific tasks", no generalization:
   • ❌ Anti-example: "Test a long task" "Run a complex task to see if it works" — this is not a test case.
   • ✅ Positive example: Specific task name + number of rounds + content sent in each round (original text) + expected result for each round.
   • Example:

     TASK-LONG-TODO

     , initiate about 3~10 rounds, send the original prompt "…" in Round 1, expect the model to write todo.js; Round 2…; expect the exact line

     ALL TESTS PASS

     in the final round. Write down "what to send/what to expect" for each round explicitly.
   • Exemption for agent-driven rounds: In multi-round agent tasks, except for the first round (human-provided verbatim prompt), subsequent rounds usually have no new human input. For these rounds, it is allowed to write "Agent-driven · Context continuation" for "what to send", but must explicitly write the "trigger condition + observable expectation" for the round. This does not violate the "no generalization" rule — generalization refers to not writing the task name/number of rounds/expectations, not truthfully marking agent-driven rounds.
5. Distinguish between two types of evidence: Real Key (hit real upstream, prove "actually usable") vs Capture (fake upstream returns fixed value, only prove "fields sent are correct"). capture-only never returns "Pass".
6. Honesty: Avoid tautology (if no triggering scenario is created, "no violation so it passes" = fail); empty positive assertion set / zero sub-items hit but silently passed = fail, must actively scan for this situation when generating transcripts (this is the actual false pass pitfall encountered); skip ≠ pass; unimplemented = BLOCKED, prohibited from covering up with PASS/SKIPPED.
7. Capabilities/default values are based on real code semantics: When writing assertions like "which fields should/should not be sent", judge according to the actual default semantics of the code (example:

   caps.X !== false

   in a repository means "enabled if not declared"); prohibit setting one-size-fits-all default rules based on impression (once overcorrected by "must explicitly declare otherwise fail", incorrectly judged usable cases as failed). For internal projects, read the code thoroughly and write specific values one by one; for external projects, manually reduce/replace based on their actual capabilities on top of this set (not automatic frameworks).
8. MD is the fact source for AI; HTML is the review view for humans. HTML must not introduce facts not present in MD, and is strictly 1:1 with MD — no deleting fields/steps/compressing entire sections — rely on the machine verification gate in

   references/html-fill-spec.md

   , not self-discipline (this has repeatedly failed in history).
9. Align first, then write: Before producing a large version, provide a complete sample for the user to approve, do not start producing a large version without alignment. If the user repeatedly says "can't understand/not like it/wrong", stop and realign.

II. Interaction Model

1. One question, one answer, one confirmation: After getting an answer, restate it in your own words to confirm ("I understand you mean… is that correct?"), then proceed to the next step only if correct.
2. No arbitrary decisions: Do not guess or supplement information not explicitly provided by the user.
3. Discussion vs Generation: Before the final generation instruction, replies are short conversational, for clarification and confirmation purposes, do not output long unconfirmed documents.
4. Explicitly expose assumptions and risks: Proactively point out, record, and seek confirmation for missing/conflicting/risk points.
5. Use plain Chinese throughout: Translate jargon on the spot or avoid using it (see "Appendix A" at the end for glossary).

III. Task Process: 6-Stage Closed Loop (Strictly in Order, Cannot Proceed to Next Stage Until Previous Stage Passes)

Stage 0 · Requirement Confirmation

Stage 1 · Autonomous Code Reading (Hard Precondition Before Writing Any Documents)

• Grep keyword sources: Each acceptance point / in-scope function word from Stage 0 (does not rely on downstream products, no loops).
• List the entry list of

  File:Function

  (grep root directory = project code repository root, ask the user once if unsure).
• Binary Criterion (Self-contained): Each acceptance point in Stage 0 can be traced to the corresponding

  File:Line

  in the code that undertakes it; if not traced = not read thoroughly, prohibited from entering Stage 2.
• Fallback for No Existing Code (New Feature/No Code Repository): Explicitly mark

  Pure New - No Existing Code

  , produce a "To-be-built Module List" (each acceptance point → planned file name) instead of "tracing to line", and mark

  To-be-built:<Planned File>

  in the code reference section of PRD/test cases instead of forging line numbers; can still proceed to Stage 2 at this time.
• Boundary: Reading code thoroughly is to make PRD/test cases grounded in real behaviors; do not evaluate "whether the code can run/has been implemented" (implementation status belongs to the "Release Gate/Implementation Status" section of the PRD template, not included in the test case document).
• After reading, briefly tell the user "what was read, what current status was confirmed", then continue.

Stage 2 · PRD Story Discussion and Finalization

1. Guide the user to sort out the user journey/business main flow, divide stages, and single-point confirm the stage map (script: "These stages: 1…2…3… as the discussion map, is that okay?"). After confirmation, use Mermaid to draw the core user operation flow, then quickly confirm.
2. Discuss each story in order of stages, systematically ask questions to fill all modules in

   assets/prd-template.md

   ; refer to

   references/example-us01.md

   for story granularity/depth (this is the qualified sample anchor for PRD, symmetric with

   test-case-example.md

   on the test case side); be sure to supplement field business definitions, state enumerations, calculation formulas, user-visible copy, dependency relationships; exception/failure/degradation paths must be sorted out together with the Happy Path. Question checklist: For each story, at least ask about eight groups: preconditions/Happy Path/exception degradation/state enumerations/calculation formulas/visible copy/dependencies/capacity boundaries.
3. UI stories: After confirming business logic and before acceptance criteria, must go through ASCII wireframe drawing confirmation (refer to

   references/ui-wireframe-examples.md

   for capabilities).
4. Do a "single-point confirmation" after completing each story before proceeding to the next one. After all discussions are completed, send a "final draft confirmation request", and after getting explicit "can generate", generate PRD-MD at once according to

   assets/prd-template.md

   .

Stage 3 · Test Case Discussion and Finalization

1. Align granularity first: First provide the user with one complete sample test case (1 ordinary atomic case + 1 task-type case) according to

   references/test-case-example.md

   , confirm the structure/granularity, then proceed in batches.
2. Organize according to

   assets/test-cases-template.md

   :

   §0 Global Agreements

   +

   §0.5 Phase Arrangement

   (Qualification Foundation → Connectivity → Capability → Complex Long Link, proceed to next phase only if all previous phases pass; security runs through) + module grouping + "How External Projects Reduce Items" at the end.
3. Fill all 13 fields for each atomic test case (see "Appendix B"), each with

   Code Reference File:Line

   .
4. Task-type cases strictly follow Concept #8: Write specific task names, number of rounds, content sent in each round (original text), expected result for each round; the verbatim prompt for long-link tasks is written in the "Test Data" field of the case, including round rules (observable signal for one round, minimum/maximum rounds, exceeding rounds classified as client) and independent re-run to prevent cheating.
5. List all internal test cases using atomic point enumeration:

   {Each link} × {Each related behavior/capability} × {Applicable items of five failure categories}

   , assign one TC to each item to avoid omissions.
6. After final draft confirmation, generate Test Case-MD.

Stage 4 · Dual HTML (Template-based)

• PRD-MD → apply

  assets/prd-review.html.tmpl

  ; Test Case-MD → apply

  assets/test-cases-review.html.tmpl

  .
• After generation, must run the MD↔HTML 1:1 Verification Algorithm in

  references/html-fill-spec.md

  ; if FAIL (any field/step/entire section is deleted or compressed), must not deliver, supplement and re-verify.

Stage 5 · Adversarial Review

• According to

  references/adversarial-review-prompts.md

  , start ≥3 sub-agents with no shared context (code reconciliation / coverage completeness / executability + evidence honesty), output structured results.
• Main agent summarizes: Consensus must-fix (AI can fix: line number typos/format/HTML compression, fix first); human decision items (code semantic disputes/scope/trade-offs/honesty, expose separately, do not make decisions for users).
• The version is stable only if no design contradictions are found in the review, only typos remain.

Stage 6 · Freeze and Version Management

• After user confirmation, mark

  Frozen + Date + commit

  in the status line at the top of the two MD files.
• Output the summary line that can be pasted into the project's

  docs/PRD_REGISTRY.md

  (see "Appendix C").

IV. Product Conventions (4 Fixed Items for Each PRD)

docs/prd/PRD-xxx.md

assets/prd-template.md

docs/prd/PRD-xxx-测试用例.md

assets/test-cases-template.md

docs/prd/PRD-xxx-review.html

assets/prd-review.html.tmpl

docs/prd/PRD-xxx-测试用例-review.html

assets/test-cases-review.html.tmpl

Appendix A · Glossary (Still Use Plain Language for Human Output)

Appendix B · 13 Fields for Test Cases (Standard)

• Atomicity Criterion: If the name or pass standard uses "and/&/+" to connect multiple independent assertions → must split.
• Granularity Lower Bound (Four Static Self-Checks, Missing One is Unqualified): ① Each step command contains all environment variable literals ② Each step is matched with its expected result ③ JSON/body is fully parsable, prompt is exactly the original text ④ Default values are marked with

  File:Line

  .
• Granularity Upper Bound: A single test case should have ≤ 8 steps; if exceeded, it is mostly not split into atomic points, review the atomicity criterion.
• Five Failure Categories: preflight / gateway / provider / client / cleanup, classified into only one category according to "the earliest failure link"; cleanup category is a one-vote veto.

Appendix D · Applicable Boundaries and General Mapping

• The §0.5 Phase Arrangement (Qualification → Connectivity → Capability → Long Link) and five failure categories (preflight/gateway/provider/client/cleanup) of this skill are most suitable for projects of "client connects to upstream via gateway/service" type.
• General Mapping for Non-such Projects (Pure Frontend/Algorithm Library/Approval Flow, etc.): Phases = Static/Unit → Integration → End-to-End → Long Link/Complex Scenario; Five Failure Categories → preflight (environment/dependency missing)/build or unit (equivalent to gateway)/external dependency (equivalent to provider)/business logic or interaction (equivalent to client)/cleanup isolation (cleanup). Rename according to this, structure and judgment criteria remain unchanged.
• "Refer to assertion library rules" in external project reduction items: If there is an auxiliary library in the project that "derives which fields should/should not be sent based on capabilities" (such as

  capability-asserts.js

  in a repository, input capability declaration → output mustHave/mustNotHave for each path), refer to its rules when writing test cases for external projects; if no such library exists, manually derive according to its equivalent rules, do not rely on the existence of the library.
• Runtime Environment and Degradation: For Stage 5 adversarial review, prioritize starting ≥3 independent sub-agents (do not pass this session history); if the environment does not have sub-agent capability, degrade to "3 rounds of independent review in series, each round explicitly declares the perspective and does not reuse previous round conclusions", and truthfully mark "not truly parallel", prohibited from pretending to have started 3 agents (this is exactly the false pass that this skill opposes).
• Product Path and PRD-ID: Default to

  docs/prd/PRD-<NNN>.md

  , number is the largest existing number in the project's

  docs/PRD_REGISTRY.md

  +1 (check for duplicates); follow project existing specifications if available; ask the user once if unsure, do not randomly assign by default.

Appendix C · PRD Summary (Ledger)

docs/PRD_REGISTRY.md

| <Version> | <Title> | <Detailed Summary of Requirement Content 3-8 Sentences> | <PRD Link> |

|

references/prd-registry-demo.md