processon-mindmap

Mind-Map Modeling

Produce a faithful, browsable hierarchy before handing it to processon-prompt. One node communicates one idea.

Structure selection

Structure	Use when
mind_free	Central topic, brainstorming, broad knowledge classification
mind_right	Linear outline, learning path, proposal, ordered reasoning
mind_org	Department, role, reporting, or genealogy hierarchy
mind_ishikawa_left	Root-cause analysis and contributing factors
mind_timeline_h	Milestones, history, roadmap, or staged evolution
mind_tree_free	WBS, deliverable decomposition, taxonomy
mind_treeTable_left_title	Comparable attributes, parameter inventory, structured classification table

These identifiers are ProcessOn structure concepts, not current MCP parameters. The official MCP tool accepts only prompt; express the selected structure in that prompt without inventing a field.

Content transformation

1. Identify one root topic from the user's objective and source material.
2. Preserve authoritative headings and their parent-child relationships.
3. Merge duplicates and separate genuinely independent branches.
4. Condense leaf content to one short claim, fact, action, or question.
5. Keep hierarchy continuous; do not skip levels.
6. Prefer three to seven top-level branches unless the source requires otherwise.
7. Pass root, branches, leaves, cross-links, selected structure, and style preference to processon-prompt.

Quality rules

• Apply MECE where it fits, but preserve source truth over forced symmetry.
• Keep siblings grammatically parallel and similar in detail.
• Move long explanation outside nodes; do not paste paragraphs into a branch.
• Use cross-links only when they materially improve understanding.
• For fishbone analysis, distinguish observed causes from hypotheses.
• For WBS, describe deliverables or outcomes rather than vague activities.
• For timelines, label dates, phases, and milestone outcomes consistently.

Visual defaults and customization

Use balanced branch density, consistent depth, restrained colors by top-level branch, readable node spacing, and a clear center or root. Accept preferences for orientation, palette, density, audience, presentation tone, and whether icons should identify categories. Do not use decorative emoji or images unless they improve recognition.

Accuracy, privacy, and boundaries

• Read supplied material before summarizing it; do not infer unavailable document contents.
• Do not invent conclusions, evidence, dates, owners, or priorities.
• Never include credentials, private local paths, or unrelated personal information.
• If the input is a process, interaction, data schema, or runtime architecture, route to processon-diagram instead.
• If the goal is a report-ready comparison or visual story rather than knowledge navigation, route to processon-infographic.

Chinese starter examples

• "Organize this proposal into a logic diagram that expands to the right, keeping the original sections and compressing the leaf-level content."
• "Use a fishbone diagram to analyze possible causes of the decline in the online model's accuracy, distinguishing facts from hypotheses to be verified."
• "Break the project down into a deliverable-oriented WBS tree diagram."

Return the hierarchy 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: Convert text, documents, plans, and knowledge into a concise ProcessOn mind map, logic map, organization map, fishbone, timeline, WBS tree, or tree table. Use for hierarchical knowledge and structured understanding, not process or interaction diagrams..

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 the request identifier and stage status; when the result is unclear, query first rather than 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: 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 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 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 writes, payments, publications, 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, then decide whether to retry.
3. Implicit scope expansion: batch, full-volume, publication, 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 test results 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 a request requires another skill, do not copy its content; hand off by skill name and preserve the current task context.

Progressive disclosure

• When inputs/outputs, states, and authorization points need to be determined, read references/workflow-contract.md。
• When pre-delivery self-checks are needed, read references/validation-checklist.md。
• When encountering timeouts, partial success, or recovery scenarios, read references/error-recovery.md。
• For first runs, refusal of privilege escalation, and failure recovery, refer to examples/happy-path.md、examples/boundary-refusal.md、examples/failure-recovery.md。