higher-order-decision-architect
Skill2 starsChanged 40 days agoMITView on GitHub
Applies first-principles, multi-order consequence analysis, inversion, systems thinking, probability, antifragility, and high-energy thrive ascent (2036 lens) before material coding decisions (architecture, dependencies, public API, security, data contracts, hard-to-revert refactors). Use when choosing between approaches, planning cross-cutting changes, or when the user asks for decision analysis, tradeoffs, pre-mortem, second-order effects, or thrive vision.
In this repository49 other files it gives its agents.
- AGENTS.mdAGENTS.md
- adversarial-auditSkill
- agentic-reactorSkill
- agent-orchestratorSkill
- ai-optimizationSkill
- architecture-synthesisSkill
- audit-allow-buildsSkill
- audit-ide-dependenciesSkill
- author-workflow-skillSkill
- bdd-strategizerSkill
- chrome-extension-mv3Skill
- concurrent-cli-agentsSkill
- control-feederSkill
- control-graphSkill
- cursor-transcript-harvestSkill
- cv-promote-guardSkill
- devcontainer-hardenedSkill
- dual-copy-skill-publishSkill
- explore-repo-readonlySkill
- finder-reactorSkill
- fix-dependency-securitySkill
- fusion-sageSkill
- git-worktreesSkill
- grok-host-prepSkill
- gt-flowSkill
- looperSkill
- master-plannerSkill
- mvu-refactor-planSkill
- odysseus-navigatorSkill
- project-editor-profileSkill
- react-client-expertSkill
- semantic-markup-cssSkill
- semantic-nameSkill
- session-unit-orderSkill
- shell-kernel-ontologySkill
- skill-rename-propagationSkill
- split-to-prsSkill
- src-tree-reorganizeSkill
- stellar-roadmapSkill
- stellar-spacemapSkill
- subagent-delegationSkill
- subagent-explore-reportSkill
- supply-chain-hardenSkill
- tauri-agenticSkill
- tauri-ipc-debugSkill
- tidy-commit-pushSkill
- upgrade-packagesSkill
- verification-cockpitSkill
- x-agent-resourcesSkill
The file
We split this skill into the rules it gives an agent
4 rules. About 0 are common, 4 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 38
Run this after steps 3–7 so pessimism does not get the last word.
- Distinctive: line 107
No corporate hedge-speak; prefer precise language.
- Distinctive: line 108
Prefer long-term (3rd-order+) value over short-term optics when they conflict.
- Distinctive: line 112
When closing a decision advisory turn, you may ask: “Stress-test further or apply to another project area?”
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Higher-Order Decision Architect
Load rule: Formal sequence is SoT. Thrive depth + provenance stay below; expand only if a step is unclear. Surface Executive Verdict, risks, confidence, next actions on non-trivial decisions (not every reply).
CLT: ../rules/clt-dual-load.mdc — keep human-facing verdicts short (extraneous ↓) while preserving judgment work (germane); do not skip the sequence to “save tokens.”
// Material decision ≔ architecture | deps | public API | security | data contracts | multi-module | hard-to-revert
// Sequence (exact order)
1 FirstPrinciples → 2 HigherOrder("and then?") → 3 Invert+PreMortem
→ 4 Systems → 5 Probabilistic → 6 Competence+Regret → 7 Antifragile
→ 8 ThriveAscent(2036) // after honest pre-mortem — never skip; never end on funeral only
// Axioms
A1 Pre-mortem mandatory and honest — but not the final beat
A2 Close with refuse vs build + ≥1 acceleration alternative when pillar kept
A3 Prefer 3rd-order+ value over short-term optics when they conflict
A4 Weak evidence → probability ranges; say "unknown" when trueOverlays: shellyxz shell arch-design/overlays/shell-kernel-decision-hooks.md · thepulimaangani-decision-hooks.
Step 8 — Thrive ascent (2036 lens)
Run this after steps 3–7 so pessimism does not get the last word. Ground optimism in evidence; high energy ≠ denial.
Thrive, not survive
| Funeral drift (avoid) | Thrive reframe |
| “This feature will die” without alternative | Name what builds toward the horizon year (default 2036) |
| “Pivot to minimal only” | Minimal plus acceleration alternative — what to invest in when the force hits |
| “Abandon the project” as closing line | Freeze vs split vs shrink — with iron-peak foundation named |
| Binary will/won’t | Probability ranges + Response column |
| Pre-mortem as autopsy | Pre-mortem → guardrails + leading indicators |
Mandatory thrive outputs (internal or surfaced)
- Ten-year thrive picture — One sentence north star: kernel (durable) + bridge/product (evolving) + boundary. Mermaid or table when in roadmap docs (stellar-spacemap §0b).
- Trajectory forces — Table: Force | P(horizon) | Effect | Response | Confidence. Include at least one tailwind (e.g. POSIX shell, manifest-first agents, contract verification).
- Refuse vs build — Two columns: what we refuse (drag) vs what we build toward
{YEAR}(ascent). No “optional workflow that may die” framing for pillars the operator cares about. - Iron-peak callout — Which abstraction compounds for a decade? (e.g.
path.contract, PLUGIN boundary, evidence schema.) Mark positive 3rd-order outcomes explicitly. - Acceleration trigger — When would pessimism say shrink? State when to invest more instead (evidence-weighted).
- Thrive bet confidence — Confidence % on the long-horizon bet; separate from near-term implementation confidence.
Provenance (shellyxz shell pattern)
Applied in ~/.config/shell:
arch-design/coming-next.md— § Trajectory forces (2036-oriented) with Response + Confidencearch-design/test-of-travelled-time-from-future.md— honest pre-mortem then split/kernel-vs-cockpit thrive framingplanned-features/done/sprint-jun-2026-pr8.md— Ten-year thrive picture mermaid (kernel2036 → bridge2036 → launch)- stellar-spacemap — §0b thrive picture, §5 trajectory forces, §6 guardrails
Mandatory process
- Diagnose the critical zone — Single highest-leverage / highest-uncertainty bottleneck. If unclear, ask 1–2 sharp questions.
- Deconstruct with first principles
- Map consequence chain (1st → 2nd → 3rd+) with rough probabilities
- Inversion & pre-mortem on top 2–3 options (honest failure modes + mitigations)
- Systems + antifragility
- Thrive ascent (step 8) — 2036 lens: forces + responses, refuse vs build, iron-peak, acceleration trigger
- Synthesize — One recommendation + explicit confidence + assumptions + leading indicators to watch
Output format (non-trivial decisions)
Executive Verdict (1–2 sentences)
Critical Area Identified — One sentence
First Principles Breakdown — Bullets
Consequence Chain — Table: Order | Effect | Probability | Impact (H/M/L) | Notes
Inversion & pre-mortem risks — Top failure modes at order 2+ and mitigations
Thrive ascent (2036) — North star one-liner; trajectory forces table (with Response); refuse vs build; iron-peak abstraction; thrive bet confidence %
Recommended Decision — Clear action + 2–3 sentence rationale (must not read as defeat if a pillar is worth keeping)
Confidence & uncertainties — Near-term confidence %; thrive bet confidence %; key assumptions; monitoring signals
Immediate next actions — Max 3 concrete steps
Non-negotiable rules
- Be direct; say “unknown” or “outside reliable competence” when true.
- No corporate hedge-speak; prefer precise language.
- Prefer long-term (3rd-order+) value over short-term optics when they conflict.
- Weak evidence → state probability ranges.
- Pre-mortem is mandatory and honest — but never the final beat. Always follow with thrive ascent (step 8).
- Do not close a material decision advisory on shrink/abandon without naming refuse vs build and at least one acceleration alternative.
- When closing a decision advisory turn, you may ask: “Stress-test further or apply to another project area?”
Activation
- User asks for tradeoffs, architecture choice, “what could go wrong”, pre-mortem, second-order effects, or thrive/2036 vision.
- Agent is about to pick dependencies, public API shape, security model, or a cross-module refactor.
- Pair with domain skills (bdd-strategizer for test-first decomposition; architecture-synthesis for long-term surplus; stellar-spacemap for §0b/§5/§6 in backlog docs; ai-optimization for evidence-first scouting; odysseus-navigator for hubris labels — HODA still owns this sequence).
- Shellyxz shell: load
arch-design/overlays/shell-kernel-decision-hooks.mdbefore kernel/plugin/PATH/ontology splits; pair with.agents/ontology/GRAPH.mdfor boundary context.
Cursor rule (optional)
Symlink rules/higher-order-decision-architect.mdc into .cursor/rules/ with alwaysApply: true to route material decisions to this skill without pasting the full framework every turn.
Example provenance: Thepulimaangani (Tamil prosody / WASM parser decisions); shellyxz shell (2036 thrive ascent + trajectory forces).
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

