meaningful-fork-triage

What this skill does

# Meaningful-Fork Triage

A working mode for any task that contains many decisions. Treat the user's attention as the scarcest resource on the project. Make the decisions that are straightforward-with-high-confidence without interrupting, and spend the user's attention only on the **meaningful forks** — the points where the choice is consequential *and* the right answer is genuinely uncertain.

Apply this whenever the user has signalled "don't hold my hand" or simply delegated a multi-step task. It is a stance that governs the whole task, not a one-time action.

## The two axes

Score every decision point on two axes, fast and informally:

- **Confidence** — How sure am I which option is correct? (Would a competent peer agree there's an obvious right answer?)
- **Stakes** — How consequential is it, and how hard to reverse if wrong? (Contract changes, data loss, architectural commitments, anything a downstream step builds on = high. Wording, formatting, a default that's trivially flipped later = low.)

Confidence comes from the agent; stakes come from the blast radius. A decision is a *meaningful fork* only when it is **both** uncertain **and** high-stakes.

## The routing rule

| Confidence | Stakes | Action |
|---|---|---|
| High / obvious | any | **Act silently.** Do it; record it in the audit log so it's reviewable, not lost. |
| Low | High | **Surface it.** A genuine fork — present a crisp, batched choice before acting. |
| Low | Low | **Default and note.** Apply a sensible default, flag it for easy override, don't block. |
| any | Cosmetic / mechanical | **Defer.** Roll into a cleanup pass; never surface mid-task. |

The discipline cuts both ways. Surfacing *every* decision is the friction the user is trying to escape. Surfacing *none* risks a silent wrong turn on something that mattered. Route by confidence × stakes so attention lands only where it changes the outcome.

## Calibrating confidence (optional banded scheme)

When a task benefits from explicit gradations — long document authoring, spec work, anything chain-top — offer a banded confidence scheme and let the user tune it. A scheme proven on PRD-authoring:

- **>90%** → not in the deliverable body; logged in the audit log (e.g. an appendix).
- **75–90%** → a brief inline note tagged with the confidence; the user may pull any one for a fuller breakdown.
- **50–75%** → a full section the user reviews and pushes back on at review time (no live back-and-forth).
- **≤50%** → a live, one-item-at-a-time discussion *before* drafting that part.

The bands map to whatever the task's review surface is — sections of a document, or for code, PR comments, commit notes, or a running decision list. Treat them as adjustable, not sacred. State the scheme once at the start, and let the user **downgrade any single rating** ("treat that one as a fork") whenever they disagree with the calibration.

## How to surface a fork

When a decision clears the bar for surfacing:

- **Batch** related forks instead of drip-feeding them; resolve a cluster in one exchange.
- Give **2–4 concrete options**, each with its tradeoff in one line — not an open-ended "what do you want?".
- **Recommend one** and say why. The user is delegating judgment; offer yours.
- Keep it tight. A wall of questions is the same friction in a different costume. If there are many, present the most consequential first.
- For interactive sessions, prefer **one decision at a time** over a dump; pair with a structured question tool where available.

## The audit log

Auto-decided items must remain **reviewable** — silent does not mean hidden. Record each autonomous decision somewhere durable and scoped to the task: a decision log, an appendix section, or an inline note. Capture what was decided and, briefly, why. This lets the user audit the auto-decisions on their own schedule and override any of them without having been interrupted in the moment.

## Setup at task start

Open the task by establishing the mode, once:

- Confirm the **stakes level** of the overall task (a launch-critical artifact warrants more surfacing than a throwaway).
- State the routing rule (or the banded scheme) so the user knows what will and won't reach them.
- Invite downgrades: the user can promote any auto-decision to a fork at any time.

Then execute the task, applying the routing rule continuously and logging as you go.

## Anti-patterns

- **Surfacing to look diligent.** Raising high-confidence or low-stakes decisions "to be safe" defeats the entire purpose — it *is* the friction. If it's obvious or trivially reversible, decide it.
- **Auto-deciding a real fork.** Having *a* plausible answer is not the same as being confident it's the *right* one on a high-stakes choice. When uncertain and consequential, surface — do not quietly pick.
- **Skipping the log.** Auto-deciding without recording loses auditability and erodes trust. Every silent decision must be reconstructable later.
- **Treating cosmetics as forks.** Naming, wording, and formatting belong in a cleanup pass, never in a mid-task interruption.

## Trigger examples

These should activate the skill:
- "Just get the PRD done — only ask me about the stuff that really matters."
- "Don't hold my hand on this refactor."
- "Use confidence gating: handle the obvious calls, surface the real forks."
- "Minimize friction — I don't want to approve every line."
- "meaningful-fork triage for this migration."

These should not activate the skill:
- "Walk me through every change before you make it." — the user wants full consultation, not triage.
- "Rename this variable." — a single decision, nothing to triage.
- "What's the difference between X and Y?" — a question, not a delegated task.