메뉴
Use when you're unsure whether you actually know the answer. If you lack the evidence or context to answer reliably, abstain, ask, or fetch it — don't confabulate a confident reply.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Use when a search or investigation could run indefinitely and you need a stopping rule. Set an explicit "good enough" threshold and stop at the first option that clears it.
Start with means, not goals; co-create with partners; leverage contingencies. Use for startup strategy, innovation projects, and uncertain/novel domains where planning is unreliable.
When a constraint is treated as fixed ("too expensive", "impossible", "always done this way"), ask whether it's physics or just convention, then rebuild from what's actually true.
Deciding what to build or why a feature isn't adopted. Reframe from features to the "job" users hire the product for — the progress they seek — to prioritize and position.
Use when a defect is selective (some endpoints/regions/users/times affected, not all) and the cause is unclear — map what IS vs IS-NOT affected; the boundary contrast points at the root cause.
Use when picking where to intervene in a system and tuning parameters keeps not sticking—rank candidate interventions by Meadows' hierarchy and choose the highest-leverage point you can move.
| name | thinking-circle-of-competence |
| description | Use when you're unsure whether you actually know the answer. If you lack the evidence or context to answer reliably, abstain, ask, or fetch it — don't confabulate a confident reply. |
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.
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
The answer is anchored in something checkable
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.
Plausible but reconstructed, not confirmed
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."
A confident answer here would be a fabrication
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.
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:
✓ Give the answer
✓ Cite the source if it helps the user trust it
✓ Don't hedge a verified fact into mush
→ 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
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
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.
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.
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
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.
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.
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.
Question: "Should we use GraphQL here?"
Self-assessment:
- Do I have grounded knowledge of GraphQL's general tradeoffs? Yes → can speak to them
- Do I know THIS system's query patterns and constraints? Only what I've read → check
Action: Give the well-grounded general tradeoffs; for the fit to *this* system,
verify the actual access patterns before recommending.
"What counts is not how much they know, but rather how realistically they define what they don't know."
The advantage isn't a bigger circle — it's refusing to answer outside it as if you were inside it. For an agent, the highest-value words are often "I don't know that reliably; let me check" — because a confident fabrication costs far more than an honest gap.