modbender 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