CtrlK
BlogDocsLog inGet started
Tessl Logo

doubt-driven-development

Subjects every non-trivial decision to a fresh-context adversarial review before it stands. Use when correctness matters more than speed, when working in unfamiliar code, when stakes are high (production, security-sensitive logic, irreversible operations), or any time a confident output would be cheaper to verify now than to debug later.

54

Quality

60%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./skills/doubt-driven-development/SKILL.md

The canonical home for this skill is doubt-driven-development in addyosmani/agent-skills

SKILL.md
Quality
Evals
Security

Quality

Content

62%Scale 1-3

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

This is a well-structured, highly actionable skill with excellent workflow clarity and concrete guidance at every step. Its primary weakness is verbosity — the content is roughly 2-3x longer than necessary, with redundant sections (Red Flags repeating process constraints, Common Rationalizations restating body content) and over-specified edge cases (cross-model CLI handling alone is ~60 lines). The skill would benefit significantly from aggressive compression and offloading detailed subsections to bundle files.

Suggestions

Compress the cross-model escalation section (~60 lines) into a referenced file, keeping only a 5-line summary in the main body with a pointer to the detailed guide.

Merge or eliminate redundancy between 'Red Flags' and the process steps — most red flags are just negations of instructions already given in Steps 1-5.

Cut the 'Common Rationalizations' table by at least half — entries like 'Two opinions are always better than one' and 'The reviewer disagreed so I was wrong' restate the RECONCILE step's guidance.

DimensionReasoningScore

Conciseness

The skill is extremely verbose at ~300+ lines. While the domain is complex, there is significant redundancy: the 'Common Rationalizations' table repeats points already made in the body, 'Red Flags' duplicates constraints from the process steps, and cross-model escalation alone consumes ~60 lines with excessive edge-case handling. Many points could be compressed 2-3x without losing clarity. Claude doesn't need explanations like 'A confident answer is not a correct one' or why debugging production bugs is expensive.

1 / 3

Actionability

The skill provides highly concrete, executable guidance: a copy-paste checklist, specific adversarial prompt text, exact shell commands for cross-model invocation (with proper escaping guidance), a clear classification framework (contract misread / actionable / trade-off / noise) with precedence ordering, and concrete CLAIM examples. Every step has specific, actionable instructions rather than vague direction.

3 / 3

Workflow Clarity

The 5-step process is clearly sequenced with explicit validation checkpoints: Step 5 defines bounded stop conditions (trivial findings, 3 cycles, user override), Step 4 has a structured classification with precedence order, and there are explicit feedback loops (fix and re-loop for actionable findings, fix contract and re-classify for contract misreads). The 'doubt theater' red flag even provides a meta-validation checkpoint for the process itself.

3 / 3

Progressive Disclosure

The skill references external files (agents/, references/orchestration-patterns.md, other skills) with clear signaling, but the main body itself is monolithic — the Common Rationalizations table, Red Flags list, cross-model escalation details, and Loading Constraints could all be split into referenced files. For a skill this long, more content should be offloaded to supporting documents rather than inlined.

2 / 3

Total

9

/

12

Passed

Description

57%Scale 1-3

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

The description has a strong 'Use when...' clause with multiple explicit trigger conditions, which is its main strength. However, it suffers from vague capability description — 'adversarial review' doesn't convey concrete actions like what the skill actually does (e.g., generates counterarguments, runs test cases, checks edge cases). The abstract framing makes it hard to distinguish from other review/verification skills.

Suggestions

Replace 'subjects every non-trivial decision to a fresh-context adversarial review' with concrete actions, e.g., 'Generates counterarguments, identifies edge cases, stress-tests assumptions, and validates logic in code decisions'

Add natural user-facing trigger terms that people would actually say, such as 'double-check', 'verify', 'sanity check', 'review my approach', 'am I missing something'

Narrow the scope to reduce conflict risk — specify what types of decisions (architecture choices, algorithm selection, security patterns) rather than 'every non-trivial decision'

DimensionReasoningScore

Specificity

The description uses abstract language like 'non-trivial decision' and 'adversarial review' without listing concrete actions. It doesn't specify what kind of review is performed, what outputs are produced, or what specific techniques are used. 'Subjects every non-trivial decision to a fresh-context adversarial review' is vague about what actually happens.

1 / 3

Completeness

The description answers both 'what' (subjects decisions to adversarial review) and 'when' with an explicit 'Use when...' clause listing multiple trigger conditions: correctness over speed, unfamiliar code, high stakes, production, security-sensitive logic, and irreversible operations.

3 / 3

Trigger Term Quality

It includes some relevant terms like 'production', 'security-sensitive logic', 'irreversible operations', 'unfamiliar code', and 'correctness' that users might mention. However, it lacks natural user-facing trigger terms — users are unlikely to say 'adversarial review' or 'fresh-context'. Missing terms like 'review', 'double-check', 'verify', 'sanity check' that users would naturally use.

2 / 3

Distinctiveness Conflict Risk

The concept of 'adversarial review' is somewhat distinctive, but the broad scope ('every non-trivial decision') and triggers like 'unfamiliar code' and 'production' could overlap with code review skills, testing skills, or general quality assurance skills. The description doesn't carve out a sufficiently narrow niche.

2 / 3

Total

8

/

12

Passed

Validation

100%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation11 / 11 Passed

Validation for skill structure

No warnings or errors.

Repository
finlay611/agent-skills
Reviewed

Table of Contents

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.