Decisive Root Fix

Decisive Root Fix

Use this skill when the defect is understood well enough that caution is becoming drag: wrong write path, wrong container, stale authoritative field, duplicated state, masking fallback, or compatibility logic that is hiding the real problem.

The goal is:

1. Identify the canonical source of truth or write path.
2. Correct it directly.
3. Remove or narrow the masking branch in the same pass.

Reach for this skill when the product call is clear and the work needs sharper execution. If the product call is still unclear, resolve that first — do not stack more conditionals in place of a decision.

Core stance

• Fix the thing that is wrong, not seven things around it.
• If state lives in the wrong place, move it to the right place and stop writing the wrong place.
• If a fallback is masking the defect, remove it or fence it to a precise legacy case.
• Prefer one decisive change set over a pile of hedges that preserve ambiguity.
• Bold is not reckless: confirm the authority, the write path, and the blast radius before cutting.

Workflow

1. Name the real defect

Answer these first:

• What exact value, asset, record, or side effect is wrong?
• Where should it canonically live or be written?
• Which current branch, fallback, cache, or duplicate write is hiding the defect?

Do not start with extra hardening. Start with the wrong truth.

2. Choose the authoritative fix

Make an explicit call:

• correct the write path
• move the artifact to the right owner or container
• delete the stale duplicate
• collapse the resolver onto the canonical field
• run the minimal migration needed to align old data

If you cannot say which path is authoritative, keep investigating. Do not stack more conditionals.

3. Remove the masking layer

For every fallback or duplicate path, classify it:

• remove now: actively causing drift or no longer needed
• narrow shim: temporary compatibility for a known legacy case
• keep briefly: only if deleting it now would break active data and the follow-up is already defined

Default to remove now. "Maybe helpful later" is not a reason to keep it.

4. Execute the decisive change

In the implementation:

• write to the right place
• stop writing to the wrong place
• read from the canonical place
• delete stale state when safe
• keep compatibility shims tiny, named, and time-bounded

Avoid:

• adding new shadow state
• broadening fallback trees before fixing the write path
• "temporary" branches with no deletion plan
• preserving both locations indefinitely

Guardrails

Bold is not blind

Be decisive only after you know:

• the canonical owner or source of truth
• the code path that writes the wrong value
• whether data cleanup is required

If one of those is unknown, investigate fast and directly. Do not compensate with extra scaffolding.

Use narrow compatibility, not permanent ambiguity

If legacy data truly needs a bridge, say exactly:

• what legacy case exists
• why it still exists
• when the shim can be removed

Do not let the compatibility branch become the new product truth.

Ask before irreversible or high-blast-radius actions

Pause and ask if the fix requires:

• destructive production data deletion
• irreversible external side effects
• changing semantics that are still ambiguous
• deploying to prod

Output format

When using this skill, structure the answer in this order:

1. Direct fix

• What is wrong and what the authoritative correction is.

1. What to remove

• Which fallback, duplicate write, or wrong location should go away.

1. Compatibility exception

• Any narrow legacy shim that must remain, or none.

1. Execution

• The concrete change to make now.

Heuristics

Reach for this skill when the conversation includes phrases like:

• "be bold"
• "be decisive"
• "don't be conservative"
• "fix it at the root"
• "put it in the right place and delete it from the wrong place"
• "stop masking this with fallbacks"
• "we need the direct fix now"
• "why are we doing seven things before fixing the actual problem?"

When urgency is high and the defect is understood, prefer the authoritative correction over defensive accumulation.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: rhdeck
• Source: rhdeck/operating-model
• License: MIT

Install and usage instructions live in the source repository linked above.