repo-visuals

Name: repo-visuals
Author: livlign

18stars1forks

How to install repo-visuals?

livlign/claude-skills/repo-visuals

$npx -y skills add livlign/claude-skills --skill repo-visuals

Installs into the current project.

Summary

Create hero visuals — animated GIF, static PNG, or animated SVG — for GitHub repositories. Runs a structured discovery conversation (scan repo → recommend format → propose creative scenarios → agree on a brief), then designs bespoke HTML/SVG, previews it in the browser, and expor

Files · 1

View on GitHub

SKILL.md

1	# repo-visuals
2
3	Turn a repo (GitHub URL, local folder, or free-text brief) into a hero visual that a viewer sees at the top of the README and instantly understands what this project does and why it's interesting. The hero may be an animated GIF, a static PNG, or an animated SVG — the skill recommends one based on the repo's identity, the user picks.
4
5	The skill's quality comes from the discovery dialog, not from templates. Every hero is bespoke.
6
7	## Phases
8
9	1. Discovery — pick operating mode (Auto / Semi-auto / Manual, §1.1a), scan the repo, summarize findings, recommend a format (animated vs static), ask about vibe/audience/hero moment, propose 2–3 scenarios, converge on a brief. Then Gate A — brief vs README (§1.8): narrow repo-context check on the brief before any pixels exist. The mode controls how many of these the user answers vs. Claude decides silently — it does not skip any of the craft checks.
10	2. Build — write HTML/CSS/JS for the chosen scenario. For static, design one decisive frame; for animated, a loop. No storyboard step. Then Gate B — rendered HTML vs README (§2.6): sample keyframes from the HTML, check what's on screen against the repo's own positioning, allow 1 auto-iteration if it fails. Both gates are deliberately narrow — only repo-context fidelity, not aesthetics or craft.
11	3. Preview & iterate — open the HTML in the user's default browser, iterate in text until the user says ship.
12	4. Export — animated GIF → Puppeteer screencast + ffmpeg palette pipeline. Static PNG → Puppeteer `page.screenshot` (with `deviceScaleFactor: 2` for retina crispness). Animated SVG → author the SVG directly (CSS `@keyframes` or SMIL `<animate>` inside the file); no rasterization step — the source is the artifact.
13	5. Output — place the hero in the target repo; optionally open a PR that embeds it in the README.
14
15	Dev mode (author-only): Phase 6 — Evaluate exists but only runs in dev mode. Dev mode is for the skill's author iterating on the skill itself; it collects scorecard data and writes run logs under `./evaluations/` in the user's current working directory. Enable it only when the user explicitly says "dev mode" (or sets `REPO_VISUALS_DEV=1`). In every normal run — including Manual, Semi-auto, and Auto — the skill ends after Phase 5. Do not mention Phase 6 to end users.
16
17	---
18
19	## Phase 1 — Discovery
20
21	Discovery runs before any HTML is written. Its job: go from a vague ask ("make a hero GIF for my repo") to a specific, committed creative brief.
22
23	### 1.1 Activation
24
25	Enter discovery mode whenever the user invokes the skill, unless they explicitly say "skip discovery, I have the brief ready."
26
27	### 1.1a Operating mode (ask first, once per run)
28
29	Before anything else — before the scan summary, before any direction questions — ask the user which operating mode they want for this run. Use the `AskUserQuestion` tool so the choice is structured and visible, not buried in free text. Offer three modes; describe each in concrete terms (what gets asked, what gets decided silently) and include pros/cons so the user can pick with open eyes. Default recommendation: Semi-auto.
30
31	> Note: this "operating mode" is a skill-level concept about how many questions the skill asks. It is distinct from the Claude Code harness's own auto-mode; the two do not replace each other.
32
33	Verbatim `AskUserQuestion` shape (Run mode header, three labeled options with pros/cons): `craft/snippets/operating-mode-question.md`. Paste as-is; option text is load-bearing.
34
35	Rules that apply to every mode regardless of choice (craft non-negotiables):
36
37	- §1.3 inventory count is always collected. Auto/semi don't skip it.
38	- §4.0 scope-match rule is always enforced. If the hero says "all" or shows a grid, on-screen reality must match the real inventory — regardless of mode.
39	- §1.8 Gate A and §1.8b Gate B are always run on the brief. Gate A covers repo-fidelity, Gate B covers aesthetic-identity match and the wow check. Auto/semi don't skip them before writing HTML.
40	- §3.0a / §4.4a render self-critique is always run. Every rendered HTML preview screenshot and every exported PNG/GIF gets read and bullet-critiqued before being shown to the user. The user is not the QA pass.
41	- Any mode can be upgraded mid-run. If Auto drifts, user can say "stop, switch to semi" and we resume from the nearest decision point. Do not silently re-ask everything;

People who liked this also viewed

6 picks

Type

repo-visuals

18stars1forks

View on GitHub

How to install repo-visuals?

livlign/claude-skills/repo-visuals

$npx -y skills add livlign/claude-skills --skill repo-visuals

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# repo-visuals
2
3	Turn a repo (GitHub URL, local folder, or free-text brief) into a hero visual that a viewer sees at the top of the README and instantly understands what this project does and why it's interesting. The hero may be an animated GIF, a static PNG, or an animated SVG — the skill recommends one based on the repo's identity, the user picks.
4
5	The skill's quality comes from the discovery dialog, not from templates. Every hero is bespoke.
6
7	## Phases
8
9	1. Discovery — pick operating mode (Auto / Semi-auto / Manual, §1.1a), scan the repo, summarize findings, recommend a format (animated vs static), ask about vibe/audience/hero moment, propose 2–3 scenarios, converge on a brief. Then Gate A — brief vs README (§1.8): narrow repo-context check on the brief before any pixels exist. The mode controls how many of these the user answers vs. Claude decides silently — it does not skip any of the craft checks.
10	2. Build — write HTML/CSS/JS for the chosen scenario. For static, design one decisive frame; for animated, a loop. No storyboard step. Then Gate B — rendered HTML vs README (§2.6): sample keyframes from the HTML, check what's on screen against the repo's own positioning, allow 1 auto-iteration if it fails. Both gates are deliberately narrow — only repo-context fidelity, not aesthetics or craft.
11	3. Preview & iterate — open the HTML in the user's default browser, iterate in text until the user says ship.
12	4. Export — animated GIF → Puppeteer screencast + ffmpeg palette pipeline. Static PNG → Puppeteer `page.screenshot` (with `deviceScaleFactor: 2` for retina crispness). Animated SVG → author the SVG directly (CSS `@keyframes` or SMIL `<animate>` inside the file); no rasterization step — the source is the artifact.
13	5. Output — place the hero in the target repo; optionally open a PR that embeds it in the README.
14
15	Dev mode (author-only): Phase 6 — Evaluate exists but only runs in dev mode. Dev mode is for the skill's author iterating on the skill itself; it collects scorecard data and writes run logs under `./evaluations/` in the user's current working directory. Enable it only when the user explicitly says "dev mode" (or sets `REPO_VISUALS_DEV=1`). In every normal run — including Manual, Semi-auto, and Auto — the skill ends after Phase 5. Do not mention Phase 6 to end users.
16
17	---
18
19	## Phase 1 — Discovery
20
21	Discovery runs before any HTML is written. Its job: go from a vague ask ("make a hero GIF for my repo") to a specific, committed creative brief.
22
23	### 1.1 Activation
24
25	Enter discovery mode whenever the user invokes the skill, unless they explicitly say "skip discovery, I have the brief ready."
26
27	### 1.1a Operating mode (ask first, once per run)
28
29	Before anything else — before the scan summary, before any direction questions — ask the user which operating mode they want for this run. Use the `AskUserQuestion` tool so the choice is structured and visible, not buried in free text. Offer three modes; describe each in concrete terms (what gets asked, what gets decided silently) and include pros/cons so the user can pick with open eyes. Default recommendation: Semi-auto.
30
31	> Note: this "operating mode" is a skill-level concept about how many questions the skill asks. It is distinct from the Claude Code harness's own auto-mode; the two do not replace each other.
32
33	Verbatim `AskUserQuestion` shape (Run mode header, three labeled options with pros/cons): `craft/snippets/operating-mode-question.md`. Paste as-is; option text is load-bearing.
34
35	Rules that apply to every mode regardless of choice (craft non-negotiables):
36
37	- §1.3 inventory count is always collected. Auto/semi don't skip it.
38	- §4.0 scope-match rule is always enforced. If the hero says "all" or shows a grid, on-screen reality must match the real inventory — regardless of mode.
39	- §1.8 Gate A and §1.8b Gate B are always run on the brief. Gate A covers repo-fidelity, Gate B covers aesthetic-identity match and the wow check. Auto/semi don't skip them before writing HTML.
40	- §3.0a / §4.4a render self-critique is always run. Every rendered HTML preview screenshot and every exported PNG/GIF gets read and bullet-critiqued before being shown to the user. The user is not the QA pass.
41	- Any mode can be upgraded mid-run. If Auto drifts, user can say "stop, switch to semi" and we resume from the nearest decision point. Do not silently re-ask everything;

People who liked this also viewed

6 picks

Type