---
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.md`
- `docs/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:

1. what this is
2. how to use it
3. what artifacts it produces
4. 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:

1. hero / product definition
2. quick-start or usage path
3. artifact map
4. evidence / results block
5. scope note
6. 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

1. Do not hide limitations for the sake of visual polish.
2. Do not introduce stronger language than the underlying artifacts support.
3. If the result is simulator-only, say that near the top instead of burying it below the fold.
4. 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.