Project Documentation

Project Documentation (Meta-Skill)

Complete workflow for setting up and maintaining project documentation.

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

CategoryPurposeGoes on Docs Site?Current StateHow things work nowYesPlanningFuture specs, designsNoArchitectureLiving docs of codeYesRoadmap/TodosWhat we're working onNoRunbooksHow to operateYesProposed RunbooksFuture plansNo

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