Small but operational
It focuses on the smallest useful governance/doc pack instead of building process theatre.
OpenClaw skill · small · practical · reality-first
Practical project governance for greenfield and retrofit work.
Project Governance Docs is a small OpenClaw skill that helps you define new projects, document projects already in progress, update only impacted docs, and keep governance useful without turning it into process theatre.
Quick invoke
/docsmenu (fixed menu) updatedocs = update impacted docs greenfield retrofit update impacted docs backup project restore project
Why this project is useful
Small enough to stay clear, practical enough to matter.
Reality-first retrofit behavior
When code already exists, it documents current reality first instead of redesigning the project in docs.
No fake rollback claims
Backup and restore language stays honest: only promise real checkpoints, and ask when the target project is unclear.
Evidence-backed completion
Done means more than “task complete” — it encourages compact proof and explicit residual risk.
Lesson extraction
Repeated mistakes can be turned into compact lessons, checklists, and stronger behavior without bloating the system.
Lean by design
It tightens existing workflows instead of creating new modes, abstractions, or a giant memory platform.
Get started
Three quick steps for a new user.
1. Install the skill
Import the packaged skill or copy the source folder into your local OpenClaw skills directory.
2. Open the workflow menu
Run /docsmenu to show the fixed workflow menu verbatim and pick the workflow that matches the project state.
3. Choose the right mode
Use greenfield for new projects, retrofit for existing ones, and update impacted docs after confirmed changes.
Install
Install it the simple way.
Option 1 — packaged skill
Download the packaged skill file and import it using your normal OpenClaw skill import flow.
Option 2 — source install
Copy the source skill folder into your local OpenClaw skills directory, then reload/restart OpenClaw if needed.
Workflows
Five simple workflow selectors.
greenfield
Define the project before coding. Best for new projects that need a foundation first. Can also be sent by itself as a direct workflow selection.
retrofit
Document and govern the current implementation first. Best for projects already in progress. Can also be sent by itself as a direct workflow selection.
update impacted docs
Update only the docs affected by the latest confirmed change in the current project context. updatedocs works as a direct alias.
backup project
Create a real checkpoint for the current clearly scoped project. If the target is unclear, ask first.
restore project
Restore the current clearly scoped project from a real checkpoint. If the target is unclear, ask first.
Lean learning loops
Built to learn without becoming bloated.
Included behavior
- learn from repeated mistakes
- use bounded fallback behavior when things are unclear
- prove completion with compact evidence
- do short post-task review and light pre-mortem where it helps
- promote strong repeated lessons into reusable behavior
How learning stays useful
- capture
- compress
- evaluate
- promote
- retain
- retire
The goal is to preserve useful learning without keeping passive duplicated clutter forever.
Example
A simple real-world path through the skill.
- Run
/docsmenu. - Choose retrofit when the project already exists.
- Inspect the current repo first.
- Update only the docs that became inaccurate.
Project links
Jump straight to the right place.
GitHub repository
Main project repo with source, dist, and README.
Packaged release files
Useful if you want the built skill artifact first.
Source skill folder
Useful if you want to inspect or install from source.
Contributing
Friendly to contributors, but still disciplined.
Good places to start
- clarify ambiguous wording
- improve examples
- tighten retrofit/greenfield guidance
- improve README clarity
- add small reusable templates
- strengthen practical guardrails or decision rules
Suggested contribution flow
- For small documentation or wording fixes, open a PR directly.
- For larger workflow changes, open an issue or discussion first.
- Keep PRs focused and explain what changed, why, and what was intentionally left unchanged.