skills/product/visual-direction/SKILL.md
Figure out what a section of content *should be* visually before reaching for any implementation pattern. Answers five structured questions — content structure, audience mental model, desired action, physical artifact metaphor, and the stupid-question test — then produces a one-paragraph visual brief for the implementer. Use when: designing a new section, evaluating a proposed visual treatment, or catching the nearest-neighbor trap (copying the adjacent project's pattern without asking if it fits). NOT for: accessibility audits (use product:a11y), visual consistency review (use product:ux-review), or wireframing (use product:mockup).
npx skillsauth add mikeparcewski/wicked-garden wicked-garden-product-visual-directionInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Reason from content structure to visual form — not from available patterns to first fit.
The nearest-neighbor trap: when Project B is being designed and Project A nearby used a pattern that worked (sidebar + sticky stage + crawling tick), the agent reaches for that pattern without asking whether Project B's content warrants it. A pattern that was right for A's content may be actively wrong for B's.
Real example: A marketing site redesign for wicked-garden kept applying the wicked-interactive conveyor pattern (sticky stage, left sidebar ledger, yellow tick) to sections where it didn't fit. The "No cloud / No black box" refusals are philosophical statements — they want to be big typographic text, not a scroll-pinned station list. The tools section is a pipeline — it wants to be a session log showing the system working, not a sidebar tour. It took three rounds of user pushback before the agent stopped copying and started reasoning from the content itself.
Not "what should it look like" — what is its intrinsic structure?
| Content type | Examples | |---|---| | Timeline | Steps, stages, history, before/after | | Principles / manifesto | Philosophical statements, refusals, beliefs | | Pipeline | Tools in sequence, data flow, system working | | Comparison | Options side by side, trade-offs | | Catalog | Items browsed, filtered, selected | | Narrative | A story with a beginning, tension, resolution | | Metric / dashboard | Numbers, status, health |
Name the type before doing anything else.
Match the metaphor to their mental model, not yours.
| Audience | Natural mental models | |---|---| | Developers | Logs, diffs, terminal output, config files | | Executives | Dashboards, summaries, traffic lights | | Designers | Grids, layers, component libraries | | End users | Shopping, browsing, reading | | Ops / SRE | Alerts, runbooks, timelines |
If the proposed visual form would feel alien to the intended audience, it's wrong.
The visual treatment — including motion — should serve the action, not decorate the section.
| Desired action | Visual implication | |---|---| | Trust it | Calm, credible, evidence-based — not flashy | | Install it | Clear path, no obstacles, quick scan | | Understand it | Progressive disclosure, not all at once | | Feel it | Emotion first, detail second | | Choose it | Comparison-friendly, scannable differences |
Animation that doesn't serve the desired action is noise.
Bypass the pattern library entirely. Name the physical object.
Examples: a receipt, a log printout, a map, a library shelf, a garden, a contract, a command-line session, a newspaper front page, a sticky note wall, a timeline on a wall, a warning label.
The physical artifact test often surfaces the right visual form faster than any pattern catalog.
Would presenting this content in the proposed form feel obviously wrong to someone who just read it carefully?
Run the test explicitly: "If someone read all of [content] and then saw it rendered as [proposed form], would they laugh or wince?"
Examples of failing the stupid-question test:
After answering all five questions, produce a one-paragraph visual brief in this form:
Visual Brief — [Section Name]
Content type: [name from Q1]. Audience mental model: [from Q2]. The section wants the
user to [action from Q3]. Physical artifact: [from Q4]. Proposed treatment: [one sentence
on form + motion]. Nearest-neighbor risk: [name the pattern being avoided and why it
doesn't fit]. Animation role: [one sentence on what motion does or "no animation — the
content is static"].
This brief is the handoff to the implementer. Do not skip to implementation without it.
product:mockup for a wireframe, or
directly to an implementer with the brief as the spec.product:ux to establish user flows, or product:strategy to
establish what the section is trying to accomplish.development
Pattern-conformance agent-half: evaluates a produced artifact or diff against a set of architectural/design pattern rules from the conformance-rule store (wicked_governance schema). Returns structured findings with rule ID, severity, and rationale — the deterministic half (mechanical rule recall) is done by the guard pipeline; this is the semantic evaluation step. Triggered by: the guard_pipeline `outgov_pattern` check (session-close), or explicitly by an engineering review when WICKED_OUTGOV_RULES_DIR is populated. NOT a replacement for the full `engineering` review skill — focuses only on conformance to stored Pattern rules; architecture and code-quality checks live in the `engineering` skill. Semantic evaluation reuses `wicked-garden-qe-semantic-reviewer` as the designated agent-half evaluator (per garden#983 spec). This skill is the orchestrating wrapper that loads applicable Pattern rules and delegates the per-rule semantic judgment to qe-semantic-reviewer.
tools
The FOUNDATIONAL domain-model capability: extract a codebase's domain — testable business rules (with confidence + provenance), entities, requirements — as a schema-conformant model on the estate graph. The workers annotate the store; wicked-core reads it and builds the requirements graph, coverage-gating fail-closed. Steers three fork workers. A shared substrate, not a modernization tool. The `modernize` archetype DERIVES from it; build / migrate / review / specify / explore consume the SAME domain model — none OWN it. Understanding a codebase's domain is upstream of almost everything else garden does. Use when: "extract the business rules / domain model from this codebase", "build a requirements graph from the code", "what does this system actually require", "reverse-engineer the domain before we build/port/migrate". Works on ANY codebase (modern or legacy) — the value is the domain model, not the porting. NOT the code transform itself (that is the archetype consuming this model). This skill produces the DOMAIN MODEL, not new code.
development
Domain-graph fork worker for the modernize archetype. Groups the estate's Louvain communities into business domains, attaches each requirement to its cluster (advisory cluster_id provenance), and invokes wicked-core's domain-graph build (which reads the annotated estate store, recomputes coverage fail-closed, and builds the requirements graph) — then validates core's output against the vendored schema. Use when: dispatched by wicked-garden-domain after rule extraction to turn a flat rule set into cluster-keyed domains; "group these into domains", "build the requirements graph", "translate clusters into a domain model". NOT for mining the rules themselves (that is domain-extractor) or threat-modeling (that is domain-coverage).
tools
Rule-extraction fork worker for the FOUNDATIONAL domain-model capability. Mines testable business rules from a codebase — each with a numeric confidence and a provenance{source, ref, source_kinds} — and annotates them into the estate store so wicked-core can build the domain-model requirements graph (coverage-gated). This is a substrate, not a modernization tool: the `modernize` archetype DERIVES from it, and build / migrate / review / specify / explore can consume the same domain model — none OWN it. Use when: dispatched by wicked-garden-domain to mine the business_rules of a codebase (or a module); "extract the domain rules", "what does this system require", building the requirements half of a domain model. NOT for grouping into domains (that is domain-modeler) or judging coverage (that is domain-coverage — a seat-distinct evaluator).