public-readme-polisher

Name: public-readme-polisher
Author: 100yenadmin

109stars4forks

How to install public-readme-polisher?

100yenadmin/fable-token-saving-skills-orchestrator/public-readme-polisher

$npx -y skills add 100yenadmin/fable-token-saving-skills-orchestrator --skill public-readme-polisher

Installs into the current project.

Summary

Use when improving a public README, repository homepage, docs landing page, or developer-facing first impression.

Files · 1

View on GitHub

SKILL.md

1	# Public README Polisher
2
3	Polish the README as the repo's public front door: credible, scannable,
4	actionable, and claim-safe.
5
6	## Use When
7
8	- a README feels plain
9	- a repo needs a public first impression
10	- a docs landing page needs clearer value, install path, or proof
11	- a visual asset could make the repo easier to understand
12
13	## Process
14
15	1. Audit repo truth: purpose, install path, tests, license, security, CI, docs,
16	examples, and public claim boundaries.
17	2. Define the public promise in one paragraph: who it helps, what it gives
18	them, and what it does not guarantee.
19	3. Improve the first viewport: title, optional hero, badges, concise opening,
20	quick action, and a scannable "what you get" table.
21	4. Add scanning structure: quick start, workflow diagram when useful, proof or
22	sources near the claim, and links to deeper docs.
23	5. Validate links, images, alt text, docs scan, tests, and the scorecard below.
24
25	## Visual Asset Rules
26
27	- Use one purposeful hero only when it clarifies the repo.
28	- For generated images: no embedded text, no logos, no watermarks.
29	- Inspect the image before committing; reject generated image with readable fake
30	text, broken UI, mascot drift, or misleading claims.
31	- Save README assets under `assets/readme`.
32	- Add alt text that explains the image function.
33
34	## Claim Safety
35
36	- Cite official sources for factual pricing, cache, legal, API, or security
37	claims.
38	- Say "patterns that worked for us" for experience-based recommendations.
39	- Avoid guaranteed savings, official endorsement, universal safety claims, or
40	"works for every workflow" language.
41	- Keep related tools optional unless the repo truly depends on them.
42
43	## Scorecard
44
45	Score each category 0-2. Pass at 13/16 or higher.
46
47	\| Category \| 2 means \|
48	\| --- \| --- \|
49	\| First-viewport signal \| repo purpose, visual tone, badges, and install path are clear without scrolling \|
50	\| Audience/value clarity \| reader knows who it is for and what problem it solves \|
51	\| Scannability \| tables, bullets, headings, and diagrams make scanning easy \|
52	\| Actionability \| quick start and next links are concrete and current \|
53	\| Trust/proof \| sources, CI, license, tests, and safety boundaries support the claims \|
54	\| Visual polish \| assets feel intentional, domain-fit, and not generic stock decoration \|
55	\| Accessibility/asset hygiene \| alt text, local paths, file size, and image rendering are sane \|
56	\| Claim safety \| claims are bounded, sourced where needed, and public-safe \|
57
58	Automatic blockers: private paths, secrets, broken local links, missing install
59	path, false or guaranteed claims, generated image with readable fake text,
60	missing alt text, failing docs scan.
61
62	## Common Mistakes
63
64	- Making a marketing page that hides the actual install/use path.
65	- Adding a pretty image that does not explain the repo.
66	- Moving official citations away from the claims they support.
67	- Replacing precise safety boundaries with vague hype.
68	- Claiming completion without running the scorecard.

People who liked this also viewed

6 picks

Type

public-readme-polisher

109stars4forks

View on GitHub

How to install public-readme-polisher?

100yenadmin/fable-token-saving-skills-orchestrator/public-readme-polisher

$npx -y skills add 100yenadmin/fable-token-saving-skills-orchestrator --skill public-readme-polisher

Installs into the current project.

Summary

Use when improving a public README, repository homepage, docs landing page, or developer-facing first impression.

Files · 1

View on GitHub

SKILL.md

1	# Public README Polisher
2
3	Polish the README as the repo's public front door: credible, scannable,
4	actionable, and claim-safe.
5
6	## Use When
7
8	- a README feels plain
9	- a repo needs a public first impression
10	- a docs landing page needs clearer value, install path, or proof
11	- a visual asset could make the repo easier to understand
12
13	## Process
14
15	1. Audit repo truth: purpose, install path, tests, license, security, CI, docs,
16	examples, and public claim boundaries.
17	2. Define the public promise in one paragraph: who it helps, what it gives
18	them, and what it does not guarantee.
19	3. Improve the first viewport: title, optional hero, badges, concise opening,
20	quick action, and a scannable "what you get" table.
21	4. Add scanning structure: quick start, workflow diagram when useful, proof or
22	sources near the claim, and links to deeper docs.
23	5. Validate links, images, alt text, docs scan, tests, and the scorecard below.
24
25	## Visual Asset Rules
26
27	- Use one purposeful hero only when it clarifies the repo.
28	- For generated images: no embedded text, no logos, no watermarks.
29	- Inspect the image before committing; reject generated image with readable fake
30	text, broken UI, mascot drift, or misleading claims.
31	- Save README assets under `assets/readme`.
32	- Add alt text that explains the image function.
33
34	## Claim Safety
35
36	- Cite official sources for factual pricing, cache, legal, API, or security
37	claims.
38	- Say "patterns that worked for us" for experience-based recommendations.
39	- Avoid guaranteed savings, official endorsement, universal safety claims, or
40	"works for every workflow" language.
41	- Keep related tools optional unless the repo truly depends on them.
42
43	## Scorecard
44
45	Score each category 0-2. Pass at 13/16 or higher.
46
47	\| Category \| 2 means \|
48	\| --- \| --- \|
49	\| First-viewport signal \| repo purpose, visual tone, badges, and install path are clear without scrolling \|
50	\| Audience/value clarity \| reader knows who it is for and what problem it solves \|
51	\| Scannability \| tables, bullets, headings, and diagrams make scanning easy \|
52	\| Actionability \| quick start and next links are concrete and current \|
53	\| Trust/proof \| sources, CI, license, tests, and safety boundaries support the claims \|
54	\| Visual polish \| assets feel intentional, domain-fit, and not generic stock decoration \|
55	\| Accessibility/asset hygiene \| alt text, local paths, file size, and image rendering are sane \|
56	\| Claim safety \| claims are bounded, sourced where needed, and public-safe \|
57
58	Automatic blockers: private paths, secrets, broken local links, missing install
59	path, false or guaranteed claims, generated image with readable fake text,
60	missing alt text, failing docs scan.
61
62	## Common Mistakes
63
64	- Making a marketing page that hides the actual install/use path.
65	- Adding a pretty image that does not explain the repo.
66	- Moving official citations away from the claims they support.
67	- Replacing precise safety boundaries with vague hype.
68	- Claiming completion without running the scorecard.

People who liked this also viewed

6 picks

Type