repo-visuals
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 exports. Use when the user asks for a README hero, repo banner, README image, GitHub header, social preview card, repo demo GIF, hero image, OG image, project screenshot, repository showcase, or any "image at the top of the README".
62
73%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Critical
Do not install without reviewing
Optimize this skill with Tessl
npx tessl skill review --optimize ./plugins/repo-visuals/skills/repo-visuals/SKILL.mdQuality
Discovery
100%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is an excellent skill description that clearly articulates specific capabilities (format options, structured workflow from discovery to export), provides comprehensive trigger terms covering many natural user phrasings, and occupies a well-defined niche. It uses proper third-person voice throughout and balances detail with readability.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Lists multiple specific concrete actions: create hero visuals (animated GIF, static PNG, animated SVG), runs a structured discovery conversation (scan repo, recommend format, propose creative scenarios, agree on a brief), designs bespoke HTML/SVG, previews in browser, and exports. | 3 / 3 |
Completeness | Clearly answers both 'what' (create hero visuals with a structured discovery-to-export workflow) and 'when' (explicit 'Use when...' clause listing numerous trigger scenarios). | 3 / 3 |
Trigger Term Quality | Excellent coverage of natural terms users would say: 'README hero', 'repo banner', 'README image', 'GitHub header', 'social preview card', 'repo demo GIF', 'hero image', 'OG image', 'project screenshot', 'repository showcase', and the very natural phrase 'image at the top of the README'. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive niche — GitHub repository hero visuals with specific output formats (GIF, PNG, SVG) and a defined workflow. The trigger terms are tightly scoped to repo/README imagery, making conflicts with other skills unlikely. | 3 / 3 |
Total | 12 / 12 Passed |
Implementation
47%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is an extraordinarily thorough skill with excellent workflow clarity — the phased structure, explicit gates, validation checkpoints, and mode-aware behavior tables represent best-in-class process design. However, the skill is severely undermined by its verbosity: it reads more like an internal design document with incident post-mortems than a concise instruction set, and much of the inline detail (gate rationale, past failure stories, design philosophy) should live in the referenced craft/ files rather than the main SKILL.md. The actionability is moderate — strong on process and critique prompts but light on executable code for the core build step.
Suggestions
Move incident write-ups, design rationale paragraphs, and 'why' explanations (e.g., 'Why one retry, not many', 'Why on HTML, not the exported artifact') into craft/rules.md or a new craft/design-decisions.md — the SKILL.md should state the rule, not argue for it.
Compress the gate critique prompts into a referenced file (e.g., craft/gates.md) and keep only a 2-3 line summary of each gate's purpose and pass/fail criteria inline.
Add a concrete, minimal working example of index.html structure in §2.3 — even a 30-line skeleton with the stage container, one scene function, and the timeline object would make the build phase far more actionable.
Restructure the SKILL.md as a true overview (~200-300 lines) with phase summaries and clear pointers to craft/ files for details, rather than inlining the full specification of every sub-step.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Extremely verbose — the content runs thousands of lines with extensive incident write-ups, repeated explanations of gate logic across modes, and lengthy rationale paragraphs that explain design decisions Claude doesn't need (e.g., why one retry not many, why Gate B scope is narrow). Much of this could be compressed to tables or terse rules without losing actionability. | 1 / 3 |
Actionability | Provides concrete commands (ffmpeg frame extraction, browser open commands, directory layouts) and specific gate critique prompts that are copy-paste ready. However, the core build phase lacks executable code examples — the HTML structure description in §2.3 is architectural guidance rather than a working template, and key pipelines are deferred to external files (craft/export.md, craft/ship.md) without inline fallbacks. | 2 / 3 |
Workflow Clarity | The 6-phase workflow is clearly sequenced with explicit gates (Gate A, Gate B), validation checkpoints (§2.6 rendered HTML check, §3.0a render self-critique, §4.4a post-export critique), feedback loops (fail → fix → re-validate, limited to one retry with clear rationale), checklists (§1.6 convergence signal), and mode-specific behavior tables. The workflow handles error recovery and destructive operations carefully. | 3 / 3 |
Progressive Disclosure | References to external files are well-signaled and one-level deep (craft/headlines.md, craft/export.md, craft/rules.md, craft/ship.md, craft/evaluate.md, craft/reference-gallery.md, craft/redesign.md, craft/svg-animation.md). However, the SKILL.md itself is monolithic — enormous amounts of detail that belong in those referenced files are inlined here (full gate critique prompts, detailed layout rules, incident write-ups, mode behavior tables), making the main file a wall of text rather than a navigable overview. | 2 / 3 |
Total | 8 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
skill_md_line_count | SKILL.md is long (580 lines); consider splitting into references/ and linking | Warning |
Total | 10 / 11 Passed | |
- Repository
- livlign/claude-skills
- Commit
7f66ce9
- Reviewed
Table of Contents
Is this your skill?
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.