taste — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited taste (Agent Skill) and scored it 96/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 1 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 1 flagged
The text {match} tells the agent to skip the normal "ask the user first" gate. Used adversarially it removes the human-in-the-loop check before destructive or sensitive actions, turning a normally-gated agent into a fire-and-forget executor.
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Taste is domain-grounded judgment applied during creation. It is not a polish pass and not a slop-removal checklist. It is the difference between output that is merely competent and output that reflects an actual understanding of what practitioners in a field consider good.
The failure mode this skill corrects is straightforward: agents produce work that is technically complete but obviously generated. The information may be correct, but the judgment is absent. Equal weight goes to unequal ideas. Structure appears because templates exist, not because the content needs it. Details stay in because they were available, not because they matter.
This skill fixes that by requiring you to understand the domain before you touch the work.
Before creating anything, establish a domain model. The depth required depends on how far the domain is from your reliable knowledge.
If you know the domain cold:
If you know the domain but not the current state:
If the domain is unfamiliar or specialized:
The grounding step should produce three things:
Skip grounding only when the domain is obvious and you are certain. When uncertain, ground.
The first judgment is what to leave out. This is only possible if you understand the function of the material you're cutting. Taste without domain knowledge is just confidence.
Nothing is included by default. Not a section header, not an abstraction, not a paragraph, not a color choice. Each element must answer: what does this do for the person encountering the work?
The exception is when the convention itself carries meaning. Standard README sections, established visual hierarchy, or a familiar API shape can earn their place because the audience relies on them.
Every created artifact has a controlling idea: the real job of a function, the actual argument of a document, the primary action of a design. Find it and orient everything around it.
If you cannot identify the spine, the work is not ready to be built.
A concrete detail grounded in the domain beats an elegant abstraction. Name the real thing. Use the actual number. Reference the specific constraint. Sophistication without anchoring is decoration.
Each domain has a native way of communicating. API docs, pitch decks, commit messages, design critiques, and internal memos do not sound alike. The right register is about signal versus noise, not about formality.
Overfinishing is a taste failure. Past the point where extra work improves the receiver's experience, you are serving your own anxiety rather than the work.
Determine what good means in this exact context. For common creation domains, load the relevant section from references/DOMAIN_MODES.md, but treat it as a starting point rather than a substitute for actual domain knowledge.
Before creating, establish:
If you cannot answer those questions, research or ask before creating.
Build from the spine outward. Apply the domain model at every decision point: inclusion, structure, level of detail, and register.
This is not create first and edit later. The filter is active during creation.
After the first pass, remove:
Read the work back. Is the controlling idea clear? Does every element support it or get out of its way? If the spine is muddy, something is competing.
Check the result against the quality bar from grounding. Do not ask whether it is maximally polished. Ask whether it is finished at the right level for the context.
Load only what the task needs.
references/DOMAIN_MODES.md: Creation-specific guidance for code, visual design, documents, data artifacts, and system design.references/ANTI_PATTERNS.md: Common ways agents fake taste during creation.references/EVALUATION.md: Rubric for high-bar self-checks.~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.