Describe a diagram that answers a business question
Use only information supplied in the conversation and this skill text. Do not browse, call tools, inspect files, execute code, create artifacts, or take external actions. Return the work directly in chat. Attribute material claims to supplied source labels or quotations; a pasted URL is a source label, not evidence that its contents were checked. Distinguish supplied facts, reasonable interpretations, proposals, and unknowns.
Inputs and scope: Establish the audience, question to explain, entities or events, relationships, sequence, dates when relevant, and the requested level of detail. Use only supplied facts for labels and connections. If a decision-changing input is absent, ask the smallest useful question and complete the portions supported by available material. State assumptions explicitly; do not manufacture facts, approvals, dates, or completion evidence.
Method 1. Identify the diagram's explanatory job: show sequence, responsibility, dependencies, relationships, hierarchy, or change over time. Do not select a fashionable format before clarifying what the reader should understand. 2. Choose a suitable structure and explain the choice briefly. Use a flow for decisions and handoffs, timeline for dated events, hierarchy for containment, or relationship map for nonsequential connections; a small table may be clearer. 3. List the essential nodes with short, meaningful labels and supporting source locations. Separate people, actions, outputs, and states so a reader can tell what each item represents. 4. Specify connections and their meaning: precedes, approves, supplies, depends on, contains, or influences. Label uncertain relationships explicitly and avoid implying causation or chronology when only association is supplied. 5. Define grouping, reading order, branch conditions, start and end points, and an explanation of any visual conventions. Keep color optional and ensure the structure can be understood through text alone. 6. Walk through a representative reader question or operational scenario. Check for missing destinations, disconnected elements, contradictory branches, and excessive detail; return a textual specification or plain-text alternative without rendering claims.
Output: Provide the diagram purpose, chosen form, node and relationship lists, layout guidance in prose, legend, and a brief walkthrough. No renderer or diagram code is required.
Quality checks: Confirm every edge has a supported meaning, hierarchy is not mistaken for authority, and uncertainty remains visible. Do not claim layout execution, visual verification, or universal renderer compatibility.
Worked example: Supplied process: agent receives request, checks completeness, sends incomplete requests back, and routes complete requests to an approver. Specify a left-to-right flow with a completeness decision and a return loop labeled missing information. Include approved and rejected outcomes only if supplied; otherwise mark the approver's possible outcomes as an open detail.