🎁 Get the FREE AI Skills Starter Guide β€” Subscribe β†’
BytesAgainBytesAgain
BytesAgain β€Ί Skills β€Ί Project Documentation
πŸ¦€ ClawHub

Project Documentation

by @wpank

Complete workflow for project documentation including ADRs, PRDs, personas, and docs organization. Use when setting up documentation for a new project or improving existing docs. Triggers on project documentation, ADR, PRD, personas, docs structure, documentation setup.

Versionv1.0.0
Downloads2,111
Installs9
Stars⭐ 3
#legal#automation
TERMINAL
clawhub install project-documentation

πŸ“– About This Skill

name: project-documentation model: standard description: Complete workflow for project documentation including ADRs, PRDs, personas, and docs organization. Use when setting up documentation for a new project or improving existing docs. Triggers on project documentation, ADR, PRD, personas, docs structure, documentation setup.

Project Documentation (Meta-Skill)

Complete workflow for setting up and maintaining project documentation.

Installation

OpenClaw / Moltbot / Clawbot

npx clawhub@latest install project-documentation

When to Use

  • Starting a new project and need docs structure
  • Improving documentation on existing project
  • Setting up ADRs, PRDs, or persona docs
  • Want consistent documentation across projects

    • Docs-First Philosophy

    Start every project with documentation, not code:

    1. Define the idea      β†’ What is this? What problem does it solve?
2. Define the personas  β†’ Who uses this? What are their journeys?
3. Define the features  β†’ What does it do for each persona?
4. Define the stack     β†’ What technologies? Why?
5. Then build           β†’ With full context established

    Directory Structure

    docs/
β”œβ”€β”€ architecture/        # CURRENT STATE - Living docs of actual code
β”‚   β”œβ”€β”€ overview.md
β”‚   └── data-flow.md
β”œβ”€β”€ guides/              # CURRENT STATE - How to use/operate
β”‚   β”œβ”€β”€ getting-started.md
β”‚   └── configuration.md
β”œβ”€β”€ runbooks/            # CURRENT STATE - Short, actionable guides
β”‚   β”œβ”€β”€ local-dev.md
β”‚   β”œβ”€β”€ deploy.md
β”‚   └── database.md
β”œβ”€β”€ planning/            # FUTURE - Not for docs site
β”‚   β”œβ”€β”€ roadmap.md
β”‚   └── specs/
β”œβ”€β”€ decisions/           # ADRs - Decision records
β”‚   β”œβ”€β”€ 001-tech-stack.md
β”‚   └── 002-auth-approach.md
└── product/             # PRD, personas
    β”œβ”€β”€ overview.md
    β”œβ”€β”€ personas/
    └── features.md

    Critical Separation: Current vs Future

    | Category | Purpose | Goes on Docs Site? | |----------|---------|-------------------| | Current State | How things work now | Yes | | Planning | Future specs, designs | No | | Architecture | Living docs of code | Yes | | Roadmap/Todos | What we're working on | No | | Runbooks | How to operate | Yes | | Proposed Runbooks | Future plans | No |

    Documentation Types

    Architecture Decision Records (ADRs)

    Template: 

    # ADR-001: [Title]
    Status
    
[Proposed | Accepted | Deprecated | Superseded]
    Context
    
[What is the issue we're solving?]
    Decision
    
[What did we decide?]
    Consequences
    
[What are the results - positive and negative?]
    Alternatives Considered
    
[What other options did we evaluate?]

    Product Requirements Document (PRD)

    Template: 

    # PRD: [Feature Name]
    Problem
    
[What problem are we solving?]
    Users
    
[Which personas does this serve?]
    Requirements
    

  • [ ] Requirement 1
    • 

  • [ ] Requirement 2
    • Non-Goals
    
[What are we explicitly NOT doing?]
    Success Metrics
    
[How do we know this worked?]

    Persona Documentation

    Template: 

    # Persona: [Name]
    Who They Are
    

  • Background
    • 

  • Technical level
    • 

  • Goals
    • Pain Points
    

  • [Pain 1]
    • 

  • [Pain 2]
    • Journey
    
1. Discovery
2. Onboarding
3. Daily use
4. Advanced usage
    Content Needs
    

  • Doc types they need
    • 

  • Format preferences
    •

    Runbooks

    Template: 

    # Runbook: [Task Name]
    Prerequisites
    

  • [Requirement 1]
    • 

  • [Requirement 2]
    • Steps
    
1. [Step 1]
2. [Step 2]
    Verify
    
[How to confirm success]
    Troubleshooting
    
| Problem | Solution |
|---------|----------|
| [Issue] | [Fix] |

    Roadmap Format

    ## Roadmap
    Current Sprint
    

  • [ ] Add user authentication endpoint
    • 

  • [ ] Create login form component
    • 

  • [ ] Wire form to auth endpoint
    • Backlog
    

  • [ ] Password reset flow
    • 

  • [ ] OAuth integration
    • 

  • [ ] Two-factor auth
    •

    Quality Gates

    Before shipping docs:

  • [ ] Separates current state from planning
  • [ ] Uses appropriate template for doc type
  • [ ] Written for the right audience
  • [ ] Actionable (runbooks) or explanatory (guides)
  • [ ] No stale/outdated information

    • Anti-Patterns

  • Mixing future plans with current state β€” Confuses what's real
  • Planning docs on docs site β€” Users expect reality
  • One-size-fits-all docs β€” Different audiences need different depth
  • Building features before personas β€” No context for decisions
  • Documentation written once and forgotten β€” Keep it current

    • Checklist for New Projects

  • [ ] Create docs/ directory structure
  • [ ] Write initial PRD/overview
  • [ ] Document 2-3 personas
  • [ ] Create ADR-001 for tech stack
  • [ ] Set up roadmap format
  • [ ] Create essential runbooks (local-dev, deploy)
  • [ ] Separate planning/ from current-state docs

    • Related Skills

  • Commands: /bootstrap-docs, /new-feature
  • Agent: development

    • ⚑ When to Use

    TriggerAction
    - Improving documentation on existing project
    - Setting up ADRs, PRDs, or persona docs
    - Want consistent documentation across projects
    ---

    βš™οΈ Configuration

  • [Requirement 1]
  • [Requirement 2]

    • πŸ“‹ Tips & Best Practices

    | Problem | Solution | |---------|----------| | [Issue] | [Fix] | ```