Menu
Le prompt qui vérifie d'abord la source est sélectionné par défaut. Vous pouvez passer à une commande directe ou télécharger une copie locale.
Lisez SKILL.md et les fichiers associés affichés par SkillsMP avant de décider de l'installer.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Une commande directe contourne le prompt de vérification. Examinez la source avant de l'exécuter.
npx skills add https://github.com/dabit3/sonic-agent --skill sketchLa commande reste sur une seule ligne. Faites défiler horizontalement pour la vérifier avant de la copier.
Vous préférez une copie locale ? Téléchargez les fichiers actuellement disponibles dans SkillsMP.
Delegate coding to OpenHands CLI (model-agnostic, LiteLLM).
Authorized web application penetration testing — reconnaissance, vulnerability analysis, proof-based exploitation, and professional reporting. Adapts Shannon's "No Exploit, No Report" methodology with hard guardrails for scope, authorization, and aux-client leakage. Active testing against running applications you own or have written authorization to test.
Generate wiki docs + Mermaid diagrams for any codebase.
Affichage de SKILL.md
Basé sur la classification professionnelle SOC
| name | sketch |
| description | Throwaway HTML mockups: 2-3 design variants to compare. |
| version | 1.0.0 |
| author | Sonic Agent (adapted from gsd-build/get-shit-done) |
| license | MIT |
| platforms | ["linux","macos","windows"] |
| metadata | {"sonic":{"tags":["sketch","mockup","design","ui","prototype","html","variants","exploration","wireframe","comparison"],"related_skills":["spike","claude-design","popular-web-designs","excalidraw"]}} |
Use this skill when the user wants to see a design direction before committing to one — exploring a UI/UX idea as disposable HTML mockups. The point is to generate 2-3 interactive variants so the user can compare visual directions side-by-side, not to produce shippable code.
Load this when the user says things like "sketch this screen", "show me what X could look like", "compare layout A vs B", "give me 2-3 takes on this UI", "let me see some variants", "mockup this before I build".
claude-design or build it properlyclaude-designexcalidraw, architecture-diagramIf gsd-sketch shows up as a sibling skill (installed via npx get-shit-done-cc --sonic), prefer gsd-sketch for the full workflow: persistent .planning/sketches/ with MANIFEST, frontier mode analysis, consistency audits across past sketches, and integration with the rest of GSD. This skill is the lightweight standalone version — one-off sketching without the state machinery.
intake → variants → head-to-head → pick winner (or iterate)
Before generating variants, get three things — one question at a time, not all at once:
Reflect each answer briefly before the next question. If the user already gave you all three upfront, skip straight to variants.
Produce 2-3 variants in one go. Each variant is a complete, standalone HTML file. Don't describe variants — build them. The point is comparison.
Each variant should take a different design stance, not different pixel values. Three good variant axes:
Pick one axis and pull apart from it. Two variants that differ only in accent color are wasted effort — the user can't distinguish them.
Variant naming: describe the stance, not the number.
sketches/
├── 001-calm-editorial/
│ ├── index.html
│ └── README.md
├── 001-utilitarian-dense/
│ ├── index.html
│ └── README.md
└── 001-playful-split/
├── index.html
└── README.md
Each variant is a single self-contained HTML file:
<style> — no build step, no external CSS<link><script src="https://cdn.tailwindcss.com"></script>) is fineOpen it in a browser. If it looks broken, fix it before showing the user.
Verify variants visually — use Sonic' browser tools. Don't just write HTML and hope it renders; load each variant and look at it:
browser_navigate(url="file:///absolute/path/to/sketches/001-calm-editorial/index.html")
browser_vision(question="Does this layout look clean and readable? Any visible bugs (overlapping text, unstyled elements, broken images)?")
browser_vision returns an AI description of what's actually on the page plus a screenshot path — catches layout bugs that pure source inspection misses (e.g. a font import that silently failed, a flex container that collapsed). Fix and re-navigate until each variant looks right.
Default CSS reset + system font stack for fast starts:
<style>
* { box-sizing: border-box; margin: 0; padding: 0; }
body {
font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto,
"Helvetica Neue", Arial, sans-serif;
-webkit-font-smoothing: antialiased;
color: #1a1a1a;
background: #fafafa;
line-height: 1.5;
}
</style>
Each variant's README.md answers:
## Variant: {stance name}
### Design stance
One sentence on the principle driving this variant.
### Key choices
- Layout: ...
- Typography: ...
- Color: ...
- Interaction: ...
### Trade-offs
- Strong at: ...
- Weak at: ...
### Best for
- The kind of user or use case this variant actually serves
After all variants are built, present them as a comparison. Don't just list — opinionate:
## Three takes on the home screen
| Dimension | Calm editorial | Utilitarian dense | Playful split |
|-----------|----------------|-------------------|---------------|
| Density | Low | High | Medium |
| Primary action visibility | Low | High | Medium |
| Scan-ability | High | Medium | Low |
| Feel | Calm, trusted | Sharp, tool-like | Inviting, energetic |
**My take:** Utilitarian dense for power users, calm editorial for content-forward audiences. Playful split is weakest — tries to do both and commits to neither.
Let the user pick a winner, or combine two into a hybrid, or ask for another round.
If the user has an existing theme (colors, fonts, tokens), put shared tokens in sketches/themes/tokens.css and @import them in each variant. Keep tokens minimal:
/* sketches/themes/tokens.css */
:root {
--color-bg: #fafafa;
--color-fg: #1a1a1a;
--color-accent: #0066ff;
--color-muted: #666;
--radius: 8px;
--font-display: "Inter", sans-serif;
--font-body: -apple-system, BlinkMacSystemFont, sans-serif;
}
Don't over-tokenize a throwaway sketch — three colors and one font is usually enough.
A sketch is interactive enough when the user can:
More than that is over-engineering a throwaway. Less than that is a screenshot.
If sketches already exist and the user says "what should I sketch next?":
Propose 2-4 named candidates. Let the user pick.
sketches/ (or .planning/sketches/ if the user is using GSD conventions) in the repo rootNNN-stance-name/index.html + README.mdopen sketches/001-calm-editorial/index.html on macOS, xdg-open on Linux, start on WindowsTypical tool sequence for one variant:
terminal("mkdir -p sketches/001-calm-editorial")
write_file("sketches/001-calm-editorial/index.html", "<!doctype html>...")
write_file("sketches/001-calm-editorial/README.md", "## Variant: Calm editorial\n...")
browser_navigate(url="file://$(pwd)/sketches/001-calm-editorial/index.html")
browser_vision(question="How does this look? Any obvious layout issues?")
Repeat for each variant, then present the comparison table.
Adapted from the GSD (Get Shit Done) project's /gsd-sketch workflow — MIT © 2025 Lex Christopherson (gsd-build/get-shit-done). The full GSD system ships persistent sketch state, theme/variant pattern references, and consistency-audit workflows; install with npx get-shit-done-cc --sonic --global.