processon-infographic

Infographic Modeling

Select layout from the information relationship, then build concise content and a coherent visual system for processon-prompt.

Relationship-to-layout map

Information relationship	Preferred layout
Two or more alternatives	comparison columns or split comparison
Repeating stages or feedback	cycle or ring
Two dimensions or four themes	matrix or quadrant
Ordered maturity or growth	staircase, S-curve, or rising path
Ranked levels or narrowing focus	pyramid or cone
One center with peer themes	radial or ray layout
Short ordered story	single row or single column
Equal categories or compact metrics	multi-row grid

The documented ProcessOn family also includes multi-column, multi-row, circular, S-shaped, stepped, conical, matrix, ray, comparison, and cyclic structures. Use the simplest layout that communicates the relationship.

Content model

1. Define one communication objective and one title.
2. Extract three to seven primary information units.
3. Give each unit a short heading and one concise fact, metric, or action.
4. Identify ordering, comparison axes, center relationship, or cycle direction.
5. Remove repeated prose and decorative filler.
6. Add a source or scope note when metrics could be misunderstood.
7. Pass content units, relationship, layout, audience, and style to processon-prompt.

Visual system

• Use one dominant focal point and predictable scan order.
• Keep category colors consistent and contrast accessible.
• Prefer flat shapes, clear whitespace, short labels, and restrained icon use.
• Use numeric emphasis only for real metrics supplied by the user.
• Avoid gradients, 3D effects, excessive shadows, and unrelated stock imagery unless explicitly requested and readability remains intact.
• For executive material, reduce density; for operational material, preserve actionable detail.

Accuracy and boundaries

• Do not invent percentages, rankings, research findings, or business outcomes.
• Do not force chronological content into a comparison or independent themes into a cycle.
• Ask one question only if the missing audience, dimensions, or ordering changes the layout.
• Never include credentials, private identifiers, or unrelated context in the prompt.
• Route processes and technical notation to processon-diagram; route deep hierarchical knowledge to processon-mindmap.

Chinese starter examples

• "Turn Agent production readiness into a four-quadrant infographic of quality, security, reliability, and operations."
• "Turn the five stages of a product from pilot to scale into a staircase infographic."
• "Turn three technical solutions into a comparison infographic by cost, performance, risk, and maintainability."

Return the content-layout model to the router; do not call ProcessOn directly.

When to use

Load this skill when the user needs to select and execute a verifiable, recoverable professional workflow for the current request . First extract the goal, inputs, constraints, delivery format, and acceptance criteria from the request; the description summary is: Model report-ready ProcessOn infographics by matching comparison, cycle, matrix, progression, hierarchy, and radial relationships to an appropriate visual layout. Use for concise communication visuals, not technical notation or deep knowledge navigation.

Rules

• Read before write: first confirm the current state and actual capabilities, then perform actions that change external state.
• Least privilege: use only the files, tools, accounts, and network scope required to complete the current step.
• Evidence first: when run results, resource IDs, versions, hashes, or test output are missing, clearly mark them as NOT_VERIFIED。
• Idempotency first: retain request identifiers and stage status; when results are unclear, query first and do not retry blindly.
• Privacy and security: logs, examples, receipts, and error messages must not contain tokens, cookies, keys, or personally sensitive data.

Workflow

Step 1: Clarify intent

Confirm whether this skill matches the goal; if it is only an adjacent need, hand it off to a more precise skill.

Step 2: Perform prechecks

Confirm the goal, inputs, constraints, available tools, success criteria, and failure boundaries; if any key condition is unknown, stop at the read-only stage.

Step 3: Form a plan

List the tools to be called, the objects that will change, the success criteria, and the safe exit method after failure.

Step 4: Execute actions

Execute in the minimum sufficient steps and record evidence at key state changes; retain an associable status or receipt for every external call.

Step 5: Verify delivery

Output the results, verification evidence, unfinished items, risks, and clear next steps, and state facts, inferences, and unverified items separately.

Validation checklist

• The skill trigger conditions are consistent with the user's intent, and adjacent tasks have not been misrouted to this skill.
• The inputs, target objects, versions, and output locations are all clear, and no guessed values have been used in place of required values.
• All write, paid, publish, or irreversible actions are within the scope of user authorization.
• The results have been verified with independent checks; "command succeeded" or "file exists" alone does not count as complete acceptance.
• The output includes actual evidence, failed/skipped items, remaining risks, and executable next steps.

Gotchas

1. Mistaking the plan for the result: a document or prompt is not equal to actual execution; the actual execution level must be indicated.
2. Retrying on error: a timeout or lost response may already have produced remote state; query first before deciding whether to retry.
3. Implicit scope expansion: batch, full-volume, publish, overwrite, and paid operations are not natural extensions of ordinary reads and writes.
4. Version drift: when referencing external resources, record the version, tag, or commit; do not treat a mutable branch as release evidence.
5. Evidence expired: Caches, old screenshots, and historical tests cannot prove the current environment; refresh key evidence before delivery.

Non-applicability and boundaries

Do not exceed the scope given by the user; writes, payments, publishing, and irreversible actions require explicit authorization. If the request requires another skill, do not copy its body text; hand off by skill name and preserve the current task context.

Progressive disclosure

• When input/output, state, and authorization points need to be determined, read references/workflow-contract.md。
• When pre-delivery self-check is needed, read references/validation-checklist.md。
• When encountering timeouts, partial success, or recovery scenarios, read references/error-recovery.md。
• For first run, privilege escalation refusal, and failure recovery, refer to examples/happy-path.md、examples/boundary-refusal.md、examples/failure-recovery.md。