thinking-systems

Plugin thinking-systems from marketplace cautious-computing-machine in iamladi/cautious-computing-machine. Commands read from the repo's manifest — 1 month ago.

Skills (29)

• abstraction-laddering

  Climbs a problem up (why?) and down (how?) the ladder — load-bearing is detecting solution-rung framings (artifact names like "dashboard" or "onboarding flow") and climbing before ideating, because running options from the solution rung just produces variants of the locked frame. Use when solutions

• balancing-feedback-loop

  Identifies a system's self-correcting mechanism (Goal → Gap → Corrective Action → Actual State) and names the delay between gap-detection and correction — delay magnitude, not goal or gap, predicts whether the loop stabilizes, oscillates, or overshoots. Use when a system keeps returning to a baselin

• concept-map

  Builds a hierarchical map of 15–25 entities connected by labeled linking phrases (each link reads as a sentence) — load-bearing is picking a sharp focus question before drawing nodes, or the map drifts to a taxonomy that encodes no testable claims. Surfaces knowledge gaps and aligns mental models. U

• concession-then-ask

  Pairs a concession (acknowledging a cost the counterpart paid) with the hard question it earned the right to ask. Load-bearing is the pre-emptive disclosure that makes the hard question askable, because asking cold reads as arrogant and triggers the counterattack the concession was meant to disarm.

• confidence-determines-speed-vs-quality

  Decides speed vs quality by splitting confidence into two independent axes (problem-confidence, solution-confidence) — load-bearing is the split; collapsing axes polishes solutions to unvalidated problems. Low problem → speed; high problem, low solution → balance; high on both → quality. Use when de

• conflict-resolution-diagram

  Resolves a conflict between two positions by surfacing needs, identifying the shared goal, and invalidating the hidden assumption that makes demands seem mutually exclusive — load-bearing is the assumption test with a concrete counter-example, not naming needs or appealing to shared values. Eli Gold

• connection-circles

  Maps a system's 5–10 elements around a circle with labeled causal arrows (+/–) — load-bearing is tracing closed loops back to their origin, because individual arrows only describe correlations and a diagram without a closed loop is a mislabeled org chart, not a systems map. Use when a problem keeps

• conversational-recovery

  Repairs a conversation after a framing move missed — load-bearing is class-shift after the miss, because repeating the same statement class harder ("pace harder") compounds the visible-effort tell that "trying is the opposite of having" and turns recovery into evidence of weakness. Use after a 1:1 /

• cynefin-framework

  Classifies a situation into Clear, Complicated, Complex, Chaotic, or Disorder and prescribes the matching response — load-bearing is probing cause-and-effect knowability (could an expert reliably predict the outcome of an action?), because misclassifying Complex as Complicated drives over-analysis i

• decision-matrix

  Builds a weighted-score matrix across multiple factors — factor discrimination is load-bearing: a factor scoring all options identically dilutes the matrix and must be dropped or reweighted. Use when the user has 2+ options and unequal evaluation criteria, when a decision is contested among stakehol

• eisenhower-matrix

  Sorts tasks across the Urgent × Important 2×2 matrix into Do / Schedule / Delegate / Eliminate — load-bearing is anchoring classification in a named long-term goal before sorting, because without that anchor importance collapses into urgency and every task drifts into Q1. Use when perpetually busy w

• first-principles

  Breaks a problem down to irreducible truths, then rebuilds from the ground up — load-bearing is the bedrock test: an assumption is irreducible only when restating it adds no new claim, so a half-stripped descent rebuilds on inherited framing. Uses Five Whys and Socratic questioning as descent tools.

• frame-control

  Plans the statement+question pair that installs a chosen frame — load-bearing is reading the frame already running in the room before speaking, because a pair deployed into an unread room is a naked move operating inside whichever frame was already there (usually the higher-status party's). Use befo

• hard-choice-model

  Classifies a decision by impact (low/high) and comparability (easy/hard) into No-Brainer / Apples-and-Oranges / Big Choice / Hard Choice, then matches deliberation strategy — load-bearing is the comparability pre-test; running hard-choice machinery on comparable options romanticizes analytical indec

• iceberg-model

  Investigates why a problem recurs by descending Events → Patterns → Structures → Mental Models — load-bearing is descent-discipline: each rung must cite evidence from the rung above, since a mental model that doesn't explain the pattern just relocates the symptom. Use when the user keeps fixing the

• impact-effort-matrix

  Sorts tasks across Impact × Effort into Quick Wins / Major Projects / Fill-ins / Thankless Tasks — load-bearing is anchoring both axes in comparable data (prior tasks, velocity, user research); unanchored estimates let feature-name heuristics place dark-mode-style fake Quick Wins that displace highe

• inversion

  Pressure-tests a plan by asking "how would I guarantee failure here?" — load-bearing is the mechanism question ("why would that actually kill the project?") that converts each vague fear into a named attack surface and a specific preventive action. Pre-mortem variant: imagine the project failed, nar

• ishikawa-diagram

  Builds a fishbone diagram mapping root causes across categories (6M default: People/Equipment/Methods/Measurement/Material/Environment, or custom) — load-bearing is picking categories that partition this domain's failure surface; 6M is a manufacturing legacy that misfits digital/service problems and

• issue-trees

  Decomposes a problem (or goal) into a MECE branching tree — problem-tree for causes, solution-tree for options — load-bearing is choosing the decomposition axis that cleanly partitions the space (funnel for retention, value-chain for margin, segment for market); the wrong axis makes branches overlap

• ladder-of-inference

  Walks a belief back down its reasoning chain (beliefs → conclusions → assumptions → interpretations → data → raw) — load-bearing is Data-rung reconstruction (what a camera would have recorded, distinct from conclusions), because stopping partway and rebuilding on accepted interpretations leaves the

• minto-pyramid

  Structures a communication top-down — conclusion first, then 3–5 supporting arguments, then detail. Load-bearing is the audience-fit check on the apex: the same apex is right for an exec and wrong for an engineer, so authoring the apex without naming the reader buries the lede. SCQA variant adds Sit

• ooda-loop

  Runs John Boyd's Observe–Orient–Decide–Act cycle for time-pressured decisions with incomplete information — Orient is load-bearing, since it's where mental models combine into the frame driving every Decide/Act, and teams that race from Observe to Act commit to whichever frame arrived first. Use whe

• presupposition-detector

  Scans an inbound message, agenda, or doc for presuppositions — assumptions embedded as fact in the grammar — and surfaces them as explicit claims. Load-bearing is surfacing the unstated assumption embedded as fact, because letting it pass uncontested ratifies the frame and makes future challenge str

• productive-thinking-model

  Tim Hurson's six-stage walk from problem to resourced plan (situation → DRIVE success → catalytic question → Generate → Forge → Align) — load-bearing is crafting the Step 3 catalytic question before brainstorming, since downstream steps inherit that framing and Step-1-to-4 jumps produce generic solu

• reinforcing-feedback-loop

  Maps a self-amplifying loop where two+ variables cause each other to grow or decline, then names the ceiling that will constrain it — every real reinforcing loop breaks against a balancing constraint, and picking the wrong ceiling lets teams plan against the comfortable one while the hard one hits f

• second-order-thinking

  Maps downstream consequences across three horizons (10 min / 10 months / 10 years) and weights cross-domain ripples higher than same-domain ones — same-domain effects are already priced into intuition, so the leverage is surfacing ripples that bleed sideways (work decision → relationships, health mo

• situation-behavior-impact

  Delivers feedback using SBI — Situation + Behavior + Impact, then optionally asks Intent — load-bearing is the video-frame test: Behavior must be what a camera would capture (words, gestures, timestamp) with zero trait or motive language, or Impact lands as attack. Use when giving critical or positi

• six-thinking-hats

  Walks a decision through six perspectives (White/facts, Yellow/benefits, Black/risks, Red/gut, Green/creative, Blue/process) starting with a Blue-hat scope-lock — a vague focus question collapses every later hat into generic talking points, while a tight scope produces hat-specific signal. Use when

• zwicky-box

  Generates novel solution combinations from a morphological matrix of attributes × values — load-bearing is verifying each axis varies independently before sweeping; coupled axes collapse the grid into the handful of defaults the team already considered. Fritz Zwicky's analysis. Use when brainstormin

Slash commands (29)

• /thinking-systems:abstraction-laddering

  Reframe a problem up (why) and down (how) the abstraction ladder

• /thinking-systems:balancing-feedback-loop

  Identify the goal-seeking mechanism that keeps a system at equilibrium; surface delays

• /thinking-systems:concept-map

  Build a hierarchical map of 15-25 entities with labeled links to align mental models

• /thinking-systems:concession-then-ask

  Pair a real concession (acknowledging a specific cost the counterpart paid, or an Ackerman 65/85/95/100 numerical anchor sequence) with the hard question the concession earns the right to ask

• /thinking-systems:confidence-determines-speed-vs-quality

  Decide speed-vs-quality strategy based on confidence in problem and solution

• /thinking-systems:conflict-resolution-diagram

  Surface needs behind opposing demands; find the assumption that makes them seem mutually exclusive

• /thinking-systems:connection-circles

  Map a system's 5-10 elements with labeled causal arrows to surface feedback loops

• /thinking-systems:conversational-recovery

  Repair a conversation after a framing move missed by diagnosing the miss type, releasing the dead move, and class-shifting (do not pace-harder)

• /thinking-systems:cynefin-framework

  Classify a situation into Clear / Complicated / Complex / Chaotic / Disorder and prescribe response

• /thinking-systems:decision-matrix

  Build a weighted-score matrix to choose between options across multiple factors

• /thinking-systems:eisenhower-matrix

  Sort tasks into the Urgent × Important matrix (Do / Schedule / Delegate / Eliminate)

• /thinking-systems:first-principles

  Strip assumptions, reach irreducible truths, rebuild a solution from the ground up

• /thinking-systems:frame-control

  Plan the statement+question pair that installs your frame in an upcoming conversation, after first reading the frame already running and checking for pre-suasion leverage

• /thinking-systems:hard-choice-model

  Classify a decision into No-Brainer / Apples-and-Oranges / Big Choice / Hard Choice

• /thinking-systems:iceberg-model

  Descend Events → Patterns → Structures → Mental Models to find systemic causes

• /thinking-systems:impact-effort-matrix

  Sort backlog tasks into Quick Wins / Major Projects / Fill-ins / Thankless Tasks

• /thinking-systems:inversion

  Pre-mortem — ask how this would fail, then derive preventive actions

• /thinking-systems:ishikawa-diagram

  Build a fishbone diagram mapping candidate root causes across categories

• /thinking-systems:issue-trees

  MECE-decompose a problem or goal into a branching tree; prioritize with 80/20

• /thinking-systems:ladder-of-inference

  Trace a belief back down the reasoning chain to raw observable data

• /thinking-systems:minto-pyramid

  Structure communication top-down — conclusion first, then arguments, then detail (SCQA optional)

• /thinking-systems:ooda-loop

  Run Observe-Orient-Decide-Act cycle for time-pressured decisions with incomplete info

• /thinking-systems:presupposition-detector

  Scan an inbound message, agenda, or doc for assumptions embedded as already-established fact (and Heritage-style optimised questions that grammatically prefer one answer), then plan whether to accept, contest, or reframe each

• /thinking-systems:productive-thinking-model

  Walk from defined problem to resourced plan through six stages (DRIVE framework)

• /thinking-systems:reinforcing-feedback-loop

  Map a self-amplifying loop producing exponential growth or decline; find its ceiling

• /thinking-systems:second-order-thinking

  Map downstream consequences of a decision across 10-min / 10-month / 10-year horizons

• /thinking-systems:situation-behavior-impact

  Deliver feedback using SBI — Situation + observable Behavior + Impact (+ optional Intent)

• /thinking-systems:six-thinking-hats

  Walk a decision through all six thinking hats (White/Yellow/Black/Red/Green/Blue) as a guided dialogue

• /thinking-systems:zwicky-box

  Generate novel solution combinations via a morphological attribute × value matrix

Similar plugins