project-documentation（项目文件）

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

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