---
name: visual-director
description: "Manual visual direction for premium websites and interfaces, audiovisual pieces, and fixed graphics. Use only when the user explicitly invokes visual-director or Visual Director; do not load automatically for ordinary styling, buttons, forms, or bug fixes. Turns a brief into visual directions, a coherent visual system, a minimum sufficient production method, and a defining prototype."
compatibility: "For coding agents with project/file access. No external tool, framework, design service, browser tool, or rendering engine is mandatory: check what is already available and request authorized setup only when a real need requires it. Verify current official documentation and runtime support before committing to a technology."
metadata:
  version: "2.0.2-draft"
  opencode/autoinvoke: false
---

# Visual Director

Direct ambitious visual work: a premium website or interface, an audiovisual piece, or a fixed graphic. Make the result specific to its subject, coherent, technically executable, and memorable. A technically valid MP4, page or image is not automatically an effective piece: judge it against purpose, audience, message and call to action.

Subject before style. Concept before stack. Strong art direction can be quiet, expressive, cinematic or typographic; premium does not require motion, 3D, generated media or effects. Communicate in the user's language.

This is one root skill, not a family per tool. It shares brief, direction, visual system, method choice, prototype, execute-review and style memory across every medium.

## When this skill applies

Load it only when the user explicitly invokes `visual-director` or "Visual Director". It is manual by design: do not auto-load it for ordinary styling, buttons, forms, routine layout or bug fixes. If invoked for a routine edit, keep that edit in the normal project workflow instead of manufacturing a brief or redesign.

## Read only the relevant references

Classify the request (`NEW` / `REDESIGN` / `CONTINUATION` / `EDIT`), identify the deliverable(s) and the production methods they need, then open only the references for the current decision. Do not preload this directory.

| Reference | Read when |
| --- | --- |
| [discovery](references/discovery.md) | Material gaps remain after inspecting the brief and existing project records. |
| [visual direction](references/visual-direction.md) | Creating, continuing or substantially changing the creative direction. |
| [design system](references/design-system.md) | Defining or refining palette, type, layout, material and motion tokens. |
| [design record](references/design-record.md) | A reusable visual record is needed, or an existing one such as DESIGN.md must be reused. |
| [frontend routing](references/frontend-routing.md) | The deliverable is a web page, interface, product UI or interactive experience. |
| [video routing](references/video-routing.md) | The deliverable is audiovisual: programmatic, recorded, edited, or a mix. |
| [graphic routing](references/graphic-routing.md) | The deliverable is fixed: poster, banner, thumbnail, illustration or slide. |
| [explanatory figures](references/explanatory-figures.md) | A hard idea must be explained with a crafted, often interactive illustration (physical metaphor, live readout). |
| [motion graphics](references/motion-graphics.md) | Motion has a defined role in the concept. |
| [3D and shaders](references/3d-shaders.md) | A required idea depends on spatial, material or procedural graphics. |
| [generative media](references/generative-media.md) | Generating images/video, or translating generated footage into authored graphics. |
| [audio](references/audio.md) | Voice, music, SFX, mixing or captions matter to the piece. |
| [quality bar](references/quality-bar.md) | Evaluating a direction, prototype or deliverable. |
| [official docs](references/official-docs.md) | Verifying APIs, versions, compatibility, install/setup or licensing. |

Do not preload the whole set. Web-only work needs no video, 3D or generative reference unless the piece uses those assets; a video piece needs no frontend routing. Reuse references already loaded in context.

If a reference is not enough, follow the official external documentation it cites rather than depending on files outside this skill root.

## Route the work

- **Deliverables** (web/interface, audiovisual, fixed graphic) and **methods** (code, 3D, generation, existing/captured material, editing) are independent axes. Combine them as the piece requires.
- **Assets** travel separately from delivery: a web hero clip may need audiovisual guidance plus generation and audio even though the delivery is a web page. Do not exclude a medium just because the final container is another one.
- Share one brand, brief and asset set across several formats; do not duplicate the brief per medium. Static pieces do not need motion, 3D or generated imagery by default.
- Choose one primary render clock and one owner per property; combine methods across scenes and assets as needed without a one-engine quota.
- Fit the budget, frame rate, reading time and mobile-declared contexts of the actual destinations.

## Fit into the current work

- Inspect the existing brief, approved direction, brand assets, design documentation, components and technical constraints before asking questions. If `docs/decisions/` exists, read it for the stack and platform already decided (project type, rendering, framework).
- Own visual decisions, not the project's orchestration. Keep existing approval, dependency, Git and delivery rules; this skill does not authorize installing tools, spending, uploading or publishing.
- If a PRD, plan or design document already owns a decision, update or reference it rather than creating a competing brief or visual plan. Do not create a new work board or SDD artifacts by ceremony.
- Scale the output to the request: exploration ends with directions; a selected direction moves to a prototype; implementation proceeds only within the requested scope. Do not restart discovery when the user is already choosing or refining a direction.
- Prefer an existing project record over a new artifact; create only what the deliverable actually needs.
- On a conversion page (home, pricing, landing), a redesign changes the presentation, not the content: keep the message, offer, FAQ and social proof, and do not write new promises or claims. Changing that content belongs to `landing-launch` and the user's approval.
- The root may **act** through the current agent or the already-assigned specialist inside the approved scope; it never auto-spawns another agent or installs an extra service. Reading an official technical skill or reference for a real need is not delegating to another agent.

## 1. Establish context and brief

Read the context already in the project and conversation, then fill only material gaps. The brief is logical, not a fixed schema: goal, audience, core message/action, deliverable(s), desired perception, brand/assets and their rights, non-negotiables, technical context, success criteria (at least one creative and one technical), budget/time/authorized actions, and declared assumptions. Use the [creative brief template](assets/CREATIVE_BRIEF.template.md) only when it helps an existing record; it is optional.

Marketing, demo, tutorial, story and editorial have different jobs: establish which one this is and the call to action up front. Use compact successive rounds only for gaps that change material decisions, and reuse what the project already records instead of re-asking. Declare bounded assumptions rather than running a large questionnaire or blocking on minor details. Ask about essential unknowns (rights, permissions, budget, capabilities); record a preference as declared, not as global policy. Visual-domain questions stay in `references/discovery.md`; if an ambiguity that changes the result (goal, scope, a decision with very different costs) remains after that, `grilling` can resolve it, and if the approved work is large and needs a task plan, `to-spec` can produce it. If the user asks for direct execution and the brief is sufficient, proceed without inserting an approval ceremony between phases that are already authorized.

## 2. Explore or continue the direction

- **Known idea**: clarify invariants, inspect the real references and materials, and refine without reinventing the concept.
- **Open idea**: propose two or three genuinely distinct, subject-specific directions; recommend one with concrete tradeoffs. Avoid cosmetic variants of the same template, and do not force the user to supply all the creativity.

Each direction states the central visual idea tied to the subject, palette, typography, composition, imagery/material, motion/camera language with intentional stillness, one defining moment, and the minimum candidate method with its main tradeoff. When a direction is already approved or the brand fixes it, develop it without reopening the choice. See [visual direction](references/visual-direction.md).

Do not promise asset fidelity, export capability or a working interaction before inspecting the assets and checking the tools.

## 3. Define one visual system

Define palette by role, typographic hierarchy, layout rhythm, shape/material language, imagery treatment, and a compact motion vocabulary. Reuse existing tokens and assets when the brief preserves the brand; do not overwrite an existing kit. Full detail lives in [design system](references/design-system.md); use [design record](references/design-record.md) when the system needs a durable record.

Keep small roles clear (which element leads, which supports) rather than styling every element equally. Preserve the brand system when it exists; an authorized new direction can depart from a canonical kit for one piece while the kit itself stays protected.

## 4. Choose the minimum sufficient method

Use the existing application stack, then select each tool for a concrete job. Confirm availability, compatible versions and production constraints through official documentation when needed ([official docs](references/official-docs.md)). Check rights before using, composing, downloading or generating any asset: a public image is not automatically licensed for use, and generated music or fonts still need clearing.

- Start web work with composition, typography, CSS and SVG; escalate to animation libraries, Canvas or 3D only for a requirement those layers cannot express well.
- For video, decide the production **method first** (programmatic generation, recorded/edited footage, 3D, generative or a mix), then the runtime; see [video routing](references/video-routing.md).
- Keep animation ownership clear: one engine per property and one primary render clock. Add methods by scene or asset, not by piling engines on the same property.
- For 3D, build fidelity only where the idea needs it: previz/blocking/camera, then a proxy or reference, then compatible generation control where the interface accepts it. Do not promise exact geometry or cross-clip identity, and bring in a complex renderer only when its role justifies the cost.
- If a tool is unavailable, offer a concrete fallback without silently installing or replacing the stack. Installation, connection and authentication are not the same as permission to spend, upload or publish.

### Tools and environment

- Check what already exists before adding anything: the project manifest, an available binary or capability, authentication, MCP metadata (never print credentials) and whether an actual render or server is reachable. If a needed service has no connector, ask which platform the user uses; if they do not know, recommend generic options from the need, not a fixed catalog.
- `npx <package> --help` may download and execute that package, so it is not a harmless presence probe; use an existing binary or the project manifest instead.

## 5. Plan and prove the representative part

Outline the experience before producing: first viewport/hierarchy/progression/mobile and quiet zones for web; hook, beats, duration, transitions, audio and ending for video; message, eye order, layout and crop variants for fixed graphics.

Prototype the riskiest, most characteristic part where it answers a real question, and not as a forced one-off for every project. State what the prototype must prove and what would change the direction. Use realistic content and inspect the rendered result. When a direction will be applied to several pages or pieces, render one representative page first, show it to the user and do not spread the work across pages or agents until they approve it. A written concept, a good single frame, fps metadata or a source inspection is not visual validation of timing, audio or motion. A proposal remains a proposal until something is actually built.

## 6. Produce, inspect, evaluate

Produce autonomously within the approved scope. Then:

- Inspect the **actual** output in every available modality: render frames and full playback (with audio when present), loaded pages at representative sizes, inspected files.
- Evaluate on two axes: **creative** against the brief and **technical** (viability, performance, accessibility, compatibility, export).
- Correct the **cause**, not the symptom; re-check only the changed areas and their dependent parts; persist a checkpoint.
- Bound cost, time and retries by project rules or the user's choice; there is no prescribed fixed number of reviews.

An editorial approval is not technical QA. If a preview or audio cannot be inspected, record the verification as **pending**, not passed. Never fill a gap with an "OK": an empty review is not a pass. Still frames do not prove pacing or audio; metadata does not prove cadence; a file's presence does not prove it was reviewed.

Actual capability depends on the model, interface and tool: not every environment can produce video, and file access does not imply the ability to hear. Claim only the modality you can actually inspect.

## 7. Deliver, feedback, style memory

Report what was actually built, how it was previewed, what was verified and what remains unverified, plus known compromises. Do not call an unseen result premium or imply a review that did not happen. Treat user feedback as a delta: adjust only the affected scope, and reopen a specific decision if feedback contradicts it rather than restarting the whole brief.

When the user accepts a final piece and asks for it to serve future work, record the accepted style in the project's existing style memory as an **approved example** with its scope: values, roles, composition, image/motion/audio where applicable, assets and rights, and a link to the real example version. A campaign example is not automatically an identity norm; promote it to a general rule only with explicit authorization. Keep one home per datum (history in Git/project records, not a duplicate ledger).

## Stop conditions

Stop when the piece meets the brief or is accepted, when no material improvement remains, when resources are exhausted, when the work is out of scope, or when a permission is missing. Do not apply collateral polish: an accepted V3 is not reopened without a new goal. If the request was only ideas, stop at the proposal.

## Boundaries

This skill does not own project orchestration, Git/CI, business auth, UI state, persistence or delivery. Those keep their existing owners. Connecting or installing a tool does not transfer that ownership.