to-prd

name	to-prd
description	Synthesis only, no interview: solidify an already-resolved requirement discussion into task artifacts (prd.md + task.json + contract.md), self-review, commit, and get user sign-off. Use after batch-grill-me, grill-me, or another discussion has resolved all open questions and the user is ready to write the spec down.

To PRD

No interview, just synthesis. The upstream superharness:batch-grill-me, superharness:grill-me, or another requirement discussion has already resolved the open questions. This skill turns that shared understanding into task artifacts. Preserve settled decisions and keep new questioning limited to genuine blocking gaps.

If you find a genuine gap that blocks writing the spec (a decision the conversation never touched), surface it to the user as one focused question. A gap at this stage is an upstream miss, not an invitation to grill again.

The caller must provide an explicit profile: full or profile: lite. Never infer or default the profile. If the caller omitted it, return one focused profile question before creating any artifact.

File Structure

Everything lands in one task directory under the project root:

{project-root}/
├── .superharness/
│   └── tasks/
│       └── {MM}-{DD}-{name}/      ← one directory per task, e.g. 07-08-auth-system
│           ├── prd.md             ← the requirement: 背景/目标/需求描述/风险分析/影响范围
│           ├── task.json          ← task metadata: status/phase/sprint, read by go and parent-thread hooks
│           ├── contract.md        ← Done Definition: verifiable acceptance checklist
│           └── trace.jsonl        ← lifecycle telemetry: seeded by task CLI, transition and prompt events append later
└── src/

Full planning may later add plan.md; delivery may add verification and QA evidence. New workflows do not create implementation protocol files. to-prd owns these four initial artifacts and nothing else.

Write the Artifacts

Create the task directory, write three semantic files, then use the task CLI to generate the trace artifact:

1. Spec (prd.md): Write the validated design to .superharness/tasks/{MM}-{DD}-{name}/prd.md

   • {MM}-{DD} is the current date (zero-padded month and day)

   • {name} is a short kebab-case identifier for the topic (e.g., 04-03-auth-system)

   • Record decisions, not code: capture what was decided and why. Wiki-sourced facts keep their document title/ID attribution.

   • A prd records the requirement, not the technical solution — how to build it belongs to writing-plans. Use this exact structure:

     # {标题}
     
     ## 背景
     
     ## 目标
     ### 业务目标
     ### 技术目标
     
     ## 需求描述
     
     ## 风险分析
     
     ## 影响范围
     

2. Contract (contract.md): Create .superharness/tasks/{MM}-{DD}-{name}/contract.md from the confirmed spec before constructing task metadata. Persist both the confirmed public seams and objectively checkable acceptance slices:

   # Done Definition — {name}
   
   ## Test Seams
   - <confirmed public callable boundary>
   
   ## Acceptance Checklist
   - [ ] <verifiable acceptance slice derived from the spec>
   - [ ] ...
   - [ ] focused tests / typecheck / lint / test 全过
   - [ ] 两轴审查（Spec + Standards）单轮 PASS
   

   Every item must be objectively checkable and name how it is checked: a focused test, an integration/E2E gate, or a reviewer/manual check. Objectively checkable does not mean unit-tested — items may be covered by QA, E2E, or reviewer verification, and manual procedures for behavior land here so finishing actually checks them. Do not use vague statements such as "works correctly".

Spec Self-Review

After writing the spec document, look at it with fresh eyes:

1. Placeholder scan: Any "TBD", "TODO", incomplete sections, or vague requirements? Fix them.
2. Internal consistency: Do any sections contradict each other? Does the architecture match the feature descriptions?
3. Scope check: Is this focused enough for a single implementation plan, or does it need decomposition?
4. Ambiguity check: Could any requirement be interpreted two different ways? If so, pick one and make it explicit.

Fix any issues inline. No need to re-review — just fix and move on.

User Review Gate

This gate remains after step 5 has created and committed prd.md, contract.md, task.json, and trace.jsonl. Read .superharness/config.yaml and ask the user to choose:

1. Continue without adversarial review — preserve the existing user review behavior.
2. Run PRD adversarial review — invoke superharness:adversarial-review with the task-id and target prd when review.mode is on-demand.

When review.mode is off, omit the adversarial option and use the existing prompt:

"Spec written and committed to .superharness/tasks/{MM}-{DD}-{name}/prd.md. Task artifacts (task.json, contract.md) created. Please review the spec and let me know if you want to make any changes."

After adversarial review finishes, return to this same user review gate. Adversarial review does not count as the user's approval.

Wait for the user's response. If they request changes, make them and re-run the self-review. Only finish once the user approves.

After Approval

This skill ends here; the caller owns the next step. The go full flow continues with superharness:writing-plans. The go Lite flow continues implementation from the 1–3 task items already persisted here. When invoked standalone, report the created task directory name and the profile-independent continuation command /superharness:go --task {task-id}. Go reads the stored profile from task.json.

Red Flags

• Re-asking questions the conversation already answered
• Writing file paths or code snippets into prd.md as requirements — they go stale; record decisions instead
• Skipping the self-review or the user review gate
• Inventing requirements that were never discussed to make the spec look complete
• Inferring a missing profile or writing artifacts before the caller provides one