visual-design-review

Visual design review

Help an experienced reader see the whole design, challenge its assumptions, and steer the choices that matter. The review interface is concise and visual; the specification remains the implementation reference.

This skill organizes the review. It does not supply a rendering framework, replace the planning workflow, or authorize implementing the system being discussed.

Establish what needs a decision

• Read the relevant existing spec, evidence, and conversation. Identify the objective, constraints, current versus proposed behavior, and decisions already made. Preserve accepted choices. Flag new evidence that challenges them without changing their status; ask the user to revisit a choice when its consequences require a changed decision.
• Distinguish verified facts, estimates, assumptions, and unresolved questions. Attach source references to claims and decisions so the reader can inspect the evidence on demand.
• Treat behavior the source does not mention as unknown, not as absent or forbidden. Describe a proposed mechanism's intended benefit without promising a guarantee that has not been established, especially across crashes, retries, or concurrent work.
• Surface choices with meaningful consequences for behavior, system boundaries, cost, security, operations, or reversibility. Use judgment about consequence; do not turn every implementation detail into a checkpoint.
• Give each decision a stable identifier, such as D1, that survives view and document changes. Define the actual question and its affected components before choosing a visual.
• If no consequential choice is open, say so and show only the requested explanation or compact recap. Do not manufacture alternatives or ask for another approval.

Compose with available capabilities

• Discover the skills and rendering tools available in the current environment before selecting the delivery surface. Respect the user's requested format.
• For a process flowchart or interactive process walkthrough, load the shared flowchart skill when available. Let it own process layout and keyboard guidance instead of copying those rules here.
• For an inline surface owned by an available visualization skill, load that skill and follow its rendering contract. Codex's bundled visualize skill is one such capability; do not assume it or its host APIs exist in Claude Code.
• A standalone browser document or a supported Mermaid diagram can be selected up front when that matches the request and available capabilities. Neither requires a Codex-specific host. Missing explicitly requested skills or unsupported chosen formats must be reported; do not silently substitute, auto-install dependencies, or switch delivery surfaces after a failure.
• Choose the representation that answers the question. Do not require every review to contain every diagram type:
  • Architecture diagrams: boundaries, responsibilities, trust, and what changes.
  • Flowcharts: decisions, process order, and reachable outcomes.
  • Sequence diagrams: who communicates with whom, timing, and failure handling.
  • State diagrams: lifecycle changes and valid transitions.
  • Tables: a few alternatives and qualitative tradeoffs.
  • Quantitative charts: measured or explicitly estimated cost, latency, capacity, or other quantities. Show units, sources, and assumptions; do not fabricate precision or turn qualitative judgments into arbitrary scores.
  • Mockups: user-visible behavior or interaction choices.