processon-diagram

Professional Diagram Modeling

Turn user facts into a topology that processon-prompt can express precisely. Focus on relationships and runtime meaning, not decoration.

Select the diagram family

User intent	Family	Required model
Process, decisions, exceptions	Flowchart	start/end, actions, decisions, labeled outcomes
Cross-role process	Swimlane	lanes, owners, handoffs, decisions, exceptions
Ordered system interaction	Sequence diagram	participants, messages, returns, alternatives, failures
System composition or deployment	Architecture	boundaries, components, dependencies, protocols, data/control flows, trust zones
Data model	ER diagram	entities, key fields, PK/FK, cardinality, optionality
Software types and behavior	UML class/state/use-case/requirement	standard UML semantics for the requested view
Reporting hierarchy	Organization chart	roles, reporting lines, groups, vacant/shared roles
Ownership or control	Equity/relationship diagram	subjects, percentages or relation labels, direction
Milestones and evolution	Timeline	dates/phases, milestones, outcomes
Business analysis	SWOT, PEST, pyramid	named dimensions, concise evidence, priority

Honor an explicit family unless it cannot represent the requested relationship. Explain any necessary mapping.

Structure workflow

1. Extract facts without changing meaning.
2. Create a compact list of nodes or participants.
3. Define every meaningful relationship and its direction or label.
4. Separate the primary path from exceptions, optional flows, and annotations.
5. Choose orientation and grouping from the topology.
6. Pass the structure to processon-prompt.

Family-specific rules

• Flowchart: use one start and at least one explicit end; decisions are questions with labeled outcomes; do not hide error paths in prose.
• Swimlane: each action belongs to exactly one accountable lane; show handoffs at lane boundaries; avoid a lane per individual unless required.
• Sequence: time runs top to bottom; distinguish synchronous calls, asynchronous messages, replies, loops, and alternatives.
• Architecture: default to an architecture block diagram with large labeled components inside explicit layers or boundaries. Show runtime or deployment boundaries, dependencies, protocols, trust zones, data/control direction, resilience, and observability where relevant. Do not use UML class tables, attribute rows, method compartments, or placeholder field types unless the user explicitly requests a class diagram. Never substitute a directory tree.
• ER: include only decision-relevant fields; mark primary and foreign keys; label one-to-one, one-to-many, or many-to-many cardinality and optionality.
• UML: choose one view that answers the question; do not mix class, state, use-case, and sequence notation on one canvas.
• Organization/equity: separate reporting, ownership, governance, and collaboration relations; label ambiguous edges.
• Timeline: use a consistent time scale or explicitly label non-linear phases.
• SWOT/PEST: facts stay in the correct dimension and are phrased as concise evidence, not slogans.

Visual constraints

Use a clear reading direction, restrained palette, consistent shapes for equivalent semantics, adequate contrast, short labels, balanced whitespace, and minimal connector crossings. Use semantic colors sparingly for success, warning, risk, or ownership.

Accuracy, privacy, and boundaries

• Do not invent components, protocols, owners, cardinalities, dates, percentages, or metrics.
• Ask one question only when a missing answer changes topology; otherwise state a conservative assumption.
• Never include credentials, local paths, private identifiers, or unrelated context in the generation prompt.
• If source code or documents are required, inspect them before modeling; a filename list is not architecture evidence.
• If the current MCP cannot edit an existing file, offer a new diagram based on supplied content and disclose the limitation.

Chinese starter examples

• "Draw a standard flowchart that includes login, risk control, payment failure, and compensation paths."
• "Draw the AI launch process for product, algorithm, backend, testing, and operations as a swimlane diagram."
• "Draw a runtime architecture diagram based on the current source code, marking protocols, trust boundaries, data flows, and failure recovery."

Return the structure 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 professional ProcessOn flowcharts, swimlanes, UML and sequence diagrams, architecture and ER diagrams, organization and equity charts, timelines, and business-analysis diagrams. Use after the ProcessOn router selects a professional diagram rather than a mind map or infographic.

Rules

• Read before write: first confirm the current state and real capabilities, then execute 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, explicitly mark them as NOT_VERIFIED。
• Idempotency first: retain request identifiers and phase state; when the result is 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: Run 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 state or receipt for every external call.

Step 5: Verify delivery

Output results, verification evidence, incomplete 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 were not misrouted to this skill.
• The inputs, target objects, versions, and output locations are all clear, and no guessed values were used to replace 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. Erroneous retry: 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 is stale: 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 respectively to examples/happy-path.md、examples/boundary-refusal.md、examples/failure-recovery.md。