doubt

Validate second-brain plugin behavior against code claims with layered adversarial checks.

Updated Apr 24, 2026
One-click install
npx skills add https://github.com/Cain-Ish/claude-code-plugin --skill doubt-cain-ish
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: doubt
Source: https://github.com/Cain-Ish/claude-code-plugin/tree/main/skills/doubt
Command: npx skills add https://github.com/Cain-Ish/claude-code-plugin --skill doubt-cain-ish

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

It reduces the risk that the second-brain plugin silently fails or drifts from its stated behavior by forcing you to read the real code and verify the real on-disk outputs through an adversarial, evidence-backed workflow.

Core Features & Use Cases

  • Layered architectural skepticism: Doubts specific plugin subsystems (hooks, stop-hook extraction, learning, MCP server, compaction, wiki maintenance) using a taxonomy mapped to concrete files.
  • History-aware question selection: Rotates focus across runs using git change recency and doubt-history rotation to avoid repeatedly asking the same weak questions.
  • Runtime artifact verification: Checks that expected files and state actually exist on disk, not just that code would write them.
  • Conversational branch drilling with citations: Generates multiple attack vectors per claim, escalates the highest-scoring branch first, and requires file:line grounding for pruned paths.
  • Quality-critic validation gate: Sends findings to a dedicated reviewer agent to confirm issues and catch systematic over-pruning.

Quick Start

Run doubt with no arguments to automatically select the most relevant plugin layers and adversarial perspectives, then produce a doubt session report with code citations and runtime-state checks.

Frequently Asked Questions about doubt

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I adversarially validate plugin correctness against runtime state?

You can validate plugin correctness by inspecting git history and filesystem state to verify expected runtime artifacts exist on disk, requiring evidence-first branching with file:line citations for any findings.

What is adversarial validation for plugin failure modes and race conditions?

It is a skeptical protocol that maps doubt to concrete files across plugin subsystems like hooks and MCP servers, checking correctness, failure modes, and integration gaps through conversational branch drilling.

How do I verify plugin runtime artifacts exist on disk and not just in code?

By running a doubt session that checks both source code and on-disk state, you confirm expected runtime artifacts physically exist, catching discrepancies between code logic and actual outputs.

Can I use git inspection to check plugin degradation over time?

Git inspection tracks change recency to rotate adversarial perspectives across runs, preventing repeated weak questions and surfacing fresh-install behavior, integration gaps, and gradual degradation over time.

Does adversarial validation require a reviewer gate for issue findings?

The reviewer gate requires confirmation for any ISSUE or FRAGILE findings, using a dedicated reviewer agent to validate issues and prevent over-pruning of adversarial branches during the validation process.

When should I not use an adversarial doubt protocol for quality assurance?

If your environment cannot support reviewer-gated confirmation or evidence-first branching with file:line citations, the doubt protocol cannot reliably validate plugin correctness or observability gaps.