| name | release-layout |
| description | Use this when the user wants to improve README, docs pages, or microsites so a new reader can understand what the project is, how to use it, what artifacts exist, and what the scope boundaries are within one screen. |
| metadata | {"openclaw":{"emoji":"🪄"}} |
Release Layout
Don't ask permission. Just do it.
Use this skill for outward-facing packaging surfaces such as:
README.mddocs/index.html- release page generator scripts
This skill improves structure and legibility. It does not upgrade the scientific claim on its own.
Core Goal
A first-time reader should understand, within one screen:
- what this is
- how to use it
- what artifacts it produces
- what the scope boundary is
Workflow
Step 1: Detect the Real Edit Target
If a page is generated by a script, prefer editing the generator rather than the built HTML.
If review/release_gate.json exists, read it before polishing release-facing copy.
Step 2: Audit the First Screen
Check whether the hero / opening section answers the four core questions above.
Step 3: Reshape the Page
Prefer this order:
- hero / product definition
- quick-start or usage path
- artifact map
- evidence / results block
- scope note
- FAQ or next steps
Use references/page-structure.md.
Step 4: Clean the Reading Path
Reduce:
- duplicated claims
- buried usage instructions
- unexplained metrics
- isolated figures without framing text
Safety Rules
- Do not hide limitations for the sake of visual polish.
- Do not introduce stronger language than the underlying artifacts support.
- If the result is simulator-only, say that near the top instead of burying it below the fold.
- If the release gate is
HOLD, stale, or missing for a share-ready artifact set, do not present the project as fully ready to share.
