gracker-diagrams

Gracker Diagrams

Default objective:low-pressure feel, high explanatory power, strong structure, visually restrained but information-dense. Use the process of "structure the content first, then generate the visual prompt, and finally render as needed," and fix the style to the technical hand-drawn style preferred by Gracker.

Mandatory execution principles

Do not throw the original text directly to an image generation/drawing tool, and do not improvise the final prompt on the spot. You must first produce intermediate files according to the process:

1. source.md: save the raw input or excerpts from the original text
2. analysis.md: analyze the information structure and the basis for inclusion/exclusion
3. structured-content.md: the Skill decides which content goes into the visual deliverable
4. copy.md: review all visible titles, module names, labels, and footnotes as pre-image copy
5. prompts/infographic.md: generate the final visual prompt based on the corresponding prompt template

Only after the above files are completed can you move on to delivery or optional rendering. When the content is long, first split it into pages by chapter; then filter high-value information within a single page. It is forbidden to compress multiple chapters into one overview poster, and it is also forbidden to arbitrarily compress with an improvised prompt.

Default pagination rules

Unless the user explicitly says "only one image / single page / compress into one,"infographics default to pagination by content chapter, one chapter per image, and explain that chapter in detail. Do not wait for the user to say it again every time.

Applies

• Style B Macaron, Style C Gracker infographic
• tasks such as videos, articles, research, courses, long notes, etc. that involve "drawing out a piece of material"
• Style D Xiaohongshu: only when the user says "two images" is it fixed at 2; otherwise also produce cards by chapter, each independently readable

Do not force it

• the user only wants one architecture diagram, one Mermaid-converted diagram, or a single concept
• Style A whiteboard architecture diagram is still one image by default; only when the system is so large that the main path cannot be seen clearly in one image should it be split by subsystem/layer

How to split

1. prioritize the original text's official chapters, timeline, and subheadings
2. when there are no official chapters, split by thematic turns; do not invent extra chapters
3. thin hooks/intros can be merged into the next chapter; do not cut again just to make up the page count
4. analysis.md must clearly state: how many pages were split, which chapter each page corresponds to, and why they were merged
5. copy.md by Card 01 … Card NN list the visible text on each page
6. write the prompt as prompts/infographic-01.md … infographic-NN.md; for the generated image *-01.png … *-NN.png

Forbidden

• compressing multiple chapters into one image to save time
• using "there is too much content so summarize first" instead of pagination
• delivering only the first image after drawing multiple images

Pre-image copy review

Before generating the prompt, you must first convert structured-content.md into copy.md。copy.md is the admission layer for the text visible in the final image; analytical language, editorial language, or AI-flavored sentences must not be sent directly into image generation.

Copy review only extracts gracker-writing 's core principles and does not depend on gracker-writing skill：

• Accurate: all titles, numbers, terms, and judgments must be traceable back to source.md、analysis.md or the cited material; do not add data or conclusions that do not exist.
• Useful: every title, module name, and list item must carry its own information gain. Copy that still works when only nouns or slogans remain is not acceptable.
• Easy to read: short titles summarize the task of the page, while body labels explain the evidence, conditions, and boundaries; do not use long sentences as titles.
• Titles speak for themselves: the main title must state what problem the page solves, for example 已确认的泄露范围、还没坐实的爆点; avoid 发生了什么、为什么重要、别把推测当结论 Generic titles like this.
• Judgments must have boundaries: when it involves rumors, media reports, sample verification, inference, or risk, the criteria must be clearly stated on the same screen.
• By default, write it as a content statement: the visual is used to explain the facts, structure, mechanisms, evidence, boundaries, and impact in the original material; unless the user explicitly asks for writing advice, communication advice, or publishing advice, do not write any page as a list of suggestions on "how to express it / what not to write / recommended wording."
• Remove the sense of an editing process: do not include 这一版、按要求、这里要讲、下面来看、先别急着、真正的、值得注意、核心在于 or other meta-narration or filler words.
• Avoid contrast slogans: do not use 不是 X，而是 Y、并不是 X，而是 Y、不只是 X，还 Y as a title or bottom-line summary.
• A list is not a table of contents: each list item uses the structure 对象 + 判断/口径/影响 , for example 黑客声称 630GB：媒体只做样本核验, do not write only 泄露规模。
• Prioritize visuals and text: do not repeat the same meaning in the series name, main title, subtitle, and module title; the title hierarchy is responsible for division of labor, not for repeatedly shouting the same sentence.

copy.md Suggestions include:

系列名（可选，XHS 默认不显示）:
Card 01:
- 页码:
- 主标题:
- 副标题（可选，XHS 默认不显示）:
- 模块:
- 标签:
- 脚注:
Card 02:
- 页码:
- 主标题:
- 副标题（可选，XHS 默认不显示）:
- 模块:
- 标签:
- 脚注:
文案自检:
- 是否有重复标题:
- 是否有泛标题:
- 是否有无依据判断:
- 是否有 AI 味/编辑语:

Rendering hard constraints

If the user requests "draw an image / produce an image / render / generate PNG / convert Mermaid to image," the final product must call image_generate, using GPT Image 2 from the current Hermes image configuration (image_gen.provider: fal, image_gen.model: fal-ai/gpt-image-2）。prompts/infographic.md is only an intermediate product, not the final delivered image.

It is forbidden to replace the final image with local HTML, SVG, Mermaid screenshots, browser screenshots, ASCII, or low-quality local generation. If GPT Image 2 backend credentials are missing, clearly report the missing configuration; do not downgrade or fake it.

Style routing

Choose the style according to user intent:

Style	Trigger words	Applicable scenarios
Whiteboard architecture diagram(default)	Architecture diagram, system diagram, module relationships, Mermaid conversion, flowchart, sequence diagram, whiteboard diagram, draw a diagram	System breakdown, component relationships, rendering pipeline, request chain
Macaron infographic	Infographic, single-page summary, vertical image, long image, knowledge summary image, framework diagram, Skill overview image	Knowledge system summary, methodology overview, Skill framework, article summary
Gracker infographic	Gracker diagram, technical infographic, research diagram, in-depth infographic, technical long image	Technical research summary, in-depth content visualization, high-text-density technical long image
Gracker Xiaohongshu style	Xiaohongshu style, Xiaohongshu image, xhs, social image, dual image, carousel image	Split a high-density Gracker long image into two social network images readable on mobile

If it cannot be determined, default to the whiteboard architecture diagram.

---

Style A: Whiteboard architecture diagram (default)

First read:

• references/style-guide.md
• references/prompt-template.md
• references/quality-checklist.md

Output process

1. Create the working directory for this session

Create manually:

<root>/<slug>/
├── source.md
├── analysis.md
├── structured-content.md
├── copy.md
├── prompts/
│   ├── infographic-01.md   # 多章则 01..NN；用户只要一张图时可用 infographic.md
│   └── infographic-02.md
└── output/
    └── diagram-01.png  # 可选：只有实际渲染后才需要；多章编号

If the user has already given a fixed directory, use the user directory directly and do not create additional levels.

2. Save the raw content

Write the raw input as-is to source.md。

The source can be:

• Mermaid
• Markdown body
• Article paragraphs
• Structural description of existing images
• Manually listed modules/relationships/steps

Rules:

• Do not add new information
• Do not change facts
• Only organize the structure

3. Analyze the information structure

In analysis.md , answer only 5 things:

1. The goal of the diagram (one sentence)
2. Content shape (sequence / hub-and-spoke / layered / decomposition / comparison)
3. 3-7 main elements
4. What secondary annotations there are
5. Where it is suitable to add Perfetto-style tracks (if there is time, phases, waiting, parallelism)

4. Generate structured content

Organize the diagram into visually consumable modules, and write to structured-content.md。

Keep the format as stable as possible:

• Title
• One-sentence summary
• Main module list
• Connection relationships
• Auxiliary annotations
• Legend/notes
• Copy label list

5. Copy review

Based on structured-content.md generate copy.md, keeping only the visible text that can go into the diagram. All titles, module names, labels, and footnotes must pass the "accurate / useful / readable / bounded" check.

6. Choose a layout

Choose based on the content shape:

• Sequential flow → linear-progression
• Central system + surrounding dependencies → hub-spoke
• System component decomposition → structural-breakdown
• Layered mechanism → hierarchical-layers
• High-density overview → dense-modules

Unless the user specifies otherwise, prioritize explainability, not visual gimmicks.

7. Generate the prompt

Based on references/prompt-template.md generate prompts/infographic.md。

Hard style constraints:

• White background or light beige paper background
• Thick black outlines
• Rounded-corner modules
• Low-saturation light-colored bordered sections
• Simplified black-and-white icons
• Orthogonal arrows
• Ample whitespace
• Hand-drawn/whiteboard-polished feel
• If there is time, phases, or concurrency, add Perfetto-style horizontal tracks or timeline bars

8. Deliver or optionally render

By default deliver source.md、analysis.md、structured-content.md、copy.md and prompts/infographic.md. If the user requests a finished image, and the current runtime environment provides image generation, drawing, browser rendering, or design tools, you may use the available tools to render; do not hardcode a model, vendor, or tool name in the Skill.

Suggested output constraints:

• aspectRatio: 16:9(default, landscape)
• filename: <slug>.png

9. Acceptance

Use visual tools to check whether the result satisfies:

• The main path can be understood at a glance
• It is not corporate PPT style
• It is not realistic poster style
• It is not cute cartoon style
• Thick lines, clear structure, light colors
• If there is timing/phases, Perfetto-style tracks actually appear

If it does not satisfy, revise the prompt and retry once. Do not redraw endlessly.

Additional rules for converting Mermaid to images

If the original input is Mermaid:

• Keep the Mermaid source
• If rendering capability is available, also generate a presentation-version image; otherwise deliver the presentation-version prompt
• If an exact version is needed, add an SVG or native Mermaid-rendered version
• Recommended order in the document: presentation version → exact version → Mermaid source

---

Style B: Macaron infographic

Read first:

• references/macaron-style-guide.md
• references/macaron-prompt-template.md

Output flow

Shares steps 1-5 with Style A (create directory → save original content → analyze information structure → generate structured content → copy review), but the subsequent steps differ:

6. Choose layout (Macaron adaptation)

Layout selection logic for Macaron infographics:

• Split pages by chapter by default, one image per chapter; only make a single page when the user explicitly asks for just one image
• Portrait orientation preferred (1024x1536 or 768x1024）
• Sequential process / step-by-step expansion → connected by vertical arrows
• Comparison / pros and cons → left-right split-column cards
• Composition / elements → side-by-side Macaron cards
• Hierarchy / quality inspection system → nested or stepped
• Cycle / iteration → circular
• Multi-module overview → card matrix + connecting lines

7. Generate prompt

Generated based on references/macaron-prompt-template.md .

Core style hard constraints (already in the template, no need to repeat):

• Warm cream paper background #F5F0E8
• Macaron-colored rounded cards, not completely filling the outline
• Hand-drawn wavy arrows
• Simple stick-figure cartoon + doodle decorations
• Bold large hand-drawn text title centered
• Bottom summary optional; if used, it must be a positive short sentence, and the "not X, but Y" contrastive sentence pattern is prohibited

8. Delivery or optional rendering

Deliver the prompt pack by default. If the user requests a finished image, and the current runtime environment provides image generation or design tools, you may use the available tools to render; do not hardcode models, vendors, or tool names in the Skill.

Suggested output constraints:

• size: 1024x1536
• filename: <slug>-macaron.png

9. Acceptance

• The information structure can be understood at a glance
• Macaron-colored blocks appear and do not completely fill the outline
• Has a hand-drawn jittery feel
• Has doodle decorations (stars, underlines, small arrows)
• If there is a bottom summary, it must be a positive short sentence, and must not use the "not X, but Y" contrastive sentence pattern
• Portrait aspect ratio
• Not a whiteboard architecture diagram style

If not satisfied, revise the prompt and retry once.

---

Style C: Gracker infographic

Read first:

• references/gracker-style-guide.md
• references/gracker-prompt-template.md

Output process

Shares steps 1-5 with Style A (create directory → save original content → analyze information structure → generate structured content → copy review), but the subsequent steps differ:

6. Choose layout (Gracker adaptation)

• Portrait orientation preferred (1024x1536）
• Split pages by chapter by default, one image per chapter; only make a single-page long image when the user explicitly asks for just one image
• High-density vertical layout, with hand-drawn lines connecting modules in a progressive manner
• Background colors naturally differentiate, no card frames
• When there is a lot of content within a single page, organize it with numbered blocks; do not squeeze in another chapter to change the density

7. Generate prompt

Generated based on references/gracker-prompt-template.md .

Core style hard constraints (already in the template, no need to repeat):

• Warm cream paper background #F5F0E8
• No card frames, background colors transition naturally
• Text density takes priority, icons restrained
• Connected by hand-drawn lines and wavy arrows
• Bottom summary optional; if used, it must be a positive short sentence, and the "not X, but Y" contrastive sentence pattern is prohibited

8. Delivery or optional rendering

Default delivery is a prompt pack. If the user requests a finished image, and the current runtime environment provides image generation or design tools, the available tools may be used to render it; the model, vendor, or tool name must not be hardcoded in the Skill.

Suggested output constraints:

• size: 1024x1536
• filename: <slug>-gracker-01.png … <slug>-gracker-NN.png; only use it when the user wants just one image <slug>-gracker.png

9. Acceptance

• The information structure can be understood at a glance
• No card frames, bubble frames, or dashed frames
• Background colors transition naturally to distinguish modules
• High text density, with technical details kept complete
• Hand-drawn lines and wavy arrows for connections
• Few icons, text-first
• If there is a bottom summary, it must be a positive short sentence, and must not use the "not X, but Y" contrastive sentence pattern
• Vertical screen ratio

If not satisfied, revise the prompt and retry once.

---

Style D: Gracker Xiaohongshu style

Read first:

• references/xiaohongshu-style-guide.md
• references/xiaohongshu-prompt-template.md

Output process

Shares steps 1-5 with Style A (create directory → save original content → analyze information structure → generate structured content → copy review), but the subsequent steps differ:

6. Choose layout (Xiaohongshu adaptation)

• When the user says "two images", split into two consecutive images:01/02 and 02/02
• When the user does not say two images, produce cards by content section:01/NN … NN/NN, do not first compress into 2 images
• Single image prioritizes a social network vertical image (suggested 1080x1440; when the content is truly dense, it may be slightly relaxed between 1080x1440 and 1200x1600 ), overall still close to 3:4, and ultra-long images are prohibited
• The titles of the two images must have a clear logic: numbering, part one/part two, good news/market concerns, conclusion/verification points, etc.
• The title system is fixed as "unified page number corner badge + a different main title for each image"; by default only one main title is shown, and the small series name and subtitle are not shown
• The page number corner badge must use the same position, color, shape, font size, and hand-drawn style in both images, with only the page number text allowed to change from 01/02 to 02/02
• The main titles of the two images must each serve a different information function, avoiding repeating the same title; the main title font size, font weight, and whitespace rhythm must be consistent
• When source, methodology, or limitation notes need to appear, place them in body small annotations, footnotes, or source lines, not as a second title or subtitle
• Information is not reduced: distribute the complete content of the same topic across the two images, rather than deleting details
• Each image must be independently readable: retain the topic title, page number, and key source or limitation notes
• The default density should be close to a Gracker long image: each image usually has 6-8 information areas, and each information area has 2-4 short sentences or labels; prioritize compressing icons, decoration, title whitespace, and margins, and do not trade large whitespace for "cleanliness"
• Density conservation: Xiaohongshu adaptation may only change layout, font size, columns, and copy compression, and must not delete the modules in copy.md into a low-density summary. Each image must retain at least 80% of the visible information of the modules on that page; key facts, causal chains, boundaries, source methodology, and action points must not be deleted just because of "mobile readability".
• If the content does not fit, the handling order is: shorten sentences → add columns/numbering/sidebars → reduce icons and decoration → relax to 1200x1600 or 1024x1536; it is prohibited to first reduce to 3-4 large blocks.
• The “readability” of the Xiaohongshu style is not low density, but font size, line spacing, grouping, and hierarchy being more suitable for mobile phones

7. Generate prompt

Based on references/xiaohongshu-prompt-template.md generate.

Must be in prompts/infographic.md write the complete two-image prompt pack; when more detail is needed, you can additionally write:

• prompts/xiaohongshu-01.md
• prompts/xiaohongshu-02.md

Core style hard constraints (already in the template, no need to repeat):

• Inherit the Gracker infographic: warm cream paper background, natural color blocks, no card frames, few icons, text first
• The two images are one carousel set, not mechanically cutting a long image into two halves
• The text density of a single image is still high, but the body text must be larger and more readable than a long image; readability relies on grouping, font size hierarchy, short labels, and columns, not on deleting information
• Each image carries about half of the complete structure, retaining wording, evidence, judgment, and boundaries, avoiding users having to manually zoom in on Xiaohongshu
• The prompt must use copy.md the final visible copy in it, do not put analysis.md the analytical sentences directly onto the image

8. Delivery or optional rendering

Default delivery is the prompt pack. If the user requests finished images, two final images must be rendered; do not deliver only the first one.

Suggested output constraints:

• size: 1080x1440; when information density is high, it can be relaxed to close to 3:4 1200x1600
• filenames: <slug>-xhs-01.png, <slug>-xhs-02.png

9. Acceptance

• Both images use the same visual system, the title logic is clear, and the page numbers are clear
• The page number appears only once, as a corner mark or header marker; the page number must not be repeated in the main title
• The page number corner mark uses the same style and position; one cannot use a red ellipse and the other a purple color block
• The main titles of the two images do not repeat, and should form a continuation relationship such as “fact / reason,” “evidence wording / risk boundary,” or “positive factors / market follow-up questions”
• By default, the two images show only one main title; there must be no heavy title stacking of “small series name + main title + subtitle”
• The two images have consistent main title font size, font weight, position, and top whitespace
• A single image is not a long image; the main text can be read on mobile without zooming in, but key facts must not be sacrificed just to look clean
• Information density is sufficient: each image usually has 6-8 information areas, and key numbers, source wording, causal chains, and limiting conditions are all on the image
• Information density is conserved: each image retains at least 80% of the visible information of the module on that page; do not leave only the title, icons, and 3-4 slogan-like summaries
• The copy passes copy.md self-check: no generic titles, repeated titles, editorial remarks, unsupported judgments, contrast slogans, or AI-flavored filler sentences
• Together the two images cover the original structure and key details, without deleting core content for layout
• No card frames, bubble frames, or dashed frames
• The background color naturally transitions to distinguish modules
• Few icons, text first
• If there is a bottom summary, it must be a positive short sentence, and must not use the “not X, but Y” contrast sentence pattern
• When retrying is needed, retry at most once, and clearly define the change target

Do not force the following situations:

• Data charts, line charts, bar charts: use vega / data visualization tools
• Strict engineering diagrams such as UML and ER: prefer mermaid / graphviz
• If you only want something quickly maintainable and do not care about visuals, use mermaid directly

Output summary format

In the final report, only say:

• Image name
• Select layout
• prompt pack path
• Rendered image path (if already rendered)
• Whether to keep Mermaid/SVG
• Whether it passes one round of visual acceptance (if already rendered)