systems-thinking

name	systems-thinking
description	Analyze a software system, AI pipeline, or research direction by surfacing its underlying structure — invariants, hidden abstractions, weak assumptions, and the single highest-leverage direction — rather than optimizing local implementations. Use when asked to step back and think about a system's design at a conceptual level, find leverage points, evaluate a research direction for compounding impact, or decide where to invest for the long term. NOT for reviewing a specific repo's architecture (use repo-architecture-review) or local code cleanup.
scope	universal
ported-from	global skill

Systems Thinking & Research Architecture

Approach systems by finding the underlying structure, not by optimizing the implementation in front of you. The output is a conceptual model and one high-leverage direction — not a task list.

Stance

Search every system for its invariants, hidden abstractions, conceptual models, leverage points, and reusable foundations. Treat each project as part of a larger ecosystem: the highest-value change is often the one that makes several future projects simpler, not the one that improves this one.

A leverage point is where a small change to one abstraction collapses complexity everywhere downstream. Find that before proposing anything.

Interrogate the design

Work through these deliberately — the answers, not the questions, are the value:

• Why does it exist? What force created it; is that force still present?
• What does it assume? List the assumptions explicitly.
• Which assumptions are essential vs accidental? Essential ones define the problem; accidental ones are frozen history you can often remove.
• What concept appears multiple times under different names? Repeated concepts are a missing abstraction announcing itself.
• What information flows through the system, and where does it choke?
• What becomes simpler if one abstraction changes? That answer is your leverage point.

Prefer / Avoid

Prefer: durable infrastructure, reusable concepts, composable systems, explicit semantics, measurable outcomes, research that compounds (each result makes the next cheaper).

Avoid: feature accumulation, premature optimization, unnecessary generalization (abstraction with one caller is speculation), and local cleanup with no architectural payoff.

Research lens

When the subject is a research direction, evaluate it on: novelty, long-term impact, scientific contribution, engineering leverage, ecosystem effects, and product potential. Weight toward work that could become more than one thing at once — a paper and a platform and a reusable framework and a product capability. Single- purpose work that can't compound is lower leverage even when it's correct.

Cadence & durable output

Role: read-only analysis/planning — route execution to a separate implementation pass. This is a low-frequency lens (quarterly, not weekly). Read the prior run's chosen direction first and confirm / drop / supersede it rather than re-deriving from scratch. Land the chosen direction as an ADR or north-star note so the next run can mark it pursued.

Output

1. Implicit conceptual model — the system as its structure actually is, named plainly (often clearer than how its authors describe it).
2. Weak assumptions — the accidental ones worth challenging, and what each costs.
3. Missing abstractions — the concepts that recur under different names.
4. Long-term architectural opportunities — what compounds across projects.
5. The single highest-leverage direction — one, chosen and defended, not a menu.