Pr1m4lc0d3
UserAdjectives are how slop is made, not how it is cured. A Claude Code skill for image and animation prompts: name the subject, fix the light, restrict the medium, say what it is not.
Categories
Indexed Skills (13)
ekphrasis
Use when writing prompts for an image or animation generator — cover art, hero images, podcast covers, product renders, stop-motion sheets, thumbnails, or any request phrased as "generate an image", "make artwork", "create a cover", "an image prompt for ChatGPT/Codex/Flux/Midjourney/DALL-E", or when generated art comes back looking glossy, generic, or obviously AI. Also use when animation frames jitter or refuse to hold a consistent subject. This is prompt AUTHORSHIP, not image editing — for producing and optimising image files see `image`, for ad specs see `ad-creative`, for video see `hyperframes`.
paraphrasis
Use when saying the same thing to a different audience — restating, re-voicing, translating for a new reader, shortening, expanding, or adapting a message for a developer, a buyer, an executive, a beginner, a skeptic, or a hostile reader. Also use when compressing to a word count, writing a summary or TL;DR, turning a spec into an announcement, a changelog into a release note, a paper into a post, or one channel's copy into another's. Carries the drift catalog, the fidelity ledger, and the reversal test. Not for improving prose in place — that is peitho. Not for rendering audio into text — that is metaphrasis.
metaphrasis
Read audio you cannot hear — music libraries and narrated video alike. Use when choosing background music, checking whether a track sits under a voiceover, triaging a folder of music, finding where a track can be cut, splicing sections from several tracks into one piece that changes tone by topic, or QA-ing a narrated marketing video (transcript, pacing, dead air, and whether the music is burying the voice). Also use when asked what a track sounds like, its tempo, key, loudness, or structure, or what a video says.
kiss-blast-radius
Use before editing, refactoring, moving, or deleting existing code — to keep the change contained to its bounded unit and prevent collateral damage to surrounding services and functions. Use whenever a change touches a file other code depends on, or whenever a refactor could ripple beyond the thing you were asked to change.
kiss-coherence
Use when auditing or changing a system where the same concept is derived in more than one place - enforces one canonical accessor per concept ("one question, one answer"), catching cross-cutting duplication that file-size and modularity audits structurally cannot see.
kiss-debt-guard
Use when a repo needs an enforceable size/debt control rather than advice — installs a light, dependency-free size-budget audit script plus a config, and points to heavier guards (dead-code, duplicate-surface, test-debt, dependency-risk, doc-drift) when a repo warrants them. Use during KISS kickoff, or when files keep drifting over budget despite good intentions.
kiss-map
Use before editing or creating code, to find where something is, whether it exists at all, or whether a twin/duplicate already exists — cheaply and without guessing. Use instead of grepping or reading the whole codebase, and whenever you are tempted to assume a function's existence or location.
kiss-plan
Use before writing code for any multi-step task, feature, or new project — orient inside the existing structure first, then turn the request into a short design doc with explicit modules, interfaces, and a verify-stepped build sequence. Use when a task is ambiguous, spans more than one file, or has more than one reasonable interpretation.
kiss-readable
Use when writing or laying out code so a human and an AI can read it, navigate it, and lift pieces out of it cleanly. Covers bounded labeled sections, intent-summaries on non-trivial functions, why-comments on complex logic, and intention-revealing naming. Use whenever code is non-obvious or a file holds more than one section of related logic.
kiss
Use at the base of a project — when starting a new project, a sizable feature, or a fresh module, before much code exists — to set it up to stay clean, and as the entry point to the KISS discipline (plan, map, readable sections, modularity, blast-radius, debt). Use whenever you want clean-code structure established from the start rather than bolted on later.
janus
Turn a product's contradictions into its positioning. Use when a product, offer, or brand carries two opposed things that both must be true (private vs. social, premium vs. free, simple vs. powerful, subscription vs. ownership) and picking one side would kill the product. Also use when positioning reads generic and the differentiator is missing, or to audit an existing design doc for contradictions being carried unnamed. Not for architecture tradeoffs, debugging, or engineering decisions that should resolve.
no-ai-slop
Edit drafts into sharper, more human writing while preserving the writer's personal voice, or detect AI-slop patterns without rewriting. Use when the user wants a draft clearer, more direct, more opinionated, or less AI-sounding, or asks whether writing reads as AI.
kiss-changelog
Use after a change lands — a feature, a fix, or any behavior change — to record what changed and why, so humans and future-you can follow the project's evolution without reading the diff. Use before declaring a unit of work done, not in a batch at the end.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.