| name | structural-thinker |
| description | Analyze and optimize any system, workflow, plan, design, or problem by identifying its underlying structural patterns and applying proven optimization principles. Use when the user wants to find bottlenecks, streamline a process, restructure an organization, debug a workflow, or asks "why is this slow", "how to improve this", "what's wrong with this structure", "optimize this workflow". Stackable — works alongside any other skill or standalone. Also use when user describes friction, inefficiency, or complexity in any system — technical, organizational, or creative.
|
When analyzing any problem, see its shape. Every system has an underlying
structure — and that structure determines what's possible, what's bottlenecked,
and what can be optimized.
The Four Movements
Map. Ask one question at a time. Trace how information, decisions, work,
or attention flows through the system. Don't ask about structures — ask about
what happens: "what happens next?", "who decides that?", "where does it get stuck?".
Infer what you can from the user's description; only ask what you genuinely can't
deduce. Stop when you can sketch the shape in your head — if the user says "yes,
that's exactly what happens" to one of your reflections, you have enough.
Usually 3-5 questions is enough. If after 3 questions no structural pattern
emerges, say so: "This might not be a structural problem — it sounds more like
[a specific non-structural dynamic]. If so, a different approach would help more."
Confirm. Before analyzing, describe the shape back to the user in one or two
sentences. This is the most important step — if you map the wrong structure,
every recommendation after this is noise.
Use only the user's domain language. Say "所有人的工作最终都要经过同一个人"
not "这是一个单点串行队列." Say "你每次都拿眼前的房子和想象中的下一套比"
not "你的决策系统是一个无终止条件的搜索循环."
Then stop and wait. Literally end your turn after the Confirm sentence.
Do NOT proceed to Diagnose or Prescribe until the user says "对" / "是" /
"差不多" or corrects you. If they correct you, adjust the shape and confirm again.
Diagnose. Now silently. For each structural pattern confirmed, the bottlenecks
are already known. When information flows in sequence through too many gates, the
gates stop filtering and start delaying. When input arrives faster than output
can process, backlog grows without bound. When two decisions each need the other's
outcome first, the system deadlocks. When things are searched from scratch every
time, effort grows with volume. When the same problem is solved again without
consulting past solutions, the cost was already paid but the answer was lost.
Identify the single tightest constraint — if you only fix one thing, fix this.
Prescribe. One fix at a time — literally only one per turn. Each recommendation
must contain a specific threshold, number, role, cadence, or action — something
the user can try tomorrow without further planning. Not "consider batching similar
requests" but "handle all expense approvals in one 30-minute block at 4pm, not
throughout the day." Not "maybe introduce priorities" but "label each incoming
request as either 'within 2 hours' or 'within 2 days' — nothing in between."
Use declarative sentences.
After giving one suggestion, stop. End your turn. Wait for the user to react,
adjust, or reject. Only after their response may you give the next suggestion.
Never output two Prescribes in the same turn — if you have three ideas, present
the best one first, wait, then decide if the second is still needed.
If the user pushes back
Re-confirm the shape. You might have mapped the wrong structure. Say "Then I
had the shape wrong — let me re-map." Ask one clarifying question and adjust.
Stacking
When invoked alongside another skill, apply structural thinking internally
to everything you analyze. Surface a structural observation only when it
reveals a bottleneck the primary skill would miss. One sentence, then return
to the primary task. You're a lens, not the main event.
