Doc Expert
Professional technical documentation authoring for product requirements, business requirements, technical designs, and solution reviews.
Overview
This skill creates well-structured, professionally formatted technical documents. It supports multiple document types with standardized templates, ensures logical rigor, and adapts content depth to the target audience.
Supported Document Types
| Type |
Purpose |
Target Audience |
| PRD |
Product Requirements Document |
Product teams |
| BRD |
Business Requirements Document |
Business / Management |
| HLD |
High-Level Design |
Architecture team |
| LLD |
Low-Level Design |
Development team |
| TDD |
Technical Design Document |
Cross-functional teams |
| Solution Review |
Alternative comparison & recommendation |
Decision makers |
See references/document-structures.md for detailed templates.
Inputs
| Parameter |
Type |
Required |
Description |
doc_type |
string |
Yes |
Document type: PRD, BRD, HLD, LLD, TDD, or solution-review |
topic |
string |
Yes |
Subject or feature to document |
context |
string |
No |
Additional context, requirements, or background info |
audience |
string |
No |
Target audience: product, business, dev, or mixed |
output_path |
string |
No |
Custom output directory or file path (defaults to current directory) |
Outputs
| Output |
Type |
Description |
document |
Markdown |
Complete structured document in Markdown format |
structure |
list |
Document outline with sections |
placeholders |
list |
Missing information marked as [TBD: xxx] |
status |
string |
"complete" or "needs_info" |
file_path |
string |
Path to saved document file (user-specified or auto-generated) |
Output Format
Documents are saved as .md files:
Default Behavior (No output_path specified)
- Save to current working directory
- Auto-generated filename:
{DocType}-{Topic}-{YYYYMMDDHHMM}.md
- Example:
PRD-Login-Refactor-202604071430.md
User-Specified Output Path
| Input Format |
Behavior |
Example |
| Directory path |
Save to directory with auto-generated filename |
./docs/ → ./docs/PRD-Login-Refactor-202604071430.md |
| File path (with .md) |
Save with exact filename |
./docs/my-prd.md → ./docs/my-prd.md |
| File path (no extension) |
Append .md automatically |
./docs/design → ./docs/design.md |
Output Requirements
- File content - Pure Markdown, ready for immediate use
- No HTML wrapper - Use native Markdown, not HTML-styled content
- Console output - After saving, output a Markdown hyperlink as the final line of the response
Filename Generation Rules
- DocType: PRD, BRD, HLD, LLD, TDD, or Solution
- Topic: Use PascalCase, limit to 3-5 words, remove articles (a, an, the)
- Date: Local date/time in YYYYMMDDHHMM format
Language Rules
- Default: English output
- Switch to Chinese only when explicitly requested
Writing Principles
| Principle |
Description |
| Structure First |
Fixed chapter skeleton before content filling |
| Logical Rigor |
Clear cause-and-effect, no jumping conclusions |
| Precise Expression |
Accurate terminology, avoid vague phrasing |
| Audience Awareness |
Adjust depth for developers / product / management |
| Information Completeness |
Ask for missing key details before writing |
Workflow
Step 1: Identify Document Type
Determine document type from user request:
- PRD keywords: "product requirements", "user story", "feature spec"
- BRD keywords: "business requirements", "ROI", "objectives"
- HLD keywords: "high level design", "architecture", "system design"
- LLD keywords: "low level design", "detailed design", "module design"
- TDD keywords: "technical design", "design doc"
- Solution keywords: "compare solutions", "review options", "pros and cons"
Step 2: Gather Information
Information Assessment:
| Sufficient? |
Action |
| Yes |
Proceed to Step 3 |
| No |
List 3-5 critical missing questions, ask user |
Required Information:
- Document subject/topic
- Core requirements or objectives
- Target audience
- Constraints or dependencies (if any)
Step 3: Select Template
Load appropriate structure from references/document-structures.md:
| Document |
Sections |
| PRD |
10 sections (background, requirements, milestones, etc.) |
| BRD |
9 sections (executive summary, ROI, stakeholders, etc.) |
| HLD |
10 sections (architecture, modules, deployment, etc.) |
| LLD |
8 sections (data model, interfaces, test points, etc.) |
| Solution |
9 sections (alternatives, comparison, risks, etc.) |
Step 4: Generate Document
Process:
- Build document outline based on template
- Fill sections with provided information
- Use
[TBD: description] for missing content
- Adapt tone for target audience:
- Product: Focus on user value and acceptance criteria
- Business: Focus on ROI and strategic alignment
- Dev: Focus on technical implementation and interfaces
Formatting Rules:
- **Avoid triple backticks (```)** in output documents - use single backticks (`) for inline code or indentation for code blocks instead
- This prevents rendering issues when the document is displayed in agent frontends
Step 5: Save and Deliver
Determine output path:
| Scenario |
Action |
| User specifies directory |
Use: {output_path}/{DocType}-{Topic}-{YYYYMMDDHHMM}.md |
| User specifies file path |
Use exact path (add .md if missing) |
| No output_path provided |
Use: ./{DocType}-{Topic}-{YYYYMMDDHHMM}.md |
Save the document:
- Resolve final file path based on above rules
- Use Write tool to save file
- Confirm save success and output the absolute file path
Quality Checklist:
Console output format:
The final line of your response must be:
[file-name.md](file:///fileAbsolutePath)
Replace file-name.md with the actual filename. Replace fileAbsolutePath with the actual file absolute path. This is a Markdown hyperlink; render it as clickable text. Important: The file path must be the actual file absolute path.
Example:
[PRD-Login-Refactor-202604071430.md](file:///workspace/PRD-Login-Refactor-202604071430.md)
Error Handling
| Error Scenario |
Cause |
Solution |
| Unclear document type |
Ambiguous user request |
Ask user to specify PRD/BRD/HLD/LLD/TDD/Solution |
| Insufficient context |
Missing key requirements |
Request specific details before proceeding |
| Unknown domain |
Unfamiliar technology/concept |
Use generic template, mark domain-specific sections as TBD |
| Conflicting requirements |
Contradictory inputs |
Highlight conflicts, ask for clarification |
| File save failed |
Permission denied or path issue |
Report error and output document content directly |
| Filename collision |
File already exists |
Append counter suffix: -v2, -v3 etc. |
Examples
Basic Usage
- "Write a PRD for user login feature"
- "Create BRD for payment system upgrade"
- "Generate HLD for microservices migration"
- "Draft solution review comparing Redis vs Memcached"
- "Help me document the API gateway architecture"
With Custom Output Path
- "Write a PRD for user login and save it to ./docs/"
- "Create BRD for payment system and save as ./requirements/payment-v2.md"
- "Generate HLD for microservices migration to ./design-docs/architecture.md"
1---2name: doc-expert3description: Professional technical documentation expert for creating PRDs, BRDs, HLDs, LLDs, TDDs, and technical solution documents. Trigger this skill when users request write document, write PRD, write BRD, write technical design, write HLD, write LLD, write TDD, solution review, create technical documentation, organize requirements, or draft a proposal.4---56# Doc Expert78Professional technical documentation authoring for product requirements, business requirements, technical designs, and solution reviews.910## Overview1112This skill creates well-structured, professionally formatted technical documents. It supports multiple document types with standardized templates, ensures logical rigor, and adapts content depth to the target audience.1314## Supported Document Types1516| Type | Purpose | Target Audience |17|------|---------|-----------------|18| PRD | Product Requirements Document | Product teams |19| BRD | Business Requirements Document | Business / Management |20| HLD | High-Level Design | Architecture team |21| LLD | Low-Level Design | Development team |22| TDD | Technical Design Document | Cross-functional teams |23| Solution Review | Alternative comparison & recommendation | Decision makers |2425See [references/document-structures.md](references/document-structures.md) for detailed templates.2627## Inputs2829| Parameter | Type | Required | Description |30|-----------|------|----------|-------------|31| `doc_type` | string | Yes | Document type: PRD, BRD, HLD, LLD, TDD, or solution-review |32| `topic` | string | Yes | Subject or feature to document |33| `context` | string | No | Additional context, requirements, or background info |34| `audience` | string | No | Target audience: product, business, dev, or mixed |35| `output_path` | string | No | Custom output directory or file path (defaults to current directory) |3637## Outputs3839| Output | Type | Description |40|--------|------|-------------|41| `document` | Markdown | Complete structured document in Markdown format |42| `structure` | list | Document outline with sections |43| `placeholders` | list | Missing information marked as `[TBD: xxx]` |44| `status` | string | "complete" or "needs_info" |45| `file_path` | string | Path to saved document file (user-specified or auto-generated) |4647## Output Format4849**Documents are saved as `.md` files**:5051### Default Behavior (No output_path specified)52- Save to current working directory53- Auto-generated filename: `{DocType}-{Topic}-{YYYYMMDDHHMM}.md`54 - Example: `PRD-Login-Refactor-202604071430.md`5556### User-Specified Output Path5758| Input Format | Behavior | Example |59|--------------|----------|---------|60| Directory path | Save to directory with auto-generated filename | `./docs/` → `./docs/PRD-Login-Refactor-202604071430.md` |61| File path (with .md) | Save with exact filename | `./docs/my-prd.md` → `./docs/my-prd.md` |62| File path (no extension) | Append `.md` automatically | `./docs/design` → `./docs/design.md` |6364### Output Requirements651. **File content** - Pure Markdown, ready for immediate use662. **No HTML wrapper** - Use native Markdown, not HTML-styled content673. **Console output** - After saving, output a Markdown hyperlink as the final line of the response6869### Filename Generation Rules70- DocType: PRD, BRD, HLD, LLD, TDD, or Solution71- Topic: Use PascalCase, limit to 3-5 words, remove articles (a, an, the)72- Date: Local date/time in YYYYMMDDHHMM format7374## Language Rules7576- **Default**: English output77- Switch to Chinese only when explicitly requested7879## Writing Principles8081| Principle | Description |82|-----------|-------------|83| Structure First | Fixed chapter skeleton before content filling |84| Logical Rigor | Clear cause-and-effect, no jumping conclusions |85| Precise Expression | Accurate terminology, avoid vague phrasing |86| Audience Awareness | Adjust depth for developers / product / management |87| Information Completeness | Ask for missing key details before writing |8889## Workflow9091### Step 1: Identify Document Type9293Determine document type from user request:94- PRD keywords: "product requirements", "user story", "feature spec"95- BRD keywords: "business requirements", "ROI", "objectives"96- HLD keywords: "high level design", "architecture", "system design"97- LLD keywords: "low level design", "detailed design", "module design"98- TDD keywords: "technical design", "design doc"99- Solution keywords: "compare solutions", "review options", "pros and cons"100101### Step 2: Gather Information102103**Information Assessment:**104105| Sufficient? | Action |106|-------------|--------|107| Yes | Proceed to Step 3 |108| No | List 3-5 critical missing questions, ask user |109110**Required Information:**111- Document subject/topic112- Core requirements or objectives113- Target audience114- Constraints or dependencies (if any)115116### Step 3: Select Template117118Load appropriate structure from [references/document-structures.md](references/document-structures.md):119120| Document | Sections |121|----------|----------|122| PRD | 10 sections (background, requirements, milestones, etc.) |123| BRD | 9 sections (executive summary, ROI, stakeholders, etc.) |124| HLD | 10 sections (architecture, modules, deployment, etc.) |125| LLD | 8 sections (data model, interfaces, test points, etc.) |126| Solution | 9 sections (alternatives, comparison, risks, etc.) |127128### Step 4: Generate Document129130**Process:**1311. Build document outline based on template1322. Fill sections with provided information1333. Use `[TBD: description]` for missing content1344. Adapt tone for target audience:135 - Product: Focus on user value and acceptance criteria136 - Business: Focus on ROI and strategic alignment137 - Dev: Focus on technical implementation and interfaces138139**Formatting Rules:**140- **Avoid triple backticks (```)** in output documents - use single backticks (`) for inline code or indentation for code blocks instead141- This prevents rendering issues when the document is displayed in agent frontends142143### Step 5: Save and Deliver144145**Determine output path:**146147| Scenario | Action |148|----------|--------|149| User specifies directory | Use: `{output_path}/{DocType}-{Topic}-{YYYYMMDDHHMM}.md` |150| User specifies file path | Use exact path (add `.md` if missing) |151| No output_path provided | Use: `./{DocType}-{Topic}-{YYYYMMDDHHMM}.md` |152153**Save the document:**1541. Resolve final file path based on above rules1552. Use Write tool to save file1563. Confirm save success and output the absolute file path157158**Quality Checklist:**159- [ ] All required sections present160- [ ] Logical flow between sections161- [ ] No placeholder text left for provided info162- [ ] TBD markers for genuinely missing info163- [ ] Consistent terminology throughout164- [ ] Audience-appropriate depth165- [ ] File successfully saved to disk166167**Console output format:**168169The final line of your response must be:170171`[file-name.md](file:///fileAbsolutePath)`172173Replace `file-name.md` with the actual filename. Replace `fileAbsolutePath` with the actual file absolute path. This is a Markdown hyperlink; render it as clickable text. Important: The file path must be the actual file absolute path.174175Example:176`[PRD-Login-Refactor-202604071430.md](file:///workspace/PRD-Login-Refactor-202604071430.md)`177178## Error Handling179180| Error Scenario | Cause | Solution |181|----------------|-------|----------|182| Unclear document type | Ambiguous user request | Ask user to specify PRD/BRD/HLD/LLD/TDD/Solution |183| Insufficient context | Missing key requirements | Request specific details before proceeding |184| Unknown domain | Unfamiliar technology/concept | Use generic template, mark domain-specific sections as TBD |185| Conflicting requirements | Contradictory inputs | Highlight conflicts, ask for clarification |186| File save failed | Permission denied or path issue | Report error and output document content directly |187| Filename collision | File already exists | Append counter suffix: `-v2`, `-v3` etc. |188189## Examples190191### Basic Usage192- "Write a PRD for user login feature"193- "Create BRD for payment system upgrade"194- "Generate HLD for microservices migration"195- "Draft solution review comparing Redis vs Memcached"196- "Help me document the API gateway architecture"197198### With Custom Output Path199- "Write a PRD for user login and save it to ./docs/"200- "Create BRD for payment system and save as ./requirements/payment-v2.md"201- "Generate HLD for microservices migration to ./design-docs/architecture.md"
ming-14