Technical Illustration

Make a proposal judgeable or a mechanism understandable through a picture. The calling workflow owns the argument, evidence, approval and publication. This skill supplies the visual, not another director or an execution framework. Em dashes are banned from all output.

Establish what the reader needs to see

Identify the question, audience, destination, supported content and selected visual direction. Reuse the caller's existing record and unchanged assets. Distinguish these uses:

• Design approval: a proposed screen or content frame exposes the concept, palette, typography, layout and realistic information density before full production. It is not a capture of implemented behavior.
• Explanation: a comparison, state diagram or sequence makes a source-supported relationship visible.
• Observed behavior: a real capture shows what actually happened at the recorded revision. An authored imitation cannot replace it.

Prefer pictures and plain prose together when they make the reader's task easier. Do not require prose to fail first or an implementation to cross a complexity threshold. A trivial change may need only a few sentences. Remove figures that merely decorate or repeat prose.

Compose the useful view

When available, load frontend-design for a consequential visual direction. It is not a mandatory dependency of this shared skill: selective installations may not include it. Otherwise use the caller's established design system and the composition/inspection guidance here and in rendering. Ground palette, typography and layout in the subject, identify the focal evidence, keep a consistent visual vocabulary, and inspect realistic content at delivery size. Do not invent a house palette or install a missing skill automatically. Preserve a caller's stricter required-tool contract. An accepted direction remains authoritative until its inputs change.

Choose realistic subject content. Show a representative mechanism or screen, not only a title card, palette swatch or generic mood board. Expose materially different layouts and states with additional views where needed. Neither one image per scene nor a fixed image quota is required.

Use the rendering guidance for the selected route. Prefer established components for controls and document chrome. Reuse the caller's composition, assets and styling when available. Choose a simple diagram when it answers the question, and composed stills when visual treatment is itself the decision. Build only the selected static views before approval. Do not construct working mini-apps, a full timeline, narration or video merely to obtain them.

Keep related objects recognizable across views. Put labels on what they name, use comparable scales for comparisons, and make the consequential difference visible. One enormous diagram full of small text is not an alternative to a wall of prose.

For current/proposed UI, before/after evidence, annotations or reveal controls, read comparisons. Reuse actual screens/components when their context makes the change easier to judge. Keep Current untouched and put change annotations on Proposed only.

Render, inspect and return

Render the actual image or vector output and inspect it at the destination's viewing size. Check its meaning against the source as well as legibility, hierarchy, clipping, label accuracy and focal point. Full-size inspection must remain possible when the destination reduces a diagram.

Return the inspected visual, a useful caption or text alternative, editable source and the design/source revision information needed to reproduce it. Place the visual beside the passage or decision it explains. Keep the claim, important qualifications and requested action in readable text too. Complex figures need an accessible account of the relationships or values they convey.

Retain provenance in the caller's record. Use specific captions such as "Proposed queue view" when that distinction changes what the reader can infer. Do not add generic production-origin badges or use a disclaimer to excuse unsupported content. Exclude sensitive data before rendering or upload.

For approval samples, bind the script or storyline and visual revisions in the existing approval record. Feedback is not approval. A material visual change returns for review before dependent production, while unchanged valid work is retained. A still establishes appearance, not motion quality, runtime correctness or final acceptance.

Use the destination's authorized attachment path. For PRs, preserve authentic behavior captures and verify uploaded links. If uploading is unavailable, return the files with their intended placement, not placeholders or local paths presented as published assets.

Keep production source, dependencies, captures and renders in the host's authorized external artifact location, outside the repository and installed skills. Preserve licenses and retention policy. Record actual costs or elapsed times only when measured. Fewer rendered frames do not establish end-to-end authoring speed.

Failure boundary

A missing required renderer or source is a specific blocker. Follow the caller's established toolchain recovery procedure. Do not repair global tools, switch to a paid service, fabricate a screenshot or start a full media job as an automatic fallback.

An optional figure may be omitted when the remaining communication fully answers the reader's question. A required approval preview or essential explanation remains blocked until supplied or its scope is explicitly changed. Retain unfinished sources as drafts and hold the approval request when required rendering or visual inspection failed. Do not present an approval request alongside an admission that its required picture was never inspected.