action-calibration

Files (4)

• SKILL.md
• cases.json · examples/
• savings-skill-audit.md · references/
• thread-derived-criteria.md · references/

SKILL.md (first lines)

# action-calibration — spend only enough to change the decision

The governing distinctions are:

```text
minimal decisive action != smallest visible deliverable
maximal coherent action  != everything that could possibly be done
```

A **minimal decisive action** is the least burdensome action whose possible outcomes
can materially change the next decision, theory, architecture, or allocation.

A **maximal coherent action** is the broadest bounded program whose parts share one
decision layer, common prerequisites, and reusable outputs, and which closes that
layer without importing unrelated ambitions.

## Load this when

- The user asks for the highest-leverage, minimal, maximal, next, or most efficient
  action.
- A research program can begin with a falsifier, exact control, obstruction, or
  sensitivity test before a complete proof program.
- A build can be staged as a bounded experiment before production hardening.
- Formal proof, independent replay, deployment, or publication may be premature.
- Several candidate tasks compete for limited human attention, money, compute,
  context, or coordination.
- A long task risks becoming impressive but non-discriminating work.
- The result of one small experiment could decide which large program is worth doing.

## Do not load this when

- The task is fixed, trivial, and has no meaningful scope choice.
- Immediate safety or security containment must happen before analysis. Contain first;
  calibrate follow-up work afterward.
- A user has explicitly required a complete regulated, contractual, or production
  deliverable whose scope cannot be reduced.
- The question is only ordinary ordering of a to-do list and no evidence, uncertainty,
  or escalation rule is involved.
- Another skill owns the real issue: use `interdependent-work-graph` for cross-repo
  authority, `risk-boundary-build` for runtime permissions, or `domain-claims` for
  semantic collisions.

## Core contract

1. **Name the decision, not merely the task.** Ask what choice the work must inform.
2. **Sketch the maximal coherent closure before selecting the minimum.** The minimum
   is defined relative to the whole decision layer, not in isolation.
3. **Find the earliest load-bearing unknown.** Prefer the first uncertainty whose
   resolution changes the downstream branch.
4. **Require outcome branching.** A minimal action is decisive only when its positive,
   negative, and unresolved outcomes have different declared consequences.
5. **Close prerequisites first.** A cheap result is not economical if an unresolved
   prerequisite makes it uninterpretable.
6. **Reuse the work.** Prefer actions whose fixtures, certificates, schemas, datasets,
   or code become inputs to the maximal program.
7. **Preserve optionality.** Avoid irreversible commitments before evidence requires
   them.
8. **Freeze criteria before evaluation.** Do not select targets, metrics, controls, or
   scientifically meaningful stopping rules after seeing the result.
9. **Preflight scarce resources before execution.** Resource scarcity requires
   contemplation before a compute run begins. Decide whether the available compute,
   memory, disk, power, network, quotas, usage limits, and durable execution time are
   sufficient for the selected action to reach its natural terminal condition. If
   there is material doubt, do not start the run; resize, stage/checkpoint, relocate,
   acquire resources, or leave it `hmmm`. Once a healthy run begins, let it finish.
   Do not invent a wall-clock ceiling merely because the action is described as
   bounded or falsifiable. Runtime/resource ceilings are stopping criteria only when
   they are load-bearing to the claim or acceptance criterion, an authorized safety
   boundary, or a real externally imposed hard limit fixed before launch.
10. **Escalate by rule, not momentum.** The result determines whether the next action is
   stop, redirect, repair a prerequisite, or enter the maximal program.
11. **Carry `hmmm`.** Unknown cost, coupling, interpretation, authority, and completion
    feasibility boundaries remain visible.

## The action record

Before execution, write:

```yaml
decision: <the choice this work must inform>
decision_layer: <geometry | topology | implementation | production | publication | other>
load_bearing_unknown: <earliest uncertainty that changes the branch>
invariants_to_preserve:
  - <facts, contracts, or user requirements that may not be traded away>

minimal_decisive_action:
  action: <bounded experiment or implementation>
  positive_outcome: <result and next action>
  negative_outcome: <result and next action>
  unresolved_outcome: <failed prerequisite or ambiguity and next action>
  prerequisites:
    - <must already be true>
  stop_condition: <semantic/computational completion condition; not an arbitrary timeout>
  reusable_outputs:
    - <artifact reused by later work>

maximal_coherent_action:
  closure_target: <entire decision layer to close>
  included_work:
    - <work sharing the same closure target>
  excluded_work:
    - <adjacent ambition intentionally outside>
  completion_condition: <what closes the layer>

cost_vector:
  time: low | medium | high | hmmm
  human_attention: low | medium | high | hmmm
  money: low | medium | high | hmmm
  compute: low | medium | high | hmmm
  coordination: low | medium | high | hmmm
  operational_risk: low | medium | high | hmmm

resource_preflight:
  completion_feasible: yes | no | hmmm
  externally_imposed_hard_limits:
    - <actual limit or none>
  scientific_resource_stop_rule: <justified load-bearing criterion or none>
  execution_durability: <why the run can reach its natural terminal condition>

From The-Interdependency/skill-lib, MPL-2.0.

More from The-Interdependency/skill-lib