Title here
Summary here
AI & Automation
On this page
1. Goto AI Prompts
Tip: I usually ask AI to generate prompt for itself by providing what I want. Then work on the prompt to fine tune as needed.
Generate Infographics
Topic: <TOPIC>
Level: <Beginner | Intermediate | Advanced | Expert>
You are an expert educational content planner and subject-matter explainer.
Create an accurate, level-appropriate content blueprint for a handwritten educational infographic about the specified topic.
## 1. Understand the Topic
First, internally identify the nature of the subject, such as:
- scientific concept
- person
- historical event
- object
- place
- process
- system
- theory
- technology
- plan
- social concept
- economic concept
- environmental topic
- classroom concept
- other relevant subject type
Use this classification only to determine the most useful content structure.
Do not create a separate "Subject Type" section unless it genuinely helps explain the topic.
## 2. Match the Requested Learning Level
Adjust both content selection and depth according to the requested level.
### Beginner
Prioritize:
- core definition
- essential parts
- basic mechanism
- simple examples
- fundamental relationships
Avoid unnecessary terminology and edge cases.
### Intermediate
Prioritize:
- mechanisms
- important relationships
- classifications
- cause and effect
- representative examples
- useful comparisons
Assume basic familiarity with the subject.
### Advanced
Prioritize:
- deeper mechanisms
- interacting factors
- nuanced relationships
- evidence
- limitations
- exceptions
- meaningful comparisons
- advanced applications
Avoid spending space on obvious introductory material.
### Expert
Prioritize:
- underlying mechanisms
- subtle distinctions
- competing explanations or models
- advanced relationships
- evidence and interpretation
- limitations and uncertainties
- edge cases
- domain-specific terminology
- important quantitative information
- expert-level comparisons
Assume strong foundational knowledge.
Do not interpret "Expert" as simply using more jargon. Increase conceptual depth.
## 3. Select 6–8 Knowledge Modules
Automatically choose 6–8 strong, topic-specific modules.
Possible module types include:
- Definition / Identity
- Key Features
- Structure
- Components
- Composition
- Origin
- Background
- Development
- Chronology
- Location / Context
- Function
- Mechanism
- Process
- Stages
- Types
- Classification
- Cause & Effect
- Comparison
- Relationships
- Evidence
- Examples
- Applications
- Effects
- Limitations
- Misconceptions
- Practical Use
These are possibilities, not a required template.
Choose modules according to the actual topic.
Do not force irrelevant categories into the structure.
For example:
A historical event may favor:
CAUSES → TIMELINE → KEY ACTORS → TURNING POINTS → CONSEQUENCES → LEGACY
A scientific mechanism may favor:
STRUCTURE → INPUTS → MECHANISM → INTERACTIONS → OUTPUTS → VARIABLES → LIMITATIONS
A person may favor:
BACKGROUND → DEVELOPMENT → MAJOR WORK → IDEAS → INFLUENCE → CONTROVERSIES → LEGACY
A system may favor:
COMPONENTS → INPUTS → PROCESS → INTERACTIONS → OUTPUTS → FEEDBACK → FAILURE/LIMITATIONS
Let the topic determine the structure.
## 4. Module Content
For each selected module provide:
### Module Title
One short concept label, not an explanatory sentence.
### Essential Content
Provide 3–5 essential facts or ideas.
Some modules may need 3 items; others may need 4 or 5.
Do not force every module to contain the same number of items.
Do not add filler merely to reach a target count.
Write the exact compact text intended to appear on the infographic.
Prefer:
- short bullets
- fragments
- labels
- names
- dates
- numbers
- equations
- measurements
- brief contrasts
- compact relationships
Avoid paragraphs and unnecessarily complete sentences.
Keep each item to approximately 3–10 words when possible.
For advanced or expert topics, slightly longer items are acceptable when technical precision requires them.
Use the fewest words necessary without sacrificing accuracy.
## 5. Show Relationships
Whenever useful, express relationships visually and compactly.
Prefer structures such as:
CAUSE → EFFECT
INPUT → PROCESS → OUTPUT
STRUCTURE → FUNCTION
EARLIER → TRANSITION → LATER
FACTOR ↑ → EFFECT ↑
A ↔ B
PART → WHOLE
CONDITION → RESPONSE
Do not reduce genuinely complex relationships to misleading simple arrows.
## 6. Highlighting
Within each content item, wrap only the most important word or short phrase in ==double equals==.
Examples:
==photosynthesis== → glucose
1789 → ==French Revolution==
DNA → ==RNA== → protein
warming ↑ → ==ice loss== ↑
Mark approximately 1–2 spans per item when useful.
A highlighted span may be:
- defining term
- important name
- date
- number
- measurement
- mechanism
- short contrast
- important relationship
Use the shortest span that preserves the intended meaning.
Never highlight more than roughly one quarter of an item.
Do not highlight text merely for decoration.
Do not create a separate glossary or key-terms section from highlighted words.
## 7. Visual Representation
For each module, specify the most useful visual representation.
Examples include:
- diagram
- labelled illustration
- map
- timeline
- cross-section
- process flow
- cycle
- comparison panel
- chart
- hierarchy
- cause-effect chain
- equation
- annotated example
- before/after view
- relationship network
Choose visuals because they explain the information better than text.
Do not add decorative visuals merely to fill space.
## 8. Central Visual
Specify one central visual representation for the entire topic.
Choose the visual that best communicates the topic's core idea.
Examples:
Process → process flow
Historical event → timeline/map
Biological structure → labelled cross-section
System → component/interconnection diagram
Person → life/work timeline
Comparison → side-by-side visual
Cycle → circular process diagram
Geographic topic → annotated map
The central visual should act as the conceptual anchor for the infographic.
## 9. Accuracy and Specificity
Keep all information:
- specific
- accurate
- topic-relevant
- appropriate to the requested level
Prefer concrete information over generic statements.
Use meaningful:
- names
- dates
- quantities
- mechanisms
- relationships
- examples
- evidence
when they genuinely improve understanding.
Do not fabricate precision.
If a claim is uncertain, debated, context-dependent, or model-dependent, represent that uncertainty accurately rather than presenting it as settled fact.
## 10. Avoid Generic Filler
Do not create standalone sections titled:
- Why It Matters
- Key Points
- Key Terms
- Summary
- Recap
- Conclusion
- Takeaways
- Fun Facts
unless explicitly requested.
Do not add:
- motivational statements
- generic importance claims
- unnecessary definitions
- repetitive examples
- decorative facts
Every item should teach something substantive about the topic.
## 11. Prevent Duplication
Do not repeat the same fact in multiple modules.
Each important idea should have one primary home.
If concepts interact across modules, show the relationship without restating the original explanation.
Before responding, check the complete blueprint for semantic duplication, not merely identical wording.
Two differently worded bullets conveying the same information still count as duplication.
## 12. Optional Required Titles
If specific module titles are supplied with the topic, prioritize those titles.
Module Mode may be:
AUTO
→ Automatically select 6–8 modules.
REQUIRED
→ Use only the supplied module titles.
HYBRID
→ Use all supplied titles, then add the strongest missing modules up to 6–8 total.
If no Module Mode is specified, use AUTO.
Do not rename, merge, or remove REQUIRED titles.
## 13. Final Quality Check
Before responding, silently verify:
1. factual accuracy
2. appropriate learning depth
3. topic-specific module selection
4. no unnecessary introductory material
5. no duplicated facts
6. no generic filler
7. meaningful relationships
8. useful visual opportunities
9. concise infographic-ready wording
10. no important concept omitted merely to preserve symmetry
Ask internally:
"Does every module contribute a distinct piece of understanding?"
If not, replace or improve the weak module.
## Output
Return only the structured content blueprint.
Do not create the final infographic.
Do not explain your methodology.
Do not add introductory or concluding prose.
Topic: [INSERT TOPIC]
Platform / Technology: [Cisco SD-WAN / SDA / BGP / EVPN / VXLAN / ISE / Catalyst Center / IOS-XE / NX-OS / IOS-XR / Security / etc.]
Level: Principal Network Engineer / CCIE Expert
You are a principal-level network architect, CCIE-level technical instructor, and senior escalation engineer.
Create an authoritative technical content blueprint for advanced handwritten engineering notes about the specified topic.
The audience already understands networking fundamentals. Do NOT spend space explaining basic concepts unless they are necessary to understand an advanced mechanism.
The goal is not introductory education. The goal is to capture the knowledge an experienced network engineer needs to:
- understand the architecture deeply
- reason about control-plane and data-plane behavior
- predict packet and route behavior
- design the technology correctly
- implement and operate it
- verify its actual state
- troubleshoot failures systematically
- understand platform-specific behavior
- recognize design tradeoffs and failure domains
## 1. Determine the Technical Nature of the Topic
Before selecting modules, internally determine what kind of engineering subject this is:
- protocol
- control-plane mechanism
- data-plane mechanism
- architecture
- overlay/underlay system
- routing technology
- switching technology
- security mechanism
- policy framework
- automation/orchestration system
- identity/access-control system
- platform feature
- operational/troubleshooting concept
Use this classification only to select the most technically useful modules.
Do NOT create a generic classification section unless it materially helps the notes.
## 2. Select 6–8 Expert-Level Knowledge Modules
Choose modules dynamically according to the technology.
Prefer engineering-oriented modules such as:
- Architecture / Components
- Control Plane
- Data Plane / Forwarding
- Packet Walk
- Route / Prefix Lifecycle
- Policy Logic
- Policy Processing Order
- Protocol State Machine
- Encapsulation / Headers
- Tables / Databases
- Route Selection
- Signaling / Advertisement
- Underlay vs Overlay
- Identity / Segmentation
- Security Enforcement
- Configuration Logic
- Verification
- Troubleshooting
- Failure Behavior
- Convergence
- Scale / Limits
- Design Tradeoffs
- Platform Nuances
- Interoperability
- Migration Considerations
Do NOT mechanically use these categories.
Choose only the modules that expose the deepest and most useful mechanics of the specific topic.
If packet flow is critical, include a packet walk.
If route propagation is critical, include a route lifecycle.
If policy is critical, include policy processing and directionality.
If multiple tables/databases participate, show how information moves between them.
If the technology has important control-plane/data-plane separation, explicitly expose it.
## 3. Technical Depth Requirements
Explain mechanisms, not merely features.
Prefer:
“OMP route → centralized policy → modified TLOC preference → advertised to edge”
over:
“Centralized policy controls routing.”
Expose important relationships such as:
SOURCE → PROCESS → STATE/TABLE → DECISION → RESULT
and:
CONTROL PLANE → PROGRAMMING → DATA PLANE → PACKET FORWARDING
Where appropriate, identify:
- protocol messages
- route types
- attributes
- TLVs
- tables
- RIB/FIB relationships
- adjacencies
- tunnels
- encapsulation
- headers
- labels/VNIs/tags
- policy direction
- match conditions
- actions
- sequence/order of operations
- route redistribution
- route installation
- forwarding decisions
- authentication/authorization exchanges
- failure detection
- convergence behavior
Do not mention these merely to appear advanced. Include only mechanisms genuinely relevant to the topic.
## 4. Configuration + Operational Reality
Where appropriate, include compact examples of:
- configuration logic
- policy structure
- CLI
- API/YANG objects
- show commands
- debug commands
- packet captures
- controller views
- expected outputs
Configuration examples must demonstrate a concept rather than become long configuration dumps.
Prefer:
show command → expected state → engineering interpretation
Example:
`show bgp l2vpn evpn`
→ Route Type 2 present
→ MAC/IP reachability learned
Verification must answer:
“What proves this mechanism is actually working?”
## 5. Troubleshooting Model
When relevant, include a troubleshooting module based on causal reasoning.
Prefer:
SYMPTOM → CHECK → EXPECTED STATE → FAILURE INDICATION → LIKELY CAUSE
Example structure:
Traffic blackhole
→ route exists in control plane?
→ route installed in FIB?
→ next-hop/tunnel reachable?
→ policy changed forwarding?
→ encapsulation/MTU issue?
Do NOT provide generic advice such as:
“Check connectivity.”
“Verify configuration.”
“Check logs.”
Every troubleshooting step should identify a specific state, table, protocol relationship, counter, command, or packet behavior.
## 6. Failure and Edge Cases
Include subtle behavior that differentiates expert understanding from documentation memorization.
Examples include:
- asymmetric routing
- recursive next-hop failure
- route-policy interaction
- control-plane healthy / data-plane broken
- stale state
- partial convergence
- MTU/fragmentation
- redistribution loops
- route leaking
- policy precedence
- default-route interaction
- overlapping prefixes
- summarization side effects
- ECMP behavior
- failover timing
- controller loss
- tunnel failure
- segmentation boundary mistakes
Include only edge cases genuinely applicable to the topic.
## 7. Design Perspective
When relevant, identify design decisions and tradeoffs.
Use compact contrasts such as:
Centralized ↔ Distributed
Control Plane ↔ Data Plane
Underlay ↔ Overlay
Inbound ↔ Outbound
Local Policy ↔ Centralized Policy
Preferred Path ↔ Backup Path
Scalability ↔ Complexity
Convergence ↔ Stability
Security ↔ Operational Simplicity
Do not declare one design universally “best.” State the technical consequence of each choice.
## 8. Content Format
For each module provide:
### Module Title
A short engineering concept label, not a sentence.
Then provide 3–6 technically dense items.
Each item should normally be one line and approximately 3–14 words.
Use:
- engineering fragments
- protocol notation
- arrows
- compact relationships
- commands
- state transitions
- formulas
- tables
- packet/header fields
- short contrasts
Avoid prose paragraphs.
Examples of preferred style:
`vSmart → OMP policy → Edge route behavior`
`TLOC = system-IP + color + encapsulation`
`match → action → sequence → default-action`
`RIB present ≠ FIB programmed`
`SYN MSS = min(local MSS, advertised MSS)`
## 9. Highlighting Rules
Wrap the most important engineering term, state, value, or relationship in ==double equals==.
Examples:
`OMP route → ==vSmart policy== → Edge`
`RIB present ≠ ==FIB programmed==`
`VPN 0 = ==transport VPN==`
`SGT → ==SGACL== → enforcement`
Use approximately 1–2 highlighted spans per item.
Highlight the shortest meaningful span.
Do not highlight entire sentences.
## 10. Visual Engineering Representation
For every module specify the best technical visual.
Prefer:
- topology
- packet walk
- route propagation diagram
- control-plane flow
- policy decision tree
- protocol state machine
- table relationship
- header breakdown
- encapsulation stack
- timeline
- failure path
- CLI/output annotation
- side-by-side comparison
Visuals must teach behavior, not decorate the page.
Use arrows with explicit meaning.
Examples:
`advertises →`
`installs →`
`encapsulates →`
`matches →`
`drops →`
`redistributes →`
Avoid ambiguous arrows.
## 11. Central Visual
Select one central visual that explains the core mechanism of the entire topic.
For architecture topics:
→ topology/component relationship
For routing topics:
→ route lifecycle
For policy topics:
→ policy pipeline / decision flow
For tunneling topics:
→ packet walk + encapsulation
For security topics:
→ identity → classification → policy → enforcement
For troubleshooting topics:
→ decision tree / dependency chain
The central visual should allow an experienced engineer to reconstruct how the technology works.
## 12. Accuracy Rules
Technical accuracy has priority over visual simplicity.
Maintain strict distinctions between:
- control plane vs data plane
- RIB vs FIB
- configuration vs operational state
- route advertisement vs route installation
- policy definition vs policy activation
- local behavior vs controller behavior
- underlay vs overlay
- packet size vs frame size
- authentication vs authorization
- classification vs enforcement
Do not collapse technically distinct concepts merely to simplify the infographic.
For vendor-specific topics, use terminology appropriate to the stated software/platform and avoid silently mixing behavior from different releases.
If behavior varies by release, architecture, deployment mode, or platform, explicitly mark:
`VERSION / PLATFORM DEPENDENT`
Do not invent commands, timers, defaults, protocol behavior, or scale values.
If uncertain about a specific value, omit it rather than fabricate precision.
## 13. Expert-Level Filtering
Assume the reader already understands:
- OSI/TCP-IP fundamentals
- VLANs
- IPv4/IPv6 basics
- subnetting
- ARP/ND
- basic routing
- basic switching
- standard ACL concepts
Do not consume modules teaching prerequisites unless the topic depends on a subtle aspect of them.
Prioritize information that helps answer:
“How does it actually work?”
“What state exists where?”
“What happens to this route or packet?”
“What changes when this policy is applied?”
“How do I prove it?”
“What breaks if this component fails?”
“What would I inspect during an outage?”
“What design choice changes this behavior?”
## 14. Anti-Filler Rules
Do NOT create sections named:
- Why It Matters
- Benefits
- Key Takeaways
- Summary
- Recap
- Conclusion
- Fun Facts
- Best Practices
unless the topic specifically requires a design-practice comparison.
Do not add generic statements such as:
“Improves network performance.”
“Provides greater scalability.”
“Enhances security.”
“Helps administrators troubleshoot.”
Replace generic claims with the mechanism that produces the result.
## 15. No Duplication
Every technical fact should have one primary home.
Do not repeat the same fact across architecture, packet flow, configuration, and troubleshooting modules.
Instead, show different dimensions of the same mechanism.
Example:
Architecture → where vSmart sits
Control Plane → what vSmart exchanges
Policy → what vSmart modifies
Troubleshooting → how to prove the resulting route state
These are related but non-duplicative.
## 16. Final Technical Review
Before responding, silently review the blueprint as a principal network engineer.
Check for:
1. protocol inaccuracies
2. control-plane/data-plane confusion
3. incorrect directionality
4. incorrect terminology
5. configuration vs operational-state confusion
6. platform/version assumptions
7. duplicated facts
8. generic filler
9. missing packet/route behavior
10. missing verification logic
11. misleading diagrams
12. commands that do not prove the claimed state
Ask internally:
“Would a CCIE-level engineer learn something operationally useful from every module?”
If not, replace the weak content.
## Output
Return only the structured content blueprint.
Do NOT generate the final infographic.
Do NOT explain your methodology.
Do NOT add introductory or concluding prose.
@Create image
Using the content blueprint in your immediately preceding response, create a visually striking handwritten educational infographic.
Aspect Ratio: <ASPECT_RATIO>
Examples:
- 16:9 — landscape
- 4:3 — landscape
- 3:2 — landscape
- 1:1 — square
- 4:5 — portrait
- 3:4 — portrait
- 9:16 — tall portrait
## PRIORITY ORDER
When instructions compete, follow this priority:
1. Content accuracy
2. Preserve blueprint meaning
3. Text completeness and legibility
4. Correct relationships and visual logic
5. Clear information hierarchy
6. Effective use of the requested aspect ratio
7. Visual style and decoration
Never sacrifice technical or factual accuracy to improve appearance.
## 1. BLUEPRINT IS AUTHORITATIVE
Treat the supplied blueprint as the authoritative content source.
Preserve its:
- central topic
- central visual concept
- 6–8 knowledge modules
- module titles
- compact facts
- fragments
- labels
- vocabulary
- dates and numbers
- equations and measurements
- examples
- relationships
- sequences
- comparisons
- marked ==highlight spans==
Do not invent:
- facts
- categories
- modules
- examples
- conclusions
- interpretations
- terminology
- labels
Do not omit important supplied content merely to simplify the layout.
Do not repeat information already presented elsewhere.
Do not create additional sections such as:
- Why It Matters
- Key Points
- Key Terms
- Summary
- Recap
- Conclusion
- Takeaways
If the blueprint does not contain a type of information, do not add it merely to fill space.
## 2. PRESERVE COMPACT WORDING
Reproduce the blueprint's supplied text as faithfully as possible.
Keep fragments as fragments.
Never expand compact text into explanatory prose or paragraphs.
Prefer:
label > sentence
arrow > explanation
symbol > prose
number > verbal description
diagram > paragraph
relationship > repeated definition
Do not add explanatory notes beneath drawings unless supplied by the blueprint.
## 3. ADAPT COMPOSITION TO ASPECT RATIO
Design the composition specifically for the requested Aspect Ratio.
Do NOT simply stretch, crop, or squeeze a fixed layout.
### Wide landscape — 16:9 / 3:2
Use a horizontal knowledge map.
Place the title near the upper center.
Place the central visual near the visual center.
Distribute modules across left, right, upper, and lower regions.
Use horizontal process flows when appropriate.
### Standard landscape — 4:3
Use a balanced radial or asymmetric classroom-board composition.
Allow modules to wrap naturally around the central visual.
### Square — 1:1
Use a compact radial composition.
Reduce unnecessary decorative spacing before reducing text legibility.
### Portrait — 4:5 / 3:4
Use a vertically flowing knowledge map.
Place the title near the top.
Place the central visual in the upper-middle or middle.
Arrange modules above, beside, and below it.
### Tall portrait — 9:16
Use a vertical learning journey.
Allow the central mechanism to extend vertically.
Organize related modules into upper, middle, and lower visual zones.
Regardless of ratio, maintain comfortable margins and prevent text, arrows, diagrams, and doodles from touching or being clipped by the image edges.
## 4. CENTRAL VISUAL
Place the blueprint's supplied central visual representation near the visual center of the composition, directly below, beside, or naturally connected to the title.
It should be the largest individual illustration on the sheet.
Its purpose is to explain the core concept, not merely decorate the page.
Allow its orientation to change according to the aspect ratio.
For example:
horizontal process → landscape
vertical sequence → portrait
cycle → centered
map → dominant central region
system architecture → topology-style center
Do not force a horizontal central visual into a portrait layout or vice versa.
## 5. KNOWLEDGE MODULES
Arrange the 6–8 modules around or along the central visual in a clear visual reading order.
Do NOT number the modules.
Do NOT place numerical markers beside module headers.
Allow modules to occupy slightly different:
- positions
- widths
- heights
- visual shapes
Avoid a strict digital grid.
Each module should contain:
- unnumbered ALL-CAPS handwritten header
- supplied compact content
- 1–3 simple topic-specific doodles when useful
- appropriate diagram/chart/example when supplied or logically represented by the blueprint
- concise labels and annotations
- original ==highlighted spans==
- meaningful visual relationship to the central topic
Not every module needs the same visual treatment.
One may use a process flow.
Another may use a comparison.
Another may use a labelled sketch.
Another may primarily use compact text and arrows.
Let the information determine the representation.
## 6. OPEN SKETCHNOTE STRUCTURE
Do NOT place modules inside rigid:
- cards
- panels
- boxes
- rounded rectangles
- UI containers
- sticker frames
- coloured backgrounds
Separate modules using a varied combination of:
- white space
- short underlines
- partial corners
- rough L-shapes
- dotted dividers
- wavy lines
- cloud-like partial separators
- arrows
- leader lines
- no separator at all
Separators should remain:
- irregular
- slightly wobbly
- incomplete
- open
Never enclose an entire module with a separator.
The only fully enclosed shapes permitted are:
- central title box
- genuine speech/thought bubbles
- small tables when genuinely necessary
- naturally enclosed objects within diagrams
## 7. TITLE TREATMENT
Place the central title inside a simple hand-drawn rectangular box.
Use:
- clean black outline
- white interior
- ALL-CAPS handwritten title
- approximately 2–4 lines when necessary
- orange shaded side and bottom edge
- subtle flat 3D lift
Do NOT use:
- gradients
- glow
- glossy effects
- rendered shadows
- coloured top plane
- elaborate perspective
Reserve this lifted-box treatment exclusively for the title.
## 8. DOODLE STYLE
Draw illustrations like an expert teacher sketching rapidly on a whiteboard.
Use:
- thin black lines
- slightly imperfect strokes
- simple geometry
- recognisable silhouettes
- minimal detail
- contextual visual cues
Objects should use recognisable outlines plus one or two identifying details.
Avoid:
- stock illustrations
- photorealism
- realistic anatomy
- detailed faces
- complex textures
- elaborate perspective
- commercial pictograms
- polished vector graphics
- finished editorial-cartoon styling
## 9. HUMAN FIGURES
When human figures genuinely help explain the topic, draw them as simple line cartoons.
Use:
- round white heads
- clearly visible simple eyes
- minimal expressive mouth
- thin limbs
- simple body shapes
Every person must have at least one visually readable identifier related to:
- role
- occupation
- historical/cultural setting
- activity
- status
- relationship to the topic
Possible identifiers:
- clothing
- tool
- hairstyle
- equipment
- posture
- companion
- contextual object
Vary identifiers across figures.
Do not add people merely for decoration.
## 10. VISUAL RELATIONSHIPS
Create a readable knowledge network using purposeful:
- arrows
- curved arrows
- dashed arrows
- leader lines
- brackets
- pointer marks
- circles
- pathways
Every connector must communicate meaning.
Use arrows to represent supplied relationships such as:
→ sequence
→ transformation
→ cause/effect
→ movement
→ dependency
→ information flow
↔ interaction/comparison
Avoid decorative arrows and unnecessary cross-connections.
When direction matters, make arrow direction unmistakable.
## 11. HIGHLIGHTING
Reproduce every supplied compact bullet, label, date, number, equation, measurement, or fragment.
Highlight only text originally wrapped in ==double equals==.
Do NOT display the `==` characters.
Each marked span receives one continuous translucent marker stroke behind the letters.
Use restrained:
- teal
- orange
- yellow
- muted red
The highlight should appear slightly imperfect and off-register, like a real marker.
Never convert highlights into:
- boxes
- pills
- tags
- badges
- digital selection bars
Keep highlighted words inside their original text.
Never extract highlighted words into separate labels or a glossary.
Never highlight text that was not marked by the blueprint.
## 12. COLOR SYSTEM
Use black or dark charcoal for:
- lettering
- outlines
- arrows
- diagrams
- connectors
Use teal and orange sparingly for:
- marker highlights
- small flat fills
- emphasis
- title-box shaded edge
Use muted red or yellow only when the blueprint contains a genuine:
- warning
- contrast
- critical state
- hierarchy
- exceptional condition
Most of the infographic should remain black ink on white paper.
Do not colour every icon.
Do not fill large regions with colour.
## 13. BACKGROUND
Use pristine bright white paper.
No:
- ruled lines
- grid
- notebook pattern
- beige tint
- cream tone
- parchment
- grey cast
- paper texture
- coloured section backgrounds
Maintain generous white space.
White space is part of the visual hierarchy, not unused space.
## 14. TABLES, QUOTES, AND SPECIAL ELEMENTS
When information is genuinely tabular, use a small plain table with:
- thin hand-drawn rules
- compact entries
- minimal styling
Use speech or thought bubbles only for quotations or thoughts explicitly supplied by the blueprint.
Do not invent quotations.
Do not create fake text, pseudo-writing, placeholder labels, or irrelevant words.
## 15. TEXT ACCURACY
Use clear, legible English.
Accurately reproduce supplied:
- titles
- terminology
- names
- dates
- numbers
- measurements
- equations
- labels
- annotations
Use distinctive ALL-CAPS handwritten printing for major headers.
Use clean compact handwritten lettering elsewhere.
Do not intentionally misspell words to imitate handwriting.
## 16. DENSITY MANAGEMENT
If the blueprint contains substantial information, preserve educational content before decorative elements.
When space becomes constrained, reduce in this order:
1. decorative doodles
2. decorative separators
3. redundant visual embellishment
4. doodle size
5. spacing where safe
Preserve:
- factual content
- module titles
- critical diagrams
- relationships
- labels
- highlighted terms
- text legibility
Never solve overcrowding by turning the infographic into tiny unreadable text.
## 17. FINAL VISUAL CHARACTER
The finished image should feel like:
an exceptionally knowledgeable teacher or subject-matter expert created a dense but highly organized handwritten teaching sheet on a clean whiteboard.
Visual Style:
==loose handwritten classroom sketchnote==
==bright white background==
==open asymmetric composition==
==simple contextual line drawings==
==restrained teal + orange accents==
==purposeful diagrams and arrows==
==compact expert information==
==highly legible text==
Avoid a:
- corporate infographic
- slide deck
- dashboard
- UI design
- textbook page
- poster template
- clip-art collection
- polished vector illustration
Before rendering, internally verify:
- all modules are represented
- no module is duplicated
- central visual matches the blueprint
- relationships remain accurate
- important supplied text is present
- highlighted spans remain in context
- no invented educational content was added
- layout suits the requested aspect ratio
- text remains readable
- nothing important is clipped
Create the infographic directly from the blueprint.
Paste image on different LLM and have it cross check.
@Create image
Using the content blueprint in your immediately preceding response, create a visually striking handwritten educational infographic.
Aspect Ratio: <ASPECT_RATIO>
Examples:
- 16:9 — landscape
- 4:3 — landscape
- 3:2 — landscape
- 1:1 — square
- 4:5 — portrait
- 3:4 — portrait
- 9:16 — tall portrait
## PRIORITY ORDER
When instructions compete, follow this priority:
1. Content accuracy
2. Preserve blueprint meaning
3. Text completeness and legibility
4. Correct relationships and visual logic
5. Clear information hierarchy
6. Effective use of the requested aspect ratio
7. Visual style and decoration
Never sacrifice technical or factual accuracy to improve appearance.
## 1. BLUEPRINT IS AUTHORITATIVE
Treat the supplied blueprint as the authoritative content source.
Preserve its:
- central topic
- central visual concept
- 6–8 knowledge modules
- module titles
- compact facts
- fragments
- labels
- vocabulary
- dates and numbers
- equations and measurements
- examples
- relationships
- sequences
- comparisons
- marked ==highlight spans==
Do not invent:
- facts
- categories
- modules
- examples
- conclusions
- interpretations
- terminology
- labels
Do not omit important supplied content merely to simplify the layout.
Do not repeat information already presented elsewhere.
Do not create additional sections such as:
- Why It Matters
- Key Points
- Key Terms
- Summary
- Recap
- Conclusion
- Takeaways
If the blueprint does not contain a type of information, do not add it merely to fill space.
## 2. PRESERVE COMPACT WORDING
Reproduce the blueprint's supplied text as faithfully as possible.
Keep fragments as fragments.
Never expand compact text into explanatory prose or paragraphs.
Prefer:
label > sentence
arrow > explanation
symbol > prose
number > verbal description
diagram > paragraph
relationship > repeated definition
Do not add explanatory notes beneath drawings unless supplied by the blueprint.
## 3. ADAPT COMPOSITION TO ASPECT RATIO
Design the composition specifically for the requested Aspect Ratio.
Do NOT simply stretch, crop, or squeeze a fixed layout.
### Wide landscape — 16:9 / 3:2
Use a horizontal knowledge map.
Place the title near the upper center.
Place the central visual near the visual center.
Distribute modules across left, right, upper, and lower regions.
Use horizontal process flows when appropriate.
### Standard landscape — 4:3
Use a balanced radial or asymmetric classroom-board composition.
Allow modules to wrap naturally around the central visual.
### Square — 1:1
Use a compact radial composition.
Reduce unnecessary decorative spacing before reducing text legibility.
### Portrait — 4:5 / 3:4
Use a vertically flowing knowledge map.
Place the title near the top.
Place the central visual in the upper-middle or middle.
Arrange modules above, beside, and below it.
### Tall portrait — 9:16
Use a vertical learning journey.
Allow the central mechanism to extend vertically.
Organize related modules into upper, middle, and lower visual zones.
Regardless of ratio, maintain comfortable margins and prevent text, arrows, diagrams, and doodles from touching or being clipped by the image edges.
## 4. CENTRAL VISUAL
Place the blueprint's supplied central visual representation near the visual center of the composition, directly below, beside, or naturally connected to the title.
It should be the largest individual illustration on the sheet.
Its purpose is to explain the core concept, not merely decorate the page.
Allow its orientation to change according to the aspect ratio.
For example:
horizontal process → landscape
vertical sequence → portrait
cycle → centered
map → dominant central region
system architecture → topology-style center
Do not force a horizontal central visual into a portrait layout or vice versa.
## 5. KNOWLEDGE MODULES
Arrange the 6–8 modules around or along the central visual in a clear visual reading order.
Do NOT number the modules.
Do NOT place numerical markers beside module headers.
Allow modules to occupy slightly different:
- positions
- widths
- heights
- visual shapes
Avoid a strict digital grid.
Each module should contain:
- unnumbered ALL-CAPS handwritten header
- supplied compact content
- 1–3 simple topic-specific doodles when useful
- appropriate diagram/chart/example when supplied or logically represented by the blueprint
- concise labels and annotations
- original ==highlighted spans==
- meaningful visual relationship to the central topic
Not every module needs the same visual treatment.
One may use a process flow.
Another may use a comparison.
Another may use a labelled sketch.
Another may primarily use compact text and arrows.
Let the information determine the representation.
## 6. OPEN SKETCHNOTE STRUCTURE
Do NOT place modules inside rigid:
- cards
- panels
- boxes
- rounded rectangles
- UI containers
- sticker frames
- coloured backgrounds
Separate modules using a varied combination of:
- white space
- short underlines
- partial corners
- rough L-shapes
- dotted dividers
- wavy lines
- cloud-like partial separators
- arrows
- leader lines
- no separator at all
Separators should remain:
- irregular
- slightly wobbly
- incomplete
- open
Never enclose an entire module with a separator.
The only fully enclosed shapes permitted are:
- central title box
- genuine speech/thought bubbles
- small tables when genuinely necessary
- naturally enclosed objects within diagrams
## 7. TITLE TREATMENT
Place the central title inside a simple hand-drawn rectangular box.
Use:
- clean black outline
- white interior
- ALL-CAPS handwritten title
- approximately 2–4 lines when necessary
- orange shaded side and bottom edge
- subtle flat 3D lift
Do NOT use:
- gradients
- glow
- glossy effects
- rendered shadows
- coloured top plane
- elaborate perspective
Reserve this lifted-box treatment exclusively for the title.
## 8. DOODLE STYLE
Draw illustrations like an expert teacher sketching rapidly on a whiteboard.
Use:
- thin black lines
- slightly imperfect strokes
- simple geometry
- recognisable silhouettes
- minimal detail
- contextual visual cues
Objects should use recognisable outlines plus one or two identifying details.
Avoid:
- stock illustrations
- photorealism
- realistic anatomy
- detailed faces
- complex textures
- elaborate perspective
- commercial pictograms
- polished vector graphics
- finished editorial-cartoon styling
## 9. HUMAN FIGURES
When human figures genuinely help explain the topic, draw them as simple line cartoons.
Use:
- round white heads
- clearly visible simple eyes
- minimal expressive mouth
- thin limbs
- simple body shapes
Every person must have at least one visually readable identifier related to:
- role
- occupation
- historical/cultural setting
- activity
- status
- relationship to the topic
Possible identifiers:
- clothing
- tool
- hairstyle
- equipment
- posture
- companion
- contextual object
Vary identifiers across figures.
Do not add people merely for decoration.
## 10. VISUAL RELATIONSHIPS
Create a readable knowledge network using purposeful:
- arrows
- curved arrows
- dashed arrows
- leader lines
- brackets
- pointer marks
- circles
- pathways
Every connector must communicate meaning.
Use arrows to represent supplied relationships such as:
→ sequence
→ transformation
→ cause/effect
→ movement
→ dependency
→ information flow
↔ interaction/comparison
Avoid decorative arrows and unnecessary cross-connections.
When direction matters, make arrow direction unmistakable.
## 11. HIGHLIGHTING
Reproduce every supplied compact bullet, label, date, number, equation, measurement, or fragment.
Highlight only text originally wrapped in ==double equals==.
Do NOT display the `==` characters.
Each marked span receives one continuous translucent marker stroke behind the letters.
Use restrained:
- teal
- orange
- yellow
- muted red
The highlight should appear slightly imperfect and off-register, like a real marker.
Never convert highlights into:
- boxes
- pills
- tags
- badges
- digital selection bars
Keep highlighted words inside their original text.
Never extract highlighted words into separate labels or a glossary.
Never highlight text that was not marked by the blueprint.
## 12. COLOR SYSTEM
Use black or dark charcoal for:
- lettering
- outlines
- arrows
- diagrams
- connectors
Use teal and orange sparingly for:
- marker highlights
- small flat fills
- emphasis
- title-box shaded edge
Use muted red or yellow only when the blueprint contains a genuine:
- warning
- contrast
- critical state
- hierarchy
- exceptional condition
Most of the infographic should remain black ink on white paper.
Do not colour every icon.
Do not fill large regions with colour.
## 13. BACKGROUND
Use pristine bright white paper.
No:
- ruled lines
- grid
- notebook pattern
- beige tint
- cream tone
- parchment
- grey cast
- paper texture
- coloured section backgrounds
Maintain generous white space.
White space is part of the visual hierarchy, not unused space.
## 14. TABLES, QUOTES, AND SPECIAL ELEMENTS
When information is genuinely tabular, use a small plain table with:
- thin hand-drawn rules
- compact entries
- minimal styling
Use speech or thought bubbles only for quotations or thoughts explicitly supplied by the blueprint.
Do not invent quotations.
Do not create fake text, pseudo-writing, placeholder labels, or irrelevant words.
## 15. TEXT ACCURACY
Use clear, legible English.
Accurately reproduce supplied:
- titles
- terminology
- names
- dates
- numbers
- measurements
- equations
- labels
- annotations
Use distinctive ALL-CAPS handwritten printing for major headers.
Use clean compact handwritten lettering elsewhere.
Do not intentionally misspell words to imitate handwriting.
## 16. DENSITY MANAGEMENT
If the blueprint contains substantial information, preserve educational content before decorative elements.
When space becomes constrained, reduce in this order:
1. decorative doodles
2. decorative separators
3. redundant visual embellishment
4. doodle size
5. spacing where safe
Preserve:
- factual content
- module titles
- critical diagrams
- relationships
- labels
- highlighted terms
- text legibility
Never solve overcrowding by turning the infographic into tiny unreadable text.
## 17. FINAL VISUAL CHARACTER
The finished image should feel like:
an exceptionally knowledgeable teacher or subject-matter expert created a dense but highly organized handwritten teaching sheet on a clean whiteboard.
Visual Style:
==loose handwritten classroom sketchnote==
==bright white background==
==open asymmetric composition==
==simple contextual line drawings==
==restrained teal + orange accents==
==purposeful diagrams and arrows==
==compact expert information==
==highly legible text==
Avoid a:
- corporate infographic
- slide deck
- dashboard
- UI design
- textbook page
- poster template
- clip-art collection
- polished vector illustration
Before rendering, internally verify:
- all modules are represented
- no module is duplicated
- central visual matches the blueprint
- relationships remain accurate
- important supplied text is present
- highlighted spans remain in context
- no invented educational content was added
- layout suits the requested aspect ratio
- text remains readable
- nothing important is clipped
Create the infographic directly from the blueprint.
If content too big and you need multiple images
## MULTI-PART OUTPUT
Output Mode: <SINGLE_PAGE | MULTI_PART>
Number of Parts: <AUTO | NUMBER>
If SINGLE_PAGE:
Create the normal 6–8 module blueprint for one infographic.
If MULTI_PART:
Divide the topic into multiple coherent infographic parts.
If Number of Parts is AUTO, determine the smallest number of parts needed to explain the topic clearly without overcrowding.
Each part must have:
- a distinct technical or conceptual purpose
- its own short title
- its own central visual
- approximately 4–7 tightly related knowledge modules
- a clear relationship to the overall topic
- enough context to be understandable independently
- no unnecessary repetition from another part
Do NOT divide parts merely to achieve equal module counts.
Split according to conceptual boundaries, mechanisms, stages, perspectives, or learning progression.
Prefer:
FOUNDATION → MECHANISM → OPERATION → TROUBLESHOOTING
rather than:
PART 1 → first half of facts
PART 2 → second half of facts
For complex topics, use progressive depth when appropriate:
Part 1 → architecture / mental model
Part 2 → internal mechanism / flow
Part 3 → implementation / operation
Part 4 → troubleshooting / failure / design
Do not repeat complete definitions across parts.
A concept introduced in an earlier part may be referenced briefly in a later part when necessary for continuity.
For each part provide:
### PART <N> — <TITLE>
**Purpose:** <one compact description>
**Central Visual:** <best visual representation>
**Modules:**
<structured modules using all existing blueprint rules>
At the end, provide:
### SERIES FLOW
PART 1 → PART 2 → PART 3 → ...
Use short labels showing the conceptual progression.
Do not generate the infographic images yet.
Brainstorming Prompts
Help me achieve [outcome]. Here is the context: [context]. Use [inputs]. Respect [constraints]. Produce [format]. Check it against [success criteria]. Flag uncertainty, and ask only questions that would materially change the result.I’m planning to [describe plan]. Review it as a skeptical but constructive expert. Identify hidden assumptions, dependencies, failure modes, and missing information. Rank the five most consequential issues. For each, suggest a practical way to validate or reduce the risk. Don’t invent objections just to fill the list.Analyze these logs, counters, and timestamps. Separate observations from interpretations. Rank plausible causes by supporting and contradicting evidence. For each cause, give the next test, expected results, and what would weaken the hypothesis. Don’t declare a root cause without sufficient evidence. Here is the data: [paste].Help me decide between [A], [B], and doing nothing. Consider my constraints: [constraints]. Compare benefits, costs, reversibility, dependencies, and uncertainty. Explain what would need to be true for each option to win. Recommend one and identify the missing fact most likely to change your recommendation.Convert the following technical situation into an executive SBAR. Preserve the distinction between confirmed impact and potential risk. Explain the business consequence, decision needed, recommendation, and consequence of deferring. Don’t invent financial figures or outage probabilities. Keep it under 250 words: [details].Role-play my [manager/vendor/project stakeholder] in a conversation about [issue]. Your priorities are [priorities], and mine are [priorities]. Respond realistically and challenge weak arguments. After each of my replies, briefly coach me on clarity, evidence, and tone, then continue the conversation.