pwp-docs
Scannednpx machina-cli add skill shandar/pwp-plugin/pwp-docs --openclawPWP Documentation Protocol
You are now operating under the Project Workflow Protocol's documentation discipline. Documentation is a living part of the codebase, not an afterthought.
Context: $ARGUMENTS
Phase 1: Identify Document Type
Determine which living document(s) need attention:
| Document | Purpose | Update When |
|---|---|---|
docs/VISION.md | Product roadmap, feature IDs | Adding/shipping features |
docs/plans/README.md | Plan registry & status | Creating/completing plans |
docs/plans/PLAN-*.md | Implementation details | During execution |
CHANGELOG.md | Version history | Each release |
docs/PRD.md | Requirements | Scope changes |
docs/ARCHITECTURE.md | Tech stack & diagrams | System changes |
README.md | Project overview | Setup/usage changes |
CLAUDE.md | AI agent instructions | Pattern/convention changes |
Phase 2: Feature Traceability
Use unique IDs to trace intent from vision to code:
Vision IDs: A1, S1 (in VISION.md)
Plan IDs: PLAN-001/P0 (in plan files)
Commits: feat(PLAN-001/P0): description
Code Comments: // See PLAN-001/P2 (where non-obvious)
Traceability Chain
VISION.md (feature A1)
→ PLAN-003.md (implements A1)
→ commit: feat(PLAN-003/P1): add payment form
→ code comment: // See PLAN-003/P2 for validation rules
Every feature should be traceable from "why we're building it" to "where the code lives."
Phase 3: CHANGELOG Management
Follow Keep a Changelog format:
## [Unreleased]
### Added
- New payment processing module (PLAN-003)
### Changed
- Updated auth flow to support OAuth2 (PLAN-005)
### Fixed
- Cart total calculation rounding error (#142)
### Removed
- Legacy XML export endpoint (deprecated since v2.1)
Rules
- Group by: Added, Changed, Deprecated, Removed, Fixed, Security
- Reference plan IDs or issue numbers
- Write for humans, not machines
- Update with every meaningful PR, not just releases
Phase 4: Architecture Documentation
ARCHITECTURE.md should cover:
- System Overview — High-level diagram of components
- Tech Stack — Languages, frameworks, databases, infrastructure
- Directory Structure — What lives where and why
- Data Flow — How requests move through the system
- Key Decisions — ADRs (Architecture Decision Records) for major choices
- External Services — APIs, third-party integrations, auth providers
When to Update
- Adding a new service or database
- Changing the deployment architecture
- Introducing a new major dependency
- Modifying the authentication flow
- Restructuring the directory layout
Phase 5: Post-Completion Walkthroughs
After completing a major feature or plan, create a Walkthrough Artifact:
## Walkthrough: {Feature Name}
### What Changed
- {Design decisions made and rationale}
- {Key files added or modified}
### Verification
- {What was tested and how}
- {Edge cases covered}
### Evidence
- {Screenshots for UI changes}
- {Test output / coverage report}
### Follow-up
- {Known limitations}
- {Future work identified}
- {Technical debt introduced}
Phase 6: README Standards
A project README must include:
- What it is — One sentence description
- Quick start — How to run it locally in <5 commands
- Prerequisites — Node version, env vars, services needed
- Project structure — Brief directory overview
- Available scripts — npm commands and what they do
- Contributing — Link to CONTRIBUTING.md
- License — Link to LICENSE
Documentation Anti-Patterns
| Anti-Pattern | Why It's Wrong | Do This Instead |
|---|---|---|
| "Self-documenting code" as excuse | Complex systems need context code can't provide | Write docs for the why, code for the what |
| Stale docs | Worse than no docs — actively misleading | Update docs in the same PR as code changes |
| Documenting everything | Noise drowns signal | Document decisions, architecture, and non-obvious patterns |
| Separate doc repo | Falls out of sync immediately | Docs live next to the code they describe |
Quick Checklist
- Correct document identified for the change
- Feature IDs trace from vision to code
- CHANGELOG updated with this release's changes
- Architecture docs reflect current system state
- README is accurate for new contributors
- No stale documentation left behind
- Walkthrough created for major features
Source
git clone https://github.com/shandar/pwp-plugin/blob/main/skills/pwp-docs/SKILL.mdView on GitHub Overview
pwp-docs standardizes the documentation lifecycle for living, current docs. It enables traceability from vision to code, manages changelogs, architecture docs, and walkthroughs, and prescribes where to create or update each document.
How This Skill Works
Identify the document type (VISION.md, PLAN-*.md, CHANGELOG.md, ARCHITECTURE.md, README.md). Use unique IDs to trace intent from vision to code (Vision IDs like A1, S1; Plan IDs like PLAN-001; commits like feat(PLAN-001/P0); and code comments like // See PLAN-001/P2). Follow a Keep a Changelog format for releases and keep ARCHITECTURE.md up to date. After major work, produce a Walkthrough artifact detailing changes, verification, and evidence.
When to Use It
- When creating or updating docs like VISION.md, PLAN-*.md, CHANGELOG.md, PRD/ARCHITECTURE.md, or README to reflect new work
- When you need to add feature traceability IDs and demonstrate end-to-end traceability
- When updating the changelog with the Unreleased section and proper categories (Added, Changed, Fixed, Removed, Security)
- When architecture changes occur (new service, major dependency, data flow update, or ADRs)
- When finishing a major feature and producing a Walkthrough artifact
Quick Start
- Step 1: Identify the documents to touch (VISION.md, PLAN-*.md, CHANGELOG.md, ARCHITECTURE.md, README) and collect relevant IDs
- Step 2: Update content and add traceability IDs (vision A1, plan PLAN-001, commits feat(...), and code comments // See PLAN-001/P2)
- Step 3: Create a Walkthrough artifact and update the changelog; verify cross-document references
Best Practices
- Identify the document type first (VISION.md, PLAN-*.md, CHANGELOG.md, ARCHITECTURE.md, README.md) and plan updates accordingly
- Use traceability IDs consistently: Vision IDs (A1, S1), Plan IDs (PLAN-001), commits (feat(PLAN-001/P0)), and code comments like // See PLAN-001/P2
- Follow Keep a Changelog formatting and group entries under Added, Changed, Fixed, Deprecated, Removed, Security in Unreleased
- Keep ARCHITECTURE.md up to date with System Overview, Tech Stack, Directory Structure, Data Flow, and ADRs
- Create a Walkthrough artifact after major work with sections What Changed, Verification, Evidence, and Follow-up
Example Use Cases
- Update a feature: add PLAN-003.md, refresh VISION.md with A1, and append a changelog entry under Unreleased for PLAN-003
- Architecture refresh: modify ARCHITECTURE.md to reflect a new service, including data flow and external services
- Traceability inline: add code comments like // See PLAN-001/P2 to map code changes back to plans
- Plan execution: create docs/plans/PLAN-123.md and link it to Vision A1 and relevant commits
- Post-completion: publish a Walkthrough artifact detailing What Changed, Verification, Evidence, and Follow-up