| name | newspaper-editorial-layout |
| description | Write long-form answers as high-density newspaper-style pages when the user wants a report, brief, feature page, morning brief, project update, or highly scannable HTML/editorial output. Use for long replies that should be easy to scan first and deep-read second. Especially useful when the user asks for "报纸排版", wants HTML pages instead of chat bubbles, or wants titles/deks/body rewritten into editorial form rather than markdown sections. |
Newspaper Editorial Layout
Overview
Use this skill when the goal is not merely to wrap content in HTML, but to rewrite the content in an editorial way so it reads like a newspaper page:
- fast to scan
- dense with useful information
- structured for both overview and deep reading
This skill is about writing + layout together.
Do not take markdown headings and mechanically pour them into boxes.
Instead, decide the page shape, rewrite titles and deks, then place content.
Core standard
Optimize for two things at once:
- 可扫读 — the user should understand the page quickly
- 高信息密度 — the page must still contain real detail, not compressed emptiness
Do not optimize for shortness alone.
A good page is not short because it cut content away.
A good page is short where it should be short, and detailed where detail carries value.
When to use this skill
Use this skill when the user wants any of the following:
- a newspaper-style page
- an HTML brief or feature page
- a morning brief / daily brief / project edition
- a highly scannable long answer
- a page that separates quick scan from deep read
- long responses transformed into editorial output instead of normal chat prose
Typical requests:
- “排成报纸”
- “给我一个 HTML 页面”
- “做成晨报”
- “让我先扫一眼，再往下深读”
- “把你的长回复都做成报纸模式”
Default page model
Prefer a page with these roles:
- masthead: page identity and context
- lead story: biggest conclusion and main reading area
- secondary stories: supporting analysis or expansions
- briefs / quick-scan rail: compressed facts, constraints, files, status, or key changes
- quote / utility block: one distilled principle or memorable line
- footer: path / file / tags / edition metadata
Default reading split:
- left/main column = deep read
- right columns / rails = quick scan
Writing rules
1. Titles must carry information
A headline should deliver a judgment, change, or situation.
It should not merely label a topic.
Bad:
- 昨晚具体推进了什么
- 当前卡在哪
- 一句判断
- 接下来最值得做的三件事
Better:
- BYOC 已进入可演示规格阶段
- 阻塞点在字段、页面和第二个 demo
- 现在要先收 schema
- 下一步先收口，再测第二个 demo
2. Keep headlines short and direct
Prefer:
- short
- scannable
- judgment-led
- low-turning
Avoid headline habits like:
- long winding setup
- repeated qualifiers
- “不是……而是……” sentence structure
- abstract category labels with no payload
If possible, a headline should be understandable when seen alone in a screenshot.
3. Deks are short, but not empty
A dek should compress the background.
It should not repeat the title with fluff.
Use the dek to answer:
- why this matters
- what changed
- what the page is about in 1–2 lines
Keep it short, but retain essential relationships.
4. Body paragraphs start with the conclusion
The first sentence of a paragraph should land quickly.
Do not spend the first sentence warming up.
Preferred pattern:
- sentence 1: conclusion / claim
- sentence 2+: object names, links, examples, mechanism, implications
Example:
第一版文档已经把对象和边界定下来了。昨晚已经形成了产品定义、协议草案和最小 schema……
5. Do not cut detail that carries value
When compressing:
- cut repetition
- cut empty transition phrases
- cut decorative meta language
Do not cut:
- concrete object names
- key files / artifacts
- relationships between systems
- actual blockers
- the user’s next action
- examples that make the judgment believable
Rule of thumb:
If removing a sentence makes the page less true or less actionable, keep it.
6. Quick-scan areas should read like short news items
For briefs / right rails / sidebars:
- compress into one useful sentence each
- prefer fact + significance
- avoid file-path soup unless file names are themselves important
Bad brief:
specs/protocol-draft.md 已定义网站 × OpenClaw 的最小协作对象。
Better brief:
协议草案已经列出网站 × OpenClaw 的最小对象。
Keep paths only when they help navigation or verification.
Layout heuristics
Use a 3-column layout when:
- there is a clear lead story
- there are supporting side facts / status items
- the user wants scan-first reading
Use a 2-column layout when:
- the page is more essay-like
- supporting material is lighter
- the lead story needs more horizontal room
Use fewer boxes when:
- the page starts feeling like a dashboard
- the user wants “像报纸，不像后台”
- the flow is better served by continuous prose and subheads
Rewriting workflow
When producing a page, follow this order:
-
Find the real judgments
- what changed?
- what matters?
- what blocks progress?
- what should happen next?
-
Write the headline system
-
Assign reading roles
- deep read on the left
- quick scan on the right
-
Write body paragraphs
- lead with conclusions
- keep concrete detail where it matters
-
Then write the HTML
- do not start from boxes
- do not start from markdown headings
Editing checklist
Before finalizing, check:
- Are the headlines informative, or are they still just labels?
- Did any headline become too long or too twisty?
- Did shortening reduce actual information density?
- Does the dek add context, not fluff?
- Does each body paragraph land quickly?
- Does the right rail help scan, not duplicate the left column?
- Does the page feel like editorial hierarchy rather than admin panels?
Preferred style summary
Stable preferences for this style:
- long replies should prefer newspaper/editorial organization
- headlines should be short, direct, and informative
- minimize turning/contrast structures like “不是……而是……”
- deks should be short but meaningful
- body paragraphs should land fast
- information density matters more than sheer brevity
- left side should support deep reading
- right side should support quick scanning
Resources
references/
Read these only when useful:
references/headline-patterns.md — headline rewrite patterns and examplesreferences/layout-decisions.md — how to choose page shape and density tradeoffs
