A Systems Theory for Today

A living, forkable attempt to build a systems theory adequate to the present — by designed disagreement.

SKILLS

Version: 0.1 · Status: Draft (author to ratify) · Last updated: Session 1

What skill this project develops, what secondary skills it spins off, and which existing skills (in Chat and Code) it is encouraged to tap.

1. The primary skill: systems-theory-panel

The project’s core deliverable-as-skill is a reusable capability for running a standing panel of real thinkers as designed disagreement, on a question of total scope, toward a living theory. The skill file itself is at the repository root: SKILL.md.

What the skill encodes:

  • The two-body pattern (deliberating panel + non-voting synthesizing chair + ratifying author).
  • The roster construction principle: compose members so their fault lines are productive; keep a summonable advisory bench and an extensible extended bench.
  • The round structure (positions → clash → rating/vote → dissent → catches).
  • The subtractive, opinionated, steelman-first discipline.
  • The learning loop (catches → learnings → rule amendments).
  • The proto-synthesis stance: every output provisional, never final.

Triggers (proposed): “the systems panel,” “run the systems theory panel,” “convene the systems panel,” or naming the project.

2. Secondary skills likely to spin off

As the project matures, several narrower skills are likely to crystallize out of it. We name them now so we recognize them when they appear (per the author’s project-self-audit practice — “watch for new skills emerging”):

  • total-system-history — the method used in HISTORY_OF_SYSTEMS_THEORIES.md: mapping a domain’s history of total explanatory frameworks, their proponents, timing, and fate. Reusable for any “who tried to explain all of X, and what happened” question.
  • polycrisis-mechanism-mapping — turning a vague “everything is connected” intuition into an explicit map of stocks, flows, feedback loops, and couplings between named subsystems. The bridge from prose to model (Phase 1).
  • theory-to-model — the discipline of rewriting a prose theory as a machine-readable model (variables, couplings, feedback signs) and then as a runnable simulation (Phase 3).
  • living-commons-governance — how a public, forkable knowledge project governs contributions, rival theories, and versioning without a central gatekeeper (Ostrom-informed; Phase 2/4).
  • red-team-a-theory — a focused adversarial protocol for trying to break a candidate theory (distinct from the generative panel): find the counterexample, the unfalsifiable move, the smuggled value judgment.

Each, if it stabilizes, gets its own SKILL file and a note here.

3. Existing skills this project is encouraged to tap

The founding brief explicitly invites the project to benefit from other skills and experts already available in Chat and Code. The relevant ones:

Deliberation / expert-panel skills (the closest cousins). The author’s existing designed-disagreement panels are direct methodological kin, and their patterns are borrowed wholesale into the method here. Where a systems question turns out to be really a question in one of their domains, defer to them:

  • A general historical-roundtable / deep-analysis panel for broad pressure-testing, root-cause work, and turning a messy brief into a clear next move — useful for the meta-question (pressure-test 4) and for stress-testing candidate theories.
  • Game- / product-design panels — relevant when we model incentive structures and feedback loops as designed systems (the dopamine economy is, precisely, a designed engagement system); their core-loop and player-fantasy lenses transfer directly to “why is the attention economy shaped this way.”
  • The literary master panels — not for theory-building, but the project produces a great deal of writing, and the author’s writing-craft skills (voice, editorial passes, subtractive style) govern the prose quality of every document here.

Craft / production skills.

  • Writing-style and editorial-pass skills — applied to every document for clarity, voice, and the subtractive discipline.
  • Frontend/design skills — for the viz/ artifacts and, in Phase 2, the public website.
  • Document-format skills (docx / pptx / pdf / xlsx) — for producing shareable deliverables (e.g. an executive brief, a slide deck of the candidate theories, a data table of the pressure-test tracker) when the audience needs them. The repository’s native form is Markdown; format-specific outputs are generated on demand.
  • Project-continuity, project-self-audit, and bundle-consistency practices — the operational spine: architectural anchors, the four-document loop (catches/learnings/metrics/handoff), periodic audits that check whether learnings are reflected in the skills, and structural sweeps for drift across the document set.

Research / retrieval tools.

  • Web search and fetch — for grounding every empirical claim and, especially, for the contemporary landscape (who is trying what now), which goes stale fast and must be re-checked each session.
  • Where the project later needs live data (fertility series, inequality series, emissions, political-violence indices), the appropriate data tools are enlisted at that point.

4. How the skills fit together (the stack)

                     ┌─────────────────────────────┐
   THIS PROJECT ───► │   systems-theory-panel      │  (primary skill; SKILL.md)
                     └───────────────┬─────────────┘
                                     │ composes / borrows from
        ┌────────────────────────────┼────────────────────────────┐
        ▼                            ▼                             ▼
  designed-disagreement        writing / editorial            project operations
  panels (method DNA)          (prose quality)                (continuity, self-audit,
                                                               metrics, handoffs)
        │                            │                             │
        └──────────── all draw on ───┴──── research + design tools ┘
                        (web search/fetch; frontend/viz; doc formats; data)

5. Skill-hygiene commitment

Per the author’s standing practice, at each session end the project asks the self-audit questions: Has anything the project learned failed to make it into a skill? Has a new skill emerged that should be named? Has the panel accumulated a pattern worth encoding? When the answer is yes, SKILL.md and this document are updated, and the change is noted in METRICS.md. The skill, like everything else here, is a living document.