Decision Frameworks (Meta-Skill)

Structured approaches for making engineering decisions with confidence and traceability.

Installation

OpenClaw / Moltbot / Clawbot

npx clawhub@latest install decision-frameworks

When to Use

• Choosing between libraries, frameworks, or tools
• Facing a build-vs-buy decision
• Selecting an architecture pattern (monolith vs microservices, SQL vs NoSQL, etc.)
• Multiple valid options exist and the team needs alignment
• Prioritizing a backlog or technical roadmap
• Documenting a significant technical decision for future reference

Decision Matrix Template

Use a weighted scoring matrix when comparing 3+ options across measurable criteria.

How to use:

1. List criteria relevant to the decision
2. Assign weights (1-5) based on project priorities
3. Score each option per criterion (1-5)
4. Multiply score x weight, sum per option
5. Highest total wins — but sanity-check the result against gut feel

Build vs Buy Framework

Follow this decision tree:

Is it a core differentiator for your product?
├── YES → Build it (own the competitive advantage)
└── NO
    ├── Does a mature, well-maintained solution exist?
    │   ├── YES → Buy / adopt it
    │   └── NO → Build, but keep it minimal
    └── Is the integration cost higher than building?
        ├── YES → Build
        └── NO → Buy / adopt

Factor comparison:

Library / Framework Selection

Evaluate candidate libraries against these criteria before adopting:

Quick heuristic: If you cannot replace the library within one sprint, treat the decision as a one-way door (see Reversibility Check below).

Architecture Decision Framework

Use these tradeoff tables when choosing between architectural approaches.

Monolith vs Microservices

SQL vs NoSQL

REST vs GraphQL

SSR vs CSR vs SSG

Monorepo vs Polyrepo

Priority Matrices — RICE Scoring

Score and rank features/tasks:

RICE Score = (Reach x Impact x Confidence) / Effort

MoSCoW Method

Reversibility Check

Classify every significant decision as a one-way or two-way door.

Rule of thumb: Wrap risky choices behind interfaces/abstractions. This converts many one-way doors into two-way doors by isolating the implementation from consumers.

ADR Template

Document significant decisions using a lightweight Architecture Decision Record.

# ADR-NNNN: [Short Title]

## Status
[Proposed | Accepted | Deprecated | Superseded by ADR-XXXX]

## Context
What is the problem or situation that motivates this decision?
Include constraints, requirements, and forces at play.

## Decision
What is the change being proposed or adopted?
State the decision clearly and concisely.

## Consequences

### Positive
- [Benefit 1]
- [Benefit 2]

### Negative
- [Tradeoff 1]
- [Tradeoff 2]

### Risks
- [Risk and mitigation]

Store in docs/adr/ or decisions/. Number sequentially. Never delete — mark superseded. Review during onboarding and quarterly audits.

Anti-Patterns

NEVER Do

1. NEVER skip writing down the decision — undocumented decisions get relitigated endlessly
2. NEVER decide by committee without a single owner — assign a DRI (Directly Responsible Individual)
3. NEVER treat all decisions as equal weight — classify by reversibility and impact first
4. NEVER ignore second-order effects — ask "and then what?" at least twice
5. NEVER lock in without an exit plan — define how you would migrate away before committing
6. NEVER conflate familiarity with superiority — evaluate on criteria, not comfort
7. NEVER defer a one-way door decision indefinitely — the cost of delay often exceeds the cost of a wrong choice