docs-writer

📁 adeonir/agent-skills 📅 1 day ago
1
总安装量
1
周安装量
#53370
全站排名
安装命令
npx skills add https://github.com/adeonir/agent-skills --skill docs-writer

Agent 安装分布

amp 1
opencode 1
kimi-cli 1
codex 1
claude-code 1

Skill 文档

Docs Writer

Generate structured documents through guided discovery. 7 document types, each with its own workflow depth.

Workflow

trigger --> detect type --> load reference --> discovery --> drafting

Detect document type from the trigger. If ambiguous, ask the user which type they want.

Document Types

Type Workflow Reference Template
PRD discovery -> analysis -> drafting prd.md prd.md
Issue classification -> drafting issue.md issue.md
Task direct drafting task.md task.md
User Story discovery -> drafting user-story.md user-story.md
RFC discovery -> analysis -> drafting rfc.md rfc.md
ADR discovery -> drafting adr.md adr.md
TDD discovery -> analysis -> drafting tdd.md tdd.md

Triggers

Trigger Pattern Type Reference
Create PRD, define product, product requirements, write PRD PRD prd.md
Create issue, report bug, feature request, create discussion Issue issue.md
Create task, sprint task, new task Task task.md
Create user story, write story, new story User Story user-story.md
Create RFC, propose change, request for comments RFC rfc.md
Create ADR, record decision, architecture decision ADR adr.md
Create TDD, technical design, design document TDD tdd.md
Create document, write doc Ask user

Shared Discovery Patterns

LOAD: discovery.md before starting any type that requires discovery.

Discovery applies to: PRD, Issue (feature/discussion subtypes), User Story, RFC, ADR, TDD. Discovery does NOT apply to: Task, Issue (bug subtype — uses structured reproduction instead).

Output

All documents save to .specs/docs/. Create the directory if it doesn’t exist.

Type Filename Pattern
PRD prd-{name}.md
Issue issue-{name}.md
Task task-{name}.md
User Story story-{name}.md
RFC rfc-{name}.md
ADR adr-{number}-{name}.md
TDD tdd-{name}.md

Use kebab-case for {name}. For ADR, auto-detect the next sequential number from existing files in .specs/docs/.

Quality Standards

Requirements must be concrete and measurable across all document types.

Bad Good
“Search should be fast” “Search returns results within 200ms”
“Easy to use” “New users complete onboarding in under 2 minutes”
“Intuitive interface” “Task completion rate above 90% without help text”

Guidelines

DO:

  • Always complete discovery before drafting (for types that require it)
  • Present draft for user feedback before saving
  • Mark unknowns as TBD rather than inventing constraints
  • Use concrete, measurable requirements
  • Ask for document name in kebab-case

DON’T:

  • Skip discovery for types that require it
  • Assume document type — detect from trigger or ask
  • Include visual/design direction (that belongs in design-builder)
  • Use vague adjectives as requirements (“fast”, “easy”, “intuitive”)
  • Mix document types in a single file

Cross-References

docs-writer -----> spec-driven    (any doc can feed into a spec)
docs-writer -----> design-builder (PRD informs copy and design extraction)
RFC -------------> ADR            (accepted RFC generates ADR)
TDD -------------> ADR            (references relevant decisions)

Integration with Other Skills

  • design-builder: PRD sections 1, 2, 3 inform copy extraction and design extraction
  • spec-driven: Any document can be input for feature initialization when implementation is complex

Error Handling

  • No .specs/docs/: Create the directory
  • Ambiguous trigger: Ask user which document type
  • Missing context for discovery: Ask questions, never assume
  • ADR numbering conflict: Scan existing files and use next available number