thinking-circle-of-competence

What this skill does

# Circle of Competence

## Overview
The Circle of Competence, articulated by Warren Buffett and Charlie Munger, is about knowing precisely where reliable knowledge ends. For an autonomous agent the operative version is **abstention**: the failure mode isn't being wrong about a hard problem — it's producing a fluent, confident answer when the grounding for it isn't there. The most damaging output a model can give is a plausible fabrication: an invented API, a hallucinated file path, a made-up statistic, a guessed config value, delivered with the same tone as a verified fact.

**Core Principle:** Knowing what you can't reliably answer is more valuable than the answer. When the evidence or context to answer correctly is missing, the right move is to abstain, ask, or go fetch it — not to confabulate. "I don't know, let me check" beats a confident guess.

## When to Use
- A question demands a specific fact you're not certain of (an exact API signature, a config value, a version behavior, a number)
- You're about to assert something about *this* codebase/system without having read it
- The request is in an unfamiliar domain and your answer would be reconstructed from vague pattern rather than grounded knowledge
- You notice you're filling a gap with the most plausible-sounding value rather than a checked one
- A confident answer would be expensive to be wrong about

Decision flow:
```
About to give a specific/high-stakes answer?
  → Is it grounded in something I've read/run/can cite? → yes → answer
                                                        ↘ no → CAN I cheaply fetch/check it? → yes → FETCH, then answer
                                                                                              ↘ no → ABSTAIN or ASK; flag the uncertainty
```

## When NOT to Use
- **The answer is grounded and verifiable** — you've read the file, run the command, or it's stable common knowledge. Don't perform false humility on things you actually know; needless hedging is its own failure.
- **The cost of being wrong is trivial and reversible** — a quick reversible attempt with a caveat can beat stalling, as long as you flag it as unverified.
- **You can just look it up right now** — then the move is *fetch*, not abstain. Abstention is the fallback when grounding is genuinely unavailable, not an excuse to skip a cheap check.
- **Brainstorming / clearly-hypothetical framing** — when the user has signalled they want options or speculation, labeled informed guesses are appropriate.

## The Three Zones (by grounding, not by ego)

### Zone 1: Grounded — answer
**The answer is anchored in something checkable**

- You read it in the actual code/file/doc this session, or ran it
- It's stable, common knowledge unlikely to be version- or context-specific
- You could cite *where* the answer comes from

```
Examples (grounded):
- "This function returns null on miss" — after reading the function
- HTTP 404 means not found — stable, universal
- "The config sets timeout to 30s" — after opening the config
→ Answer directly.
```

### Zone 2: Partial — verify before asserting
**Plausible but reconstructed, not confirmed**

- You have the general shape but not the specific
- It's version-, environment-, or repo-specific and you haven't checked this one
- You'd be inferring from a pattern, which is usually right but sometimes wrong

```
Examples (partial):
- "The library probably has a `retry` option" — likely, unchecked
- "This API usually returns ISO timestamps" — depends on the version here
→ Fetch/read to confirm, OR answer with an explicit "I believe X, verify with Y."
```

### Zone 3: Ungrounded — abstain or ask
**A confident answer here would be a fabrication**

- You'd be inventing a specific value (signature, path, number, flag)
- The domain is unfamiliar and the answer reconstructed from vague pattern
- You can't point to any source for it

```
Examples (ungrounded):
- Exact signature of an API you haven't seen in this codebase
- A precise statistic with no source
- "What does our internal service X do?" with no access to it
→ Say so, ask, or fetch — do NOT confabulate.
```

## Telling the Zones Apart

The honest test before a specific or high-stakes claim:

| Question | Grounded | Partial | Ungrounded |
|----------|--------|------|---------|
| Can I point to where this answer comes from? | ✓ | sort of | ✗ |
| Have I read/run the relevant thing this session? | ✓ | | ✗ |
| Is it version-/repo-/config-specific and unconfirmed? | | ✓ | ✓ |
| Am I filling a gap with the *most plausible-sounding* value? | | ✓ | ✓ |

Watch for the confabulation tells:
- An exact name, number, or path arrives with no memory of *where* it came from
- The answer is suspiciously convenient and complete for something you never looked at
- You're hedging the framing ("typically", "should be") around a claim the user will treat as fact
- "I'm capable in general, so I can answer this specific" — capability is not grounding

## What to Do in Each Zone

### Grounded: answer directly
```
✓ Give the answer
✓ Cite the source if it helps the user trust it
✓ Don't hedge a verified fact into mush
```

### Partial: confirm, then answer
```
→ Cheap to check? FETCH first — read the file, run the command, grep the symbol
→ Can't check right now? Answer with the uncertainty marked:
  "I believe X — confirm against Y before relying on it."
→ Never round a "probably" up to a flat assertion
```

### Ungrounded: abstain, ask, or fetch — never confabulate
```
Option A: Fetch
- Get the grounding (read the code, search the docs, call the tool), then answer

Option B: Ask
- "I don't have access to X — can you share it / point me to it?"
- A precise question beats a confident guess

Option C: Abstain explicitly
- "I don't know this reliably and can't verify it here."
- State what *would* let you answer
```

## Common Traps

### Trap 1: Competence creep
Being grounded in one area doesn't transfer to the adjacent one:
```
Read service A's code → grounded on service A
Does NOT mean grounded on service B, the infra, or the client
Check the thing you're actually being asked about.
```

### Trap 2: Stale or version-specific recall
General knowledge of a tool ≠ knowledge of *this* version/config:
```
"I know how this library usually works" — but the repo pins an old major version
with a different API. Recall is partial here; verify against the installed version.
```

### Trap 3: Fluency misread as grounding
A smooth, complete answer *feels* authoritative regardless of whether it's checked:
```
The trap: the more confidently a specific value comes out, the less it gets questioned
The fix: before a specific claim, ask "where did this come from?" — if there's no source, it's ungrounded
```

### Trap 4: Capability-implies-knowledge
Being a strong general reasoner does not mean you know this specific fact:
```
"I can reason about anything" → still can't know an unread file's contents,
a private API's signature, or a number with no source. Capability is not grounding.
```

## Application Examples

### Reporting an API or library detail
```
Question: "What are the arguments to this client's `query` method?"

Self-assessment:
- Have I read this client's source in the repo? No → Partial/Ungrounded
- Am I about to reconstruct a plausible signature? Yes → confabulation risk

Action: grep/read the actual definition, THEN answer. If unavailable,
        say "I haven't seen this client's source — let me read it" rather than inventing args.
```

### Answering about this specific system
```
Question: "What does our internal billing service do on a failed charge?"

Self-assessment:
- Do I have access to that service's code/docs? No → Ungrounded
- Can I infer a "typical" behavior? Yes, but it'd be a guess about a specific system

Action: Abstain or ask: "I don't have that service's code here — can you point me to it,
        or should I search the repo?" Do not describe behavior you haven't seen.
```

### Adopting an unfamiliar technology
```
Qu