What the requirements source provides is often a Word document—freely formatted, scattered information, many implicit assumptions. This Skill converts it into structured Markdown and places it at docs/prd/<feature-name>/prd.md, so that grill-with-prd, the various prototype skills, andacceptance-checklist can read it directly.
Only do conversion and structuring; do not invent requirements. Anything not written in the original text must be marked [UNKNOWN]。
Usage boundaries
- Applicable: you have a
.docxfile, or a large block of pasted PRD text. - Not applicable：
- Requirements are still verbal and boundaries have not been clarified → use
requirement-clarify - Requirements are already clear and you want to write the PRD directly → use
prd-writeorcontext-to-prd - Meeting minutes, chat records → that is not a PRD, use
context-to-prdis more appropriate
- Requirements are still verbal and boundaries have not been clarified → use
Dependencies and automatic preparation
.docx is essentially ZIP-compressed XML, and the Read tool cannot read it, so this skill includes a Node parsing script.
This is the only one of the 11 skills in this repository that has runtime environment requirements; all the rest are pure Markdown.
The script requires Node.js ≥ 20 and three open-source parsing libraries (mammoth、jszip、xml2js）。
Before starting, self-check and prepare first—do not ask the user first, check yourself first
Execute in order;if the previous step succeeds, skip to the next step。
Step 1: Check whether Node is available
node --version
If there is output and it is ≥ v20 → go to Step 2. If it reports command not found or the version is too low → skip to Step 3.
Step 2: Check whether dependencies are already installed
ls "<本 skill 目录>/scripts/node_modules" >/dev/null 2>&1 && echo 已装 || echo 未装
If not installed,install directly; no need to ask for consent first—but before installing, explain in one sentence what you are installing:
Parsing Word requires installing 3 open-source parsing libraries first (mammoth / jszip / xml2js), a few MB; install once and no need to install again later.
npm --prefix "<本 skill 目录>/scripts" install
Installation fails (no network, npm error)Do not get stuck; go directly to Step 4 and explain the reason for the failure.
Step 3: Node unavailable → provide specific installation guidance + fallback
Do not just say "please install Node first". Give commands that can be followed:
| Platform | Approach |
|---|---|
| macOS | brew install node, or go to https://nodejs.org to download the LTS installer |
| Windows | Go to https://nodejs.org to download the LTS installer,and be sure to check Add to PATH during installation |
| Linux | Use the distribution package manager, or use nvm |
At the same time, a fallback must be provided, do not leave the user stuck at this step:
It is also fine if you do not want to install Node—copy and paste the content from Word directly to me, and the subsequent structuring process is exactly the same. Only images embedded in the document need to be screenshotted and saved by you.
Step 4: Take the pasted-text route
Skip the script and proceed normally starting from Step 2 of the "Process".The delivery notes must state clearly: the script was not used, fidelity verification was not performed, and embedded images were not automatically extracted.
feature-name naming rules
This section is the authoritative source for this repository's feature-name rules. Other skills are referenced here, not copied again— copying once means it drifts once.
(This file does not link to the repository's
docs/: when the skill is installed separately, that path does not exist. The linking convention is written indocs/chain.md's "Cross-document conventions", which is for users.)
<feature-name> determines the directory name,enforces pure English kebab-case：
| Rules | ✅ | ❌ |
|---|---|---|
| Only lowercase English + digits + hyphens | order-management |
Order_Management、order management |
| No Chinese (must be translated into semantic English) | member-points |
会员积分、hui-yuan |
| No modifiers (remove version numbers/dates/"PRD"/"requirements document"/"proposal") | payment-checkout |
payment-prd、payment-v2 |
| 2~5 words, total length ≤ 40 characters | user-center |
comprehensive-payment-checkout-system-with-refund |
Derivation order:User explicitly specifies(highest priority) → extract the subject from the file name and translate it → derive from the document title.
When multiple reasonable translations exist (e.g., "会员中心" could be user-center or member-center), list 2~3 candidates for the user to choose from,do not decide on your own。
Self-check before writing: all lowercase / contains only [a-z0-9-] / does not start or end with - and has no -- / length ≤ 40 / does not contain prd、v1, years, or other modifiers.
Process
1. Get the text
-
If there is a .docx：first run those 4 self-check steps according to "Dependencies and automatic preparation"(check Node → install dependencies → if installation fails, guide + provide a fallback), then run the script:
node "<本 skill 目录>/scripts/extract-docx.mjs" "<docx 路径>" --output-dir ".claude/context/{源文件名}-extracted" --quietAdd
--quiet—otherwise the full Markdown will be poured into the context. After running, use Read to readcontent.md. The script extracts the text (preserving h1–h6 hierarchy), tables (converted to Markdown tables), and embedded images (saved intoimages/) all together. -
User chooses to paste text: directly use the pasted content, and note in the delivery description that the script was not used, no fidelity check was performed, and embedded images were not extracted.
2. Structure by dimension
Extract item by item according to the following 8 dimensions.Tables are the most precise information source in a PRD, so extract from tables first; convert flowchart descriptions into "state transitions + operation sequences"; extract fields from the text descriptions next to interface screenshots.
| # | Dimension | What to extract |
|---|---|---|
| 1 | Business background | Project positioning (one paragraph), business goals (quantifiable), scope for this phase and what is not being done |
| 2 | User roles | Who each role is, in what scenarios they use it, what they care about most, 3~5 high-frequency operations |
| 3 | Functional modules | Module division, sub-functions, priority P0/P1/P2, dependencies between modules |
| 4 | Field definitions | One table per entity: field name, type, required, validation rules, default value, description |
| 5 | Business processes | Trigger conditions, state transitions, operation sequences, exception branches |
| 6 | Role permission matrix | A comparison table of function × role |
| 7 | Validation rules | Frontend validation, backend validation, business validation, and their respective prompt copy |
| 8 | Non-functional and acceptance | Performance/concurrency/data volume/security requirements; functional acceptance + general acceptance checklist |
3. Fidelity check (when using the script)
After the script runs, it automatically generates fidelity-report.txt，You must read it before deciding the next step：
| Condition | Action |
|---|---|
| Total score ≥ 90 and no hard-gate alerts | ✅ Continue directly |
| 70–89 or has ⚠️ | ⚠️ Check the alert items, fix them in a targeted way, then continue |
| < 70 or has ❌ | ❌ Stop and request manual intervention |
Hard gates (any one triggered is an alert, not masked by the total score): image file extraction rate < 90%, image reference rate < 90%, table extraction rate < 90%.
How to fix common alerts:Missing image files → most likely embedded charts or OLE objects; mark them in Markdown as [图表未提取：请手动补充]；Missing image references → the files were extracted but the body text does not have ![](), check the conversion;Lost text → most likely from text boxes or SmartArt; verify against the original text;Missing tables → may be nested tables or non-standard formats; manually check against the original text.
When the script was not used (pasted text), skip this step, but state "no fidelity check performed" in the delivery notes.
4. Annotate ambiguities
Write them as "Items to be confirmed", divided into three levels by impact:
- High (blocks development): affects architecture or data design — state the impact and the proposed solution
- Medium (affects detailed implementation): state the scope of impact and the recommendation
- Low (can be iterated later): explain why it can be deferred
Any lost content found in step 3 goes into "High".
5. Put it into the feature directory
- Determine
<feature-name>, and run through the self-check checklist. - Copy the images from
.claude/context/todocs/prd/<feature-name>/images/，and rewrite all image references uniformly to./images/xxxrelative paths—the final PRD must be self-contained and must not point to intermediate directories. - Write to
docs/prd/<feature-name>/prd.md。 - Read it back once to confirm there are no remaining
.claude/context/paths.
Evidence annotation (consistent with the repository)
Follow the three-way classification used by other skills in this repository,do not invent your own markers：
| Original text situation | Mark as |
|---|---|
| Explicitly stated | Extract directly, keep the key original wording |
| Reasonably inferable | [INFERRED], and state the basis for the inference |
| Not mentioned | [UNKNOWN], and state who should confirm it |
| Contradictory | Record both places and list them under Items to be confirmed |
Outputs
.claude/context/{源文件名}-extracted/ # 中间产物，保留供追溯
├── content.md
├── fidelity-report.txt
└── images/
docs/prd/<feature-name>/ # 最终交付，下游直接消费
├── prd.md # 8 个维度 + 待确认事项
└── images/ # 自包含副本，正文引用 ./images/xxx
Pre-delivery check
-
<feature-name>passed the 5 self-check rules - All 8 dimensions have content (even if only a
[UNKNOWN]placeholder) - All
[INFERRED]and[UNKNOWN]appear under Items to be confirmed - Fidelity score ≥ 70 (when the script was used), or it is noted that no check was performed
- Images have been copied to the feature directory, and the body text all uses
./images/xxx - Read back
prd.md, no.claude/context/residual paths
What not to do
- Do not invent requirements. For anything not written in the original text, mark it
[UNKNOWN], do not fill it in on behalf of the original author. - Do not perform engineering-side cross-validation (do not scan database DDL or entity classes).
- Do not treat intermediate artifacts
.claude/context/as deliverables—the final PRD must be self-contained. - Do not omit fidelity verification and still claim "extraction is complete."
Next step
Hand prd.md over to grill-with-prd for adversarial stress testing, and ask until the missing boundaries and acceptance criteria are surfaced—requirements in Word usually withstand line-by-line questioning the least.
When requirement background, competitive reference, or visual evidence needs to be supplemented, use context-to-prd or web-design-extractor。