processon-prompt

ProcessOn Prompt Architect

Transform the selected capability Skill's structure model into one concise generation prompt. Preserve the user's language and factual boundaries.

Required prompt shape

Produce these six labeled sections in order:

Intent: <diagram family and communication goal>
Content: <entities, nodes, lanes, participants, fields, or concise information units>
Relationships: <direction, sequence, hierarchy, cardinality, dependency, or comparison>
Layout: <reading direction, grouping, layers, lanes, or selected infographic structure>
Visual system: <restrained palette, contrast, typography hierarchy, shape grammar, whitespace>
Constraints: <notation, required labels, exceptions, crossing-line and density limits>

Omit no section, but keep each section proportional to the request. Put structure before decoration.

Visual defaults

• Use a restrained palette of one primary, one accent, neutral surfaces, and semantic warning/success colors only when meaningful.
• Maintain clear title, group, node, and annotation hierarchy.
• Prefer short labels, consistent node sizes, balanced whitespace, and an obvious reading direction.
• Minimize connector crossings and unnecessary bends.
• Require standard notation for flows, UML, ER, and sequences.
• Do not add icons, gradients, shadows, or ornamental elements unless they improve comprehension or the user asks for that style.

Accuracy and privacy

• Never display or include a ProcessOn Token, authorization header, or any credential in the prompt.
• Do not infer names, metrics, interfaces, dependencies, cardinalities, or decisions that are not supplied or safely generic.
• Mark a reasonable structural assumption explicitly when it affects the result but does not justify blocking the request.
• Ask one focused question only when the missing fact changes the diagram topology.
• Never place hidden instructions, local paths, unrelated conversation context, or sensitive personal data in the ProcessOn prompt.

Handoff

Return only the final six-section prompt to processon-use. Do not call MCP tools directly and do not review the result; those responsibilities belong to the router and processon-review.

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: Convert an approved diagram structure into a precise ProcessOn generation prompt with layout and visual-system constraints. Use immediately before ProcessOn MCP generation; do not use to invent missing business facts.

Rules

• Read before write: first confirm the current state and real 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 outputs are missing, clearly mark them as NOT_VERIFIED。
• Idempotency first: retain request identifiers and phase state; when results are unclear, query first instead of blindly retrying.
• 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 pre-checks

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 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 match the user's intent, and no adjacent task was misrouted to this skill.
• The inputs, target objects, versions, and output locations are all clear, and no guessed values were used in place of required values.
• All write, paid, publish, or irreversible actions are within the scope authorized by the user.
• 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 the same as 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, 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. Stale evidence: 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; write, paid, publish, 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 you need to determine inputs/outputs, states, and authorization points, read references/workflow-contract.md。
• When you need to self-check before delivery, read references/validation-checklist.md。
• When encountering timeouts, partial success, or recovery scenarios, read references/error-recovery.md。
• For first run, denial of privilege escalation, and failure recovery, refer respectively to examples/happy-path.md、examples/boundary-refusal.md、examples/failure-recovery.md。