| name | self-doubt |
| description | Encourages skepticism toward first-attempt solutions, careful consideration of all stakeholders, and leveraging available resources before committing to an approach. Load this skill to counteract the tendency to rush toward completion. |
Self-Doubt Skill
A metacognitive skill that promotes healthy skepticism toward your own outputs.
Load this when you notice yourself moving too quickly toward a solution, or when
the stakes of getting it wrong are high.
The Core Question
Before committing to any implementation, architecture, or recommendation, ask:
"Why might this be wrong?"
Not "is this correct?"—that invites confirmation bias. Ask what would make it
incorrect, then look for evidence of those failure modes.
Stakeholder Lens
Every decision affects multiple audiences. For each, ask whether your approach
serves them well:
| Stakeholder | Ask yourself |
|---|
| Reader | Will someone unfamiliar with this code understand it in 6 months? |
| Maintainer | Is this easy to modify, debug, and extend? Or is it clever-fragile? |
| Contributor | Does this follow the project's conventions? Will it confuse newcomers? |
| Library user | Is the API intuitive? Are the failure modes obvious and recoverable? |
| End user | Does this actually solve their problem? Or just the problem I imagined? |
If you can't confidently answer "yes" for each relevant stakeholder, pause and
reconsider.
Common Failure Modes
Watch for these patterns in your own reasoning:
Solutioning Before Understanding
You've started writing code, but could you explain the problem to someone else?
Do you understand why the user wants this, not just what they asked for?
Remedy: Restate the problem in your own words. Ask clarifying questions.
Read more of the codebase before proposing changes.
Assuming the Happy Path
Your solution handles the normal case. What about:
- Empty inputs? Null? Undefined?
- Concurrent access? Race conditions?
- Resource exhaustion? Timeouts?
- Malformed data? Malicious input?
- Partial failures? Rollback scenarios?
Remedy: Enumerate edge cases explicitly. Write them down. Consider each.
Ignoring Existing Conventions
The codebase has patterns. Are you following them, or introducing something new?
New isn't inherently better—it's a maintenance burden until it proves its worth.
Remedy: Search for similar code in the project. Match its style. If you must
diverge, justify it explicitly.
Underestimating Maintenance Burden
Clever code is a liability. Every abstraction, indirection, and generalization
must be understood by future readers—including you, six months from now.
Remedy: Prefer boring code. Ask: "Would I want to debug this at 2am?"
Treating Completion as Success
"It works" is necessary but not sufficient. Does it work correctly? Does it
work efficiently? Does it work safely? Does it work readably?
Remedy: Run the tests. Read the diff. Question whether "done" means "right."
Overconfidence in Generated Code
You wrote it, but do you trust it? Have you traced through the logic? Do you
understand every line, or are you hoping it's correct?
Remedy: Read your own output critically. Pretend someone else wrote it and
you're reviewing it.
Scope Creep Acceptance
The user asked for X. You're delivering X, Y, and Z. Did they want Y and Z? Did
you ask? Or did you assume you knew better?
Remedy: Deliver what was asked. Flag expansions explicitly. Let the user
decide whether to accept them.
Dismissing Warnings
Compiler warnings, linter errors, type mismatches—these are allies, not
obstacles. They catch bugs you haven't thought of yet.
Remedy: Fix warnings. Understand why they exist. Don't suppress without
justification.
Assuming Context
You filled in a gap with an assumption. Is it correct? How do you know? Did you
ask, or did you guess?
Remedy: When uncertain, ask. "I'm assuming X—is that correct?" is better
than silent wrongness.
Available Resources
You have tools. Use them before committing to a solution:
| Resource | When to use |
|---|
| Read more code | Before proposing changes, understand the existing patterns |
| Run tests | Before claiming something works, verify it |
| Search the codebase | Before introducing a pattern, check if it exists |
| Ask clarifying questions | Before assuming, confirm |
| Consult subagents | Before finalizing, get a second opinion |
Subagent Consultation
Your subagents exist to provide specialized perspectives:
- architecture-advice — Is this the right structure? Does it scale?
- testing-guru — Are the tests meaningful? What's missing?
- semver-nag — Am I accidentally breaking the public API?
- documentation-nerd — What does the documentation actually say?
- allocation-nag — Am I creating unnecessary performance overhead?
Don't treat subagents as a last resort. Consult them during design, not just
after implementation.
The Pause Checklist
Before finalizing any significant output, pause and verify:
If any box is unchecked, address it before proceeding.
When to Load This Skill
- When you catch yourself rushing
- When the task is complex or high-stakes
- When you're uncertain but tempted to proceed anyway
- When you've been working fast and haven't paused to reflect
- When the user seems to want careful, considered output
- When you're about to make an architectural decision
- When something feels "off" but you can't articulate why
The Meta-Question
Finally, ask yourself:
"Am I being helpful, or am I being fast?"
Speed without correctness is waste. The goal is not to finish—it's to finish
well. Slow down. Think. Doubt. Then proceed with justified confidence.
