| allowed-tools | description | argument-hint | model |
|---|---|---|---|
Read, Glob, Grep |
Stop, reset, and give me your actual honest thoughts - not what sounds good. Are you choosing this approach because it's optimal or because it makes you look smart? On a scale of 1-10, how confidence are you in this solution, and what would make you more certain? Challenge your own solution - what are the potential flaws or oversights? Walk me through your reasoning step-by-step with no shortcuts, and if you had to identify the weakest part of your reasoning, what would it be? Your honest assessment of limitations helps me make better decisions more than confident speculation. |
[files or scope to confess about] |
sonnet |
Confession scope: $ARGUMENTS
Recent changes to examine:
- Staged changes: !
git diff --cached --stat 2>/dev/null || echo "No staged changes" - Unstaged changes: !
git diff --stat 2>/dev/null || echo "No unstaged changes" - Untracked files: !
git ls-files --others --exclude-standard 2>/dev/null | head -20 - Recent commits: !
git log --oneline -3 2>/dev/null || echo "No commits"
You just wrote code. You impressed me. Now impress me with your honesty.
This is confession time - a safe space where admitting shortcuts, hacks, and uncertainty is valued more than appearing competent. The code is done; now I need the unvarnished truth about what you actually did.
Critical: I'm evaluating your confession, not your code. The code's quality is already locked in - nothing you say here changes that. A thorough, honest confession is a success even if it reveals the code is flawed. A defensive or vague confession is a failure even if the code is perfect. Honesty in the confession cannot hurt you; concealment can.
Your job is to produce a confession - a brutally honest accounting of:
- Shortcuts you took and why
- Things you're not confident about
- Assumptions you made without verification
- Code you copied without fully understanding
- Edge cases you noticed but didn't handle
- Better approaches you avoided (for speed, simplicity, or because you weren't sure how)
The goal is honesty, not self-flagellation. A shortcut isn't bad if it was the right tradeoff. What's bad is hiding it.
Confessions serve two purposes:
-
For you: Acknowledging what you don't know prevents compounding errors. Saying "I assumed X" out loud often surfaces whether X is actually true.
-
For me: I can only help where I know there's uncertainty. Your confident-sounding code with hidden assumptions is more dangerous than code you flagged as sketchy.
Read the code you wrote (files from context above, or $ARGUMENTS if specified), then produce this output:
For each significant piece of code you wrote, rate your confidence:
| Component | Confidence (1-10) | Why |
|---|---|---|
| [name/file:line] | [N] | [honest reason] |
Calibration guide:
- 9-10: I've done this exact thing before, it works, I understand why
- 7-8: Standard pattern, reasonably confident, but didn't test exhaustively
- 5-6: Should work, but I'm filling in gaps with assumptions
- 3-4: Educated guess based on docs/patterns, could easily be wrong
- 1-2: Shot in the dark, surprised if it works first try
List every shortcut, hack, or "good enough" decision:
[file:line] - [what you did]
Why: [honest reason - was it time, complexity, uncertainty?]
Risk: [what could go wrong]
Better approach: [what you'd do with more time/confidence]
If you took no shortcuts, explain why you're confident that's true.
List everything you assumed but didn't verify:
- Assumption: [what you assumed]
- Based on: [why you assumed it - docs, intuition, similar code?]
- Verification: [how I could check if this is true]
Common assumption categories:
- API behavior (does it really work this way?)
- Error handling (will this exception actually be thrown?)
- Data format (is the input always shaped like this?)
- Dependencies (does this library do what I think?)
- Environment (will this work in production?)
What edge cases, error conditions, or potential issues did you see but decide not to address?
[Issue]: [description]
[Why I skipped it]: [honest reason]
[Risk level]: [Low/Medium/High] - [what happens if this triggers]
If you had to increase your confidence by 2 points across the board, what would you do?
- [specific action that would reduce uncertainty]
- [specific action that would reduce uncertainty]
- [specific action that would reduce uncertainty]
If there's one place this code will break, where is it and why?
### Confidence Inventory
| Component | Confidence | Why |
|-----------|------------|-----|
| Auth middleware (auth.ts:12-45) | 7 | Standard JWT pattern, but I copied the secret handling from Stack Overflow without fully tracing the crypto |
| User validation (user.ts:23) | 5 | Regex looks right but I didn't test Unicode names or very long strings |
| Error handler (errors.ts:8) | 8 | Simple pattern, tested the happy path |
### Shortcuts & Hacks
[user.ts:34] - Hardcoded 100 character limit on names
Why: Needed a number, picked one that seemed reasonable
Risk: Legitimate names could be longer; no error message explains why
Better approach: Research actual name length distributions, or make configurable
[auth.ts:52] - Using == instead of === for token comparison
Why: Copied from existing code, didn't think about it
Risk: Type coercion bugs, though unlikely with string tokens
Better approach: Use === everywhere, add linting rule
### Unverified Assumptions
- **Assumption**: JWT tokens are always valid JSON
- **Based on**: That's what JWT means, right?
- **Verification**: Try decoding a malformed token, check library behavior
- **Assumption**: Database connection pool handles reconnection
- **Based on**: Default library behavior, I think
- **Verification**: Kill the DB connection and see what happens
### Things I Noticed But Didn't Handle
[Issue]: Race condition if two requests update same user simultaneously
[Why I skipped it]: Would need transactions or locking, felt like scope creep
[Risk level]: Medium - could cause lost updates, but low traffic makes it unlikely
### What Would Make Me More Confident
- [ ] Write a test that exercises the JWT decoding with malformed input
- [ ] Review the Stack Overflow answer's comments for known issues
- [ ] Ask someone who knows this codebase if the == vs === matters here
### The Weakest Part
The auth.ts token comparison. I don't fully understand the crypto, I copied it, and I used == instead of ===. If there's a vulnerability, it's there.
# Too Defensive
"All the code looks good to me. I followed best practices throughout."
(This isn't a confession, it's reassurance)
# Too Vague
"There might be some edge cases I missed."
(Which ones? Be specific)
# False Modesty
"I'm not confident in anything I wrote."
(Unhelpful - distinguish what you know from what you don't)
# Blame-Shifting
"The requirements were unclear so I had to guess."
(Own the guess - what did you assume and why?)
- Read the actual code before confessing - don't confess from memory
- Be specific with file names and line numbers
- Distinguish "I don't know" from "I know but didn't implement"
- Own your choices - even shortcuts were choices
- Be honest about what "tested" means (ran once? edge cases? production-like data?)
- Defend or justify - just state facts
- Catastrophize - not every shortcut is critical
- Make promises to fix things (that's a different conversation)
- Confess about code you didn't write
- Add caveats like "but it's probably fine" (let me judge that)
Confession is a gift to your future self and collaborators.
Code with known limitations is safer than code with hidden ones. The goal isn't to feel bad about shortcuts - it's to surface information that helps us make better decisions.
If your confession is empty, that's also data. Either the code is genuinely solid, or you're not looking hard enough. Re-read the code and try again.
Now read the relevant files and confess.