SOC 직업 분류 기준
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
직접 명령은 검토 Prompt를 거치지 않습니다. 실행하기 전에 소스를 확인하세요.
npx skills add https://github.com/tomevault-io/skills-registry --skill diagram-orchestrator명령은 한 줄로 유지됩니다. 복사하기 전에 가로로 스크롤해 전체 내용을 확인하세요.
로컬 사본을 원하시나요? SkillsMP에서 현재 제공할 수 있는 파일을 다운로드하세요.
SKILL.md 표시 중
| Use when this capability is needed.
> Use when this capability is needed.
Review architecture and API design for the vfs-s3 project. Use when the user mentions @architect, asks to review an issue's design, discuss module boundaries, API shape, or architectural decisions for vfs-s3. Also trigger when the user wants to create an ADR (Architecture Decision Record) or evaluate a technical approach for the project. Intended for dispatch from Codex automation or Claude routines; GitHub trigger phrase: @vfs-s3-bot please prepare design doc Use when this capability is needed.
| name | diagram-orchestrator |
| description | > Use when this capability is needed. |
Entry point for creating information design diagrams. Routes work through specialized skills, each handling a distinct layer of the design process. The first three skills (content → encoding → design) are shared; the final rendering step branches to either Illustrator or SVG.
User request (document, concept, data)
│
▼
┌─────────────────────────────┐
│ Skill 1: Content Analysis │ What to show
│ diagram-content-analysis │ → Content specification (YAML)
└──────────────┬──────────────┘
│
▼
┌─────────────────────────────┐
│ Skill 2: Visual Encoding │ How to encode it
│ diagram-visual-encoding │ → Visual design plan (YAML)
└──────────────┬──────────────┘
│
▼
┌─────────────────────────────┐
│ Skill 3: Graphic Design │ How to make it look right
│ diagram-graphic-design │ → Design specification (YAML)
└──────────────┬──────────────┘
│
▼
┌──────┴──────┐
│ Renderer? │
└──┬───────┬──┘
│ │
┌─────┘ └─────┐
▼ ▼
┌────────────────┐ ┌────────────────┐
│ Skill 4a: │ │ Skill 4b: │
│ Illustrator │ │ SVG Render │
│ Render │ │ │
│ → .ai + PNG │ │ → .svg + PNG │
└────────────────┘ └────────────────┘
Each skill produces a structured YAML specification that the next skill consumes. The user can approve, modify, or reject the output at each stage.
After Skill 3 completes, choose the renderer:
Use Illustrator (Skill 4a) when:
Use SVG (Skill 4b) when:
Default: If the user doesn't specify, check whether Illustrator is available. If yes, use Illustrator. If no, use SVG. When in doubt, ask.
New diagram from scratch: User provides source material (document, dataset, concept description) and wants a diagram. Run the full pipeline.
Modify an existing diagram: User identifies a problem. Route to the appropriate skill based on what layer the problem lives in (see Routing Guide below).
Explore before committing: User isn't sure what kind of diagram they want. Start with Skill 1 to analyze the content, then present options at Skill 2.
Read the user's request and determine:
What source material exists? Document, dataset, conversation notes, or just a concept description? This determines how much Skill 1 needs to do.
How clear is the intent? "Make a diagram of this chapter" is clear — run the pipeline. "Help me visualize something" is ambiguous — interview first.
Are there constraints? Page size, medium (print/screen/presentation), audience, standalone vs. companion to text. Capture these for Skill 1's constraint section.
Read the diagram-content-analysis skill and follow its workflow. Feed it the source
material and constraints.
Output: A content specification with story, dimensions, relationships, concepts (if applicable), written content, and constraints.
Checkpoint: Present the content spec to the user. Key questions:
If the user wants changes, iterate within Skill 1. Don't proceed until the content spec is approved.
Read the diagram-visual-encoding skill. Feed it the approved content spec.
Output: A visual design plan with composition type, channel assignments (which visual channels encode which data dimensions), dynamic range verification, spatial layout, and Tufte audit.
Checkpoint: Present the visual plan. Key questions:
This is where the user might say "I was thinking more of a flowchart" or "Can we show the volume differences more prominently?" Those are Skill 2 decisions.
Read the diagram-graphic-design skill. Feed it the approved visual plan.
Output: A complete design specification with grid system, type scale, color palette, element styling, and composition rules — all as concrete values (point sizes, RGB values, spacing in grid units).
Checkpoint: The design spec is technical. For most users, present a summary:
Most users will approve this quickly. Designers may want to adjust colors, fonts, or spacing — those are Skill 3 decisions.
Choose the renderer based on the Renderer Selection rules above.
Read the diagram-illustrator-render skill. Feed it both the visual plan (Skill 2)
and the design spec (Skill 3).
Output: A rendered diagram in Illustrator, exported as PNG for review.
Evaluation loop: View the PNG. Check against the design spec. Fix rendering issues (misalignment, wrong colors, text overflow, MRAP errors). Typically 2-4 iterations.
Read the diagram-svg-render skill. Feed it both the visual plan (Skill 2)
and the design spec (Skill 3).
Output: An SVG file, optionally converted to PNG for review.
Evaluation loop: Read the SVG file to view it. Check against the design spec. Fix rendering issues (text clipping, missing markers, foreignObject problems). Typically 2-3 iterations. SVG is declarative, so iteration is faster — no app launch or osascript round-trips.
SVG-specific notes:
<marker> for arrows instead of manual arrowhead triangles<foreignObject> for wrapped textcairosvg if the user needs raster outputFinal checkpoint: Show the user the rendered diagram. If they identify issues, route to the appropriate skill (see below).
Once approved:
Illustrator path:
SVG path:
When the user identifies a problem with a diagram, route to the skill that owns that layer. The diagnostic question: what kind of change would fix it?
Signal words: story, message, content, concepts, definitions, examples, text, what it says, missing information, wrong emphasis.
Signal words: diagram type, composition, chart type, encoding, channel, flow direction, reading order, can't see the difference, clutter, pattern.
Signal words: colors, fonts, spacing, alignment, grid, typography, hierarchy, professional, polish, clean up, looks off, feels wrong.
Signal words: rendering, Illustrator, error, export, z-order, overlap, blurry, positions, script, JSX, MRAP.
Signal words: SVG, markup, viewBox, marker, foreignObject, text clipping, xmlns, browser rendering, cairosvg, convert to PNG.
Sometimes the user says something like "it doesn't look right" without being specific. Ask a diagnostic question:
"Is the information wrong (what it shows), or does the presentation feel off (how it looks)?"
If information → Skill 1 or 2
If presentation → Skill 3 or 4
"Can you see the main message in the first 3 seconds?"
If no → probably Skill 2 (encoding not working)
If yes but it's ugly → Skill 3 (graphic design)
When intent is clear (user provides a document and says "make a one-page diagram of the key concepts"): Run the pipeline, present checkpoints briefly, move quickly. Propose rather than interview.
When intent is ambiguous (user says "help me visualize this"): Interview at Skill 1 to understand what they want to communicate. Present composition options at Skill 2. Move to rendering only after the design direction is confirmed.
When iterating (user has seen a render and wants changes): Identify the layer, route directly to that skill, and re-render. Don't re-run upstream skills unless the change cascades (e.g., changing the story in Skill 1 requires re-running 2, 3, and 4).
Changes at an upstream skill may invalidate downstream work:
| Change at | Must re-run |
|---|---|
| Skill 1 (content) | Skills 2, 3, 4a/4b |
| Skill 2 (encoding) | Skills 3, 4a/4b |
| Skill 3 (design) | Skill 4a or 4b only |
| Skill 4a/4b (render) | Nothing — just fix and re-render |
| Switch renderer | Skill 4a ↔ 4b only (design spec is shared) |
In practice, most iterations after the first render are Skill 3 or 4 changes that don't cascade. Content and encoding changes are rarer but more expensive. Switching between Illustrator and SVG is cheap — the design spec feeds both renderers, so only the rendering step re-runs.
For the common case — user provides a document and wants a diagram:
Each skill has its own reference documents. Read them when that skill runs:
references/content-writing.md, references/output-format.mdreferences/channel-effectiveness.md, references/compositions.mdreferences/design-rules.mdreferences/extendscript-api.md, references/composition-implementations.mdreferences/svg-patterns.mdConverted and distributed by TomeVault — claim your Tome and manage your conversions.