Messy Idea To System Diagram

Turns a messy idea with many moving parts into a one-page node-and-flow system diagram with grouped themes, labeled relationships, a legend, and explicit unknowns. Use when the user wants to see how parts of an idea, project, plan, product, story, research topic, or organization relate before deciding what to do next.

Overview

Use this prompt-only skill when a user has an idea with many moving parts and wants to see the system. The output is a visual thinking artifact: a one-page node-and-flow diagram plus a legend, not a final strategy, diagnosis, architecture, or decision framework.

The goal is to make relationships visible. Preserve uncertainty. Label guesses, inferred links, weak evidence, missing parts, and unknown ownership so the diagram does not create false certainty.

When to Use

Use this skill when the user asks to:

• turn a messy idea into a system diagram
• visualize moving parts, relationships, loops, dependencies, or flows
• map a project, product, story world, research topic, business model, community, workflow, or plan
• see how concepts, actors, resources, decisions, risks, or outcomes connect
• create a concept relationship map before prioritizing or deciding
• produce a one-page diagram and legend from scattered notes

Trigger phrases include: "my idea has many moving parts", "help me see the system", "turn this into a diagram", "map the relationships", "make a node-and-flow map", "visualize this idea", and "concept relationship map".

Required Inputs

Ask only for missing information that blocks a useful first diagram:

• The raw idea, notes, bullets, transcript, or rough explanation
• The intended audience or purpose for the diagram
• The main outcome, question, or thing the user wants to understand
• Known actors, components, inputs, outputs, constraints, risks, or feedback loops
• Preferred format if relevant: Mermaid, ASCII, outline, slide-ready text, or whiteboard brief

If the user provides incomplete material, proceed with a provisional diagram and mark assumptions clearly.

Workflow

1. Capture the parts. Extract named actors, components, resources, actions, decisions, constraints, signals, risks, outputs, and outcomes from the user's material.
2. Normalize names. Merge duplicates, rename vague labels into short noun phrases, and keep the user's original wording when it carries meaning.
3. Group themes. Cluster related parts into three to seven zones such as users, inputs, process, infrastructure, incentives, risks, outputs, feedback, or context.
4. Draw links. Connect nodes with directional relationships. Label each link with a verb or flow type such as funds, informs, blocks, depends on, produces, governs, triggers, or learns from.
5. Mark confidence. Label each node and link as known, inferred, guessed, unknown, contested, or needs evidence when appropriate.
6. Find loops and bottlenecks. Identify feedback loops, reinforcing cycles, handoffs, single points of failure, unclear ownership, and places where information or value changes form.
7. Create the one-page diagram. Produce a compact node-and-flow diagram in the requested format or in Mermaid by default when no format is specified.
8. Add a legend. Explain node types, link meanings, confidence labels, and any visual notation used.
9. Summarize what the diagram reveals. Offer a short reading of patterns, unknowns, and the next questions to test. Do not overstate conclusions.

Output Format

Default to the following structure:

1. Diagram Brief
   • Purpose
   • Scope
   • Audience
   • Confidence note
2. One-Page Node-and-Flow Diagram
   • Mermaid flowchart by default, or ASCII/outline if Mermaid is not useful
   • Nodes grouped into labeled zones
   • Directional links with short labels
   • Unknowns and guesses visibly marked
3. Legend
   • Node categories
   • Link labels
   • Confidence markers
   • Boundary markers
4. Reading the System
   • Main flows
   • Feedback loops
   • Bottlenecks or fragile handoffs
   • Missing information
5. Questions to Verify
   • Three to seven concrete questions that would improve the diagram
6. Optional Next Version
   • What to add if the user wants a stakeholder map, workflow map, technical architecture, business model, or implementation plan later

Diagram Conventions

Use concise labels so the diagram stays readable:

• Use rectangles for components, actors, or work areas.
• Use diamonds only for decision points when the format supports them.
• Use grouped subgraphs for themes or zones.
• Mark unknowns with (unknown) or [?].
• Mark inferred relationships with (inferred).
• Mark guessed relationships with (guess).
• Use verbs on edges whenever possible.
• Keep the first diagram small enough to scan in one view.

For Mermaid output, prefer flowchart LR for relationship maps and flowchart TD for process-heavy maps. Avoid complex styling unless it improves clarity.

Boundaries

• This is a visual thinking artifact only. It does not prove causality, feasibility, legality, safety, market demand, technical correctness, or organizational truth.
• Do not present guesses, inferred links, or user-supplied claims as facts.
• Do not invent precise metrics, stakeholder motives, dependencies, or process steps without labeling them as assumptions.
• Do not turn the exercise into a prioritization matrix, business plan, technical spec, legal review, medical analysis, financial advice, or final decision unless the user asks for a separate follow-up.
• If the idea touches legal, medical, financial, safety, engineering, employment, education, housing, or regulated domains, keep the diagram provisional and recommend verification with authoritative sources or qualified people before action.
• If important details are missing, show the missing pieces directly in the diagram instead of smoothing over them.

Acceptance Criteria

1. Produces a one-page node-and-flow diagram from messy idea material.
2. Groups nodes into clear themes or zones.
3. Labels directional links with relationship or flow verbs.
4. Includes a legend for node types, link meanings, confidence markers, and unknown markers.
5. Labels guesses, inferred links, missing information, and unknowns visibly.
6. Avoids false certainty and does not claim that the diagram proves the real system.
7. Identifies feedback loops, bottlenecks, fragile handoffs, or unclear ownership when present.
8. Ends with concrete verification questions or next information to gather.
9. Stays focused on visual understanding, not final strategy or professional advice.
10. Works as a prompt-only skill with no executable code or external services.

Example

User says: "I have an idea for a local tool library with volunteers, donations, repairs, memberships, and workshops, but I cannot see how it all fits."

Skill response: Create a provisional system diagram with zones for community demand, inventory, operations, repair loop, funding, education, and risks. Label membership fees as funding, donations as inventory input, repairs as a maintenance loop, volunteer scheduling as a bottleneck, and unknowns such as insurance, storage, tool tracking, and liability review.