GitHub-README Hero.skill

Turn ordinary GitHub README pages, skill landing pages, or Markdown intros into cover-like hero layouts with centered titles, quote-led openings, restrained...

Security Scan

This is an instruction-only README/Markdown editing skill whose requested artifacts and runtime instructions are coherent with its stated purpose.

Purpose & Capability

Name/description (hero-style README redesign) match the SKILL.md and README content. The skill requests no binaries, credentials, or installs that would be unrelated to rewriting Markdown.

Instruction Scope

SKILL.md explicitly limits operations to reading and editing the top of a Markdown document (30–80 lines), adding hero blocks, badges, and navigation, and preserving original text. It does not instruct access to unrelated files, environment variables, or external endpoints.

Install Mechanism

No install spec and no code files — nothing will be downloaded or written during install. This is the lowest-risk model for a skill of this kind.

Credentials

No environment variables, credentials, or config paths are requested. The declared requirements are proportional to the stated purpose.

Persistence & Privilege

The skill is not marked always:true. agents/openai.yaml sets policy.allow_implicit_invocation: true, which permits autonomous invocation by the agent; this is a normal default but increases blast radius compared with a purely user-invoked skill.

Assessment

This skill is internally consistent and limited to editing README/Markdown content. Before using it: run it on a copy or branch so you can review diffs; do not provide any files or screenshots that contain secrets; verify any automated edits before committing; if you prefer only manual runs, disable or remove implicit/autonomous invocation in your agent config. If you need stronger guarantees, ask for a dry-run output (proposed Markdown) rather than an automatic write. If the skill is from an unknown publisher and will be used widely across repos, consider auditing produced changes or restricting it to trusted repositories.

A weak README explains itself. A strong README arrives with presence.

This skill exists for pages that already have a voice, a strong sentence, or a real idea, but still look like raw Markdown instead of a deliberate front page.

Use this skill when the user wants a README, skill page, or landing-style Markdown document to feel more like a designed front page:

• GitHub README beautification
• ClawHub skill page polish
• hero-section redesign
• quote + badge + navigation layout
• preserving a strong original intro while improving presentation
• upgrading the front page of a Chinese-first README
• making a skill page feel more like a product showcase
• preserving the strongest original line while redesigning only the first screen

Do not use this skill for generic copywriting, long-form documentation editing, or full website implementation unless the user specifically wants the document itself restyled.

Core Promise

Do not delete the soul of the page.

Your job is not to replace the author's best line with decorative polish. Your job is to:

1. identify the best existing line, quote, or paragraph
2. elevate it into a stronger first screen
3. preserve the original substance underneath
4. make the page feel intentional, clean, and memorable

This skill should sharpen the entrance, not erase the voice.

Default Workflow

1. Read the top of the document first

Inspect the first 30-80 lines before editing.

Look for:

• the strongest quote-worthy sentence
• the real title
• whether the page is bilingual
• whether the page already has useful sections worth linking to
• whether the current top is dry, cluttered, or visually weak

2. Decide the hero structure

Prefer this top-level structure when suitable:

<div align="center">

# Title

> Strong quote or distilled line

![badge](...)
![badge](...)

<p align="center">
  horizontal navigation
</p>

<p align="center">
  short subtitle or two-line promise
</p>

</div>

---

Use it only if it improves the page. Do not force it onto documents that need a plain technical opening.

3. Preserve the original introduction

After the hero block:

• keep the original opening material if it has literary force or brand value
• trim only duplication introduced by the new hero
• do not flatten expressive copy into bland product language

If the author already wrote a powerful intro, keep it alive.

4. Add badges with restraint

Badges should signal structure, not become confetti.

Good uses:

• bilingual
• mode or category
• platform
• output style
• standard / workflow type

Bad uses:

• five badges that all say the same thing
• random rainbow clutter
• fake technical authority

Default range: 3-5 badges.

Prefer flat-square style unless the repo already uses something else.

5. Make navigation horizontal and useful

If the page is long enough to justify navigation:

• add a centered horizontal link row near the top
• link only to real high-value sections
• create stable anchor ids when necessary

Good examples:

• Chinese / English
• Install
• Usage
• Examples
• Prompt
• Output

Do not add navigation if the document is too short to need it.

6. Use renderer-safe HTML only

Prefer Markdown plus minimal HTML that renders well in GitHub-like surfaces:

• <div align="center">
• <p align="center">
• <br />
• <a id="..."></a>

Avoid:

• inline CSS
• scripts
• complex tables for decoration
• fragile HTML tricks that break on GitHub or ClawHub

7. Respect bilingual logic

If the page is bilingual:

• keep the language order the user wants
• keep heading patterns consistent
• do not mix languages randomly inside one line unless the document already uses that style intentionally

If the user wants Chinese-first, keep Chinese-first. If the user wants English-first, keep English-first.

For Chinese-facing pages:

• prefer Chinese-first copy and navigation labels unless the user explicitly wants English-first
• preserve literary Chinese phrasing when it carries brand value
• do not flatten vivid Chinese introductions into stiff product prose
• keep the page readable to Chinese users before making it impressive to everyone else

Editing Principles

• Favor visual hierarchy over more words
• Favor one strong quote over three weak slogans
• Favor one clean hero over many decorative gimmicks
• Preserve the strongest original copy
• Keep the first screen readable in raw Markdown and rendered view
• Make the page look designed, not overdesigned

Output Rules

When you edit:

• keep the page functional as Markdown
• keep links and anchors valid
• keep section order logical
• keep existing meaning intact unless the user asks for copy changes
• explain briefly what you changed and why

If the user asks for a specific style reference:

• mirror the layout principles
• do not plagiarize exact wording
• adapt the style to the user's own content and voice

Typical Requests That Should Trigger This Skill

• "Make my README look like a landing page"
• "Why does their README look so much better than mine?"
• "Add a centered title, badges, and navigation"
• "Keep my intro, but make the top prettier"
• "Turn this skill page into a poster-style cover"
• "Make this GitHub / ClawHub page feel more premium"
• "Rework my GitHub README into this kind of front-page layout"
• "Keep the original introduction, but make the top feel more premium"
• "Use this screenshot as the reference and turn my skill page into a showcase-style page"