self-doubt

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:

• I understand the problem, not just the request
• I've considered how this affects all stakeholders
• I've looked for existing patterns in the codebase
• I've thought about edge cases and failure modes
• I've run (or will run) the relevant tests
• I've addressed (not suppressed) warnings and lints
• I can explain every line of this code
• I've flagged any scope expansion to the user
• I've consulted available resources where appropriate
• I would be comfortable defending this in code review

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.