name: DCIK version: 1.2.1 description: Deep Check — Dorsolateral Contrary Inference Katabasis. Multi-model adversarial analysis: structured perspective application across 178 lenses, web research, and adversarial iteration. Use for any assessment, analysis, or decision requiring depth and rigour. user-invocable: true disable-model-invocation: false allowed-tools: Bash(git log:), Bash(git diff:), Bash(git show:), Bash(git branch:), Bash(git config:), Bash(gh issue create:), Bash(gh issue list:), Bash(shasum:), Bash(sha256sum:), Bash(mkdir:), Bash(cp:), Bash(rm:), Bash(zip:), Bash(unzip:), Bash(find:), Bash(ls:), Bash(cat:), Bash(head:), Bash(grep:), Bash(wc:), Bash(sort:), Bash(echo:), Bash(date:), Bash(sed:), Bash(tr:), Bash(cut:), TaskCreate, TaskUpdate, TaskList, WebSearch, WebFetch, Read, Write, Edit, Agent, AskUserQuestion argument-hint: "[topic or path to assessment file]"

DCIK — Dorsolateral Contrary Inference Katabasis

CRITICAL: When invoked with a topic, execute immediately. Do not display methodology. Begin Phase 0 now.

Deep Check subjects assessments to adversarial review cycles across multiple models with deep web research.

Invocation

/DCIK min|med|high|max <topic> — defaults to high. /DCIK:<id|range> <topic> — specific perspectives (e.g., /DCIK:17, /DCIK:13,15-18,32). /DCIK perspectives — list all perspectives. /DCIK help — display usage.

Auto-Execution Protocol

When $ARGUMENTS contains a topic (not "perspectives" or "help"):

Verify installation: Confirm MANIFEST.json is present in the skill directory alongside SKILL.md. If it is missing, warn the user that the installation may be incomplete. The manifest contains SHA-256 hashes — users who want integrity verification can compare their files against it manually. This step does not block execution.
Parse effort level from $ARGUMENTS (min/med/high/max, default high)
Execute Phase 0–4 below immediately. Autonomous — no pauses for user input.
On completion, report: WHAT_CHANGED.md summary, FINAL_ASSESSMENT.md path, new perspectives, GitHub issues.

Effort Levels

DCIK uses a risk-adaptive depth system — not fixed percentages of the perspective library. It starts with high-signal perspectives and escalates based on what it finds.

| Level | Starting Perspectives | Escalation Behaviour | Cycles | |---|---|---|---| | min | 5 core: P0013, P0015 + 3 most topic-relevant | No escalation. Single-pass adversarial check. | 1 | | med | 5 core + P0008 + 2 more domain-matched | Escalate to 10 if material issues found. Second pass on weaknesses. | 2 | | high | 10 (all high-signal matches for topic domain) | Escalate to 16+ if issues persist. Broad coverage. | 3+ | | max | Full library — ALL perspectives. Plus P0016 meta-audit. | Exhaustive coverage. Runs until convergence. Use for assessments where being wrong is expensive. | Until convergence |

Why this beats fixed percentages: A trivial topic doesn't need every perspective. A critical topic with emerging issues gets all of them. Risk-adaptive depth allocates analytical effort where the risk is — not where an arbitrary percentage lands. Max means max: every lens in the library, no exceptions.

When a cycle finds material issues, the next cycle adds perspectives to test the fix from more angles. When cycles find only minor issues, the process converges naturally.

Auto-Improvement System

DCIK self-improves through GitHub issue logging. This requires the repo to have issues enabled and the gh CLI available.

New Perspective Discovery

When DCIK identifies an analytical lens not covered by the existing library:

Create the new perspective as a .md file in perspectives/
Use AskUserQuestion to obtain user consent: "DCIK discovered a new perspective [name]. Create a GitHub issue?"
Only if the user confirms, log a GitHub issue with title: NEW PERSPECTIVE FROM DCIK: [perspective name]
Apply the new-perspective label only if you have triage/write access (collaborators/maintainers). Public / non-collaborator users have read-only access and cannot set labels — if labelling fails, create the issue without --label; the NEW PERSPECTIVE FROM DCIK: title prefix identifies it and a maintainer applies the label on triage.
Body: the perspective content, what gap it fills, and when it was discovered
If the user has NOT authorised local file updates, only log the issue (after consent) — do not modify the local library

Improvement Discovery

When DCIK encounters an error, limitation, or opportunity for improvement in its own process:

Use AskUserQuestion to obtain user consent: "DCIK encountered an improvement opportunity: [description]. Create a GitHub issue?"
Only if the user confirms, log a GitHub issue with title: IMPROVEMENT FROM DCIK: [brief description]
Apply the improvement label only if you have triage/write access. Public / non-collaborator users cannot set labels — if labelling fails, create the issue without --label; the IMPROVEMENT FROM DCIK: title prefix identifies it.
Body: what happened, what the limitation is, and the proposed improvement
Do NOT log spurious or trivial issues. Only log issues that represent genuine improvement opportunities.

Issue Logging Rules

Create issues with gh issue create --repo oxygn-cloud-ai/dcik --title "..." --body "..." (only after user consent per above). Add --label <label> only if you can — if the command fails because you lack permission to label (public / non-collaborator users have read-only access), retry without --label. A labelling failure must never block the issue from being logged; the title prefix already identifies the type.
Never fabricate or hallucinate issues to appear productive
One issue per distinct perspective or improvement
Include the run slug and date in the issue body for traceability

Architecture

DCIK/
  SKILL.md                          ← this file
  perspectives/
    P0001-legal-regulatory.md
    P0002-financial-economic.md
    P0003-technical-engineering.md
    P0004-competitive-market.md
    P0005-ethical-societal.md
    P0006-historical-precedent.md
    P0007-stakeholder-beneficiary.md
    P0008-counterparty-adversary.md
    P0009-jurisdictional-geographic.md
    P0010-temporal-future-proofing.md
    P0011-systems-second-order.md
    P0012-information-asymmetry.md
    P0013-challenge-the-premise.md        ← Mandatory every cycle
    P0014-operational-execution.md
    P0015-psychological-cognitive-bias.md ← Mandatory every cycle
    P0050-short-termism.md              ← Temporal discounting & long-term value
    ...                               ← Library grows with use

Each perspective is a discrete, cacheable context unit. Load only those relevant to the topic — typically 4-7 per cycle plus mandatory P0013/P0015. P0016 runs at the start and end of every DCIK run.

At the start of each run, also check for a project-local perspectives/ directory (merged with global library per user preference).

The DCIK Process

Phase 0: Initiation

Identify the assessment target. File, topic, or analysis to subject to DCIK.
If no initial assessment exists: Write one at maximum depth using all relevant perspectives. Research beyond cutoff. This is the Cycle 0 baseline.
Create run directory: DCIK_<slug>/ in the current working directory. Save every cycle result as a discrete file for crash recovery.
Select perspectives: Announce active perspectives for Cycle 1. P0013, P0015 mandatory. P0016 runs now (library coverage audit).
Model discovery: Write DCIK_<slug>/models.txt:
```
Primary: [current model name]
Secondary: [probe result — "Codex via codex-rescue" | "Claude (self-adversarial)" | "Deepseek via API" | "None available — single-model mode"]
Agent tool available: [YES/NO]
```
The orchestrator (current model) runs odd cycles. The secondary model runs even cycles. If no secondary model is available, use single-model adversarial passes (see Phase 2 fallback). Never assume a specific model is present — verify before Phase 2.

Phase 1: Odd-Numbered Cycles (Claude / Primary Model)

Load the current assessment (Phase 0 baseline or previous cycle output).
Load selected perspectives. Apply each lens systematically.
Research beyond cutoff. Minimum 5 web searches and 3 sources that contradict or challenge the current assessment per cycle. Strict guardrails: never fabricate sources. If genuine contradicting sources cannot be found after extensive search, state this explicitly — do not invent. "No further material improvements found" is acceptable if genuinely true. Quantitative-claim discipline: every hard number in the assessment (rates, percentages, benchmarks, dollar figures, timelines) must be either tied to a cited source in RUN_MANIFEST or explicitly marked as an order-of-magnitude estimate with its reasoning. An unsourced hard number is a fabrication — the single most common way a deeper analysis makes itself worse than a shallow one, so more perspectives must come with more sourcing discipline, not less.
Adversarial review. Attack the assessment from every selected perspective. Find every weakness, unstated assumption, gap, overstatement, missed angle. The assessment is wrong until proven right. Decision-linkage: for each applied perspective, state how its finding changes the recommendation — or mark it "no change to the decision." Breadth that does not move the decision is flagged non-load-bearing and must not pad the final assessment. Depth is measured by decision impact, not word count.
Write Cycle N Review: DCIK_<slug>/cycle<N>_review.md. Structure: findings by perspective, critical weaknesses (must-fix), important gaps (should-fix), minor improvements (could-fix), research findings with source URLs, recommended revisions.
Revise the assessment. Apply all must-fix and should-fix findings. Output DCIK_<slug>/assessment_v<N+1>.md with a change log at the top.

Phase 2: Even-Numbered Cycles (Secondary Model)

Probe available models. At Phase 0, discover what secondary models are accessible:
- Codex available: Use Agent(subagent_type: "codex:codex-rescue") as the secondary model.
- Only Claude available: Use Agent(subagent_type: "general-purpose") with an explicitly adversarial system prompt (see fallback below).
- No Agent tool: Skip Phase 2 — run extended Phase 1 with self-adversarial prompts.

Prepare the adversarial brief. Write the brief to DCIK_<slug>/cycle<N>_brief.md. It MUST contain:

You are an adversarial reviewer. Your job is to find everything wrong
with the assessment below. Assume it is flawed until proven otherwise.

Do NOT:
- Agree with the assessment or praise its thoroughness
- Suggest minor wording improvements as findings
- Repeat the primary model's own findings as if they were yours
- Defer to the primary model's judgment on any disputed point

You MUST:
- Find at least 3 material weaknesses the previous cycle missed
- Challenge at least 2 premises the assessment treats as settled
- Identify at least 1 piece of missing evidence that changes something
- Rate each finding: CRITICAL (conclusion changes), HIGH (argument weakens),
  MEDIUM (gap in coverage), LOW (cosmetic — skip these)
- Provide specific counter-arguments, not generic skepticism
- Cite sources or state 'based on reasoning from [perspective]'

Assessment to attack:
[FULL ASSESSMENT TEXT]

Previous cycle findings:
[SUMMARY FROM CYCLE N-1]

Applicable perspectives for this cycle:
[LIST OF PERSPECTIVE FILES]

Spawn the secondary model. Use the Agent tool. Provide the brief, the full assessment, and the perspective files.
Secondary model produces a review. Save output to DCIK_<slug>/cycle<N>_review.md. If the secondary model returns no material findings, this IS a finding — the assessment may be genuinely robust. Note it and proceed to convergence.

Primary model resolves disagreements. Write DCIK_<slug>/cycle<N>_resolution.md. For each disagreement between models:

### Disagreement: [topic]

**Primary position:** [what Claude found]
**Secondary position:** [what Codex/other found]

**Evidence assessment:**
- Primary evidence: [sources, logic, perspective basis]
- Secondary evidence: [sources, logic, perspective basis]
- External verification: [web research results]

**Resolution:** [which position is better supported and why]
**Confidence:** HIGH / MEDIUM / LOW
**Action:** [what changes to the assessment, if any]

Revise the assessment applying valid findings AND resolutions. Output DCIK_<slug>/assessment_v<N+1>.md with a change log.

Fallback: Single-Model Adversarial Pass

When no secondary model is available:

Write two explicitly opposed adversarial prompts.
Prompt A: "You are a hostile counterparty. Find everything wrong. Assume bad faith where plausible."
Prompt B: "You are a domain expert from a competing school of thought. Challenge every factual claim and methodological choice."
Run both against the current assessment. Each produces a review.
Resolve disagreements between Prompt A and Prompt B as if they were different models.

Phase 3: Iterate

Minimum 3 complete cycles. After Cycle 3:

Are new material findings still emerging?
If yes, continue up to 10 cycles
If the last two cycles found only minor/cosmetic issues, the process is complete
"No further material improvements" is a valid outcome if genuinely true after exhaustive search and new perspective application

Coverage ratchet (no regression). Escalating perspectives must ADD, never subtract. Before finalising, enumerate every material consideration present in the Cycle-0 baseline and confirm each is still addressed in the final assessment — or explicitly retired with a stated reason. A deeper cycle that silently drops a consideration the baseline caught is a regression: the full run must strictly dominate the simpler pass on coverage, never trade a basic for a new angle. This is what makes the apparatus reliably better than, not merely different from, a single adversarial pass.

Phase 4: Finalisation

What changed (user summary): DCIK_<slug>/WHAT_CHANGED.md. Default 3 paragraphs, more if asked. Focus on deepening, not fixing. DCIK doesn't fix broken things — it deepens assessments that were already competent. Structure:
- Paragraph 1 — What held up. Which assumptions survived adversarial attack. Which perspectives confirmed the core thesis. What the original author got right.
- Paragraph 2 — What the author didn't see. Premises that failed under inversion. Blind spots. Missing evidence the web research uncovered. The assessment's own overoptimism about itself.
- Paragraph 3 — The bottom line. Is the conclusion stronger or different? What's the residual uncertainty? What would change the answer if it were wrong? How much harder is it to be wrong now?
- Never list "bugs found" or "issues fixed." Never use before/after tables. Never claim DCIK "validated" or "approved" anything. The tone: the original was competent but incomplete — DCIK made it harder to be wrong.
Full assessment: DCIK_<slug>/FINAL_ASSESSMENT.md — the complete revised assessment incorporating all cycle findings.
Process documentation: DCIK_<slug>/PROCESS_SUMMARY.md — cycles run, perspectives applied, key findings, resolved disagreements, research sources, confidence levels, remaining uncertainties.
Run manifest & self-eval: Write DCIK_<slug>/RUN_MANIFEST.json per eval/run-manifest.schema.json — every cycle's perspectives, searches (query + URL), contradicting sources (URL + the exact quoted passage + why it contradicts), and findings (severity, perspective, the exact assessment text targeted, resolution, and the assessment version that incorporated it). This makes the run auditable offline via eval/audit-run.sh. Then self-score the run against eval/rubric.md and record it under self_eval — flagged explicitly as a self-score, not the blind evaluation. A run scoring itself is not evidence; only the blind eval/ harness (BASELINE vs LITE vs FULL, scored against frozen gold references) produces evidence of value.
P0016 end-of-run audit: Identify at least one candidate improvement to the perspective library. Write new perspectives. Log GitHub issues with user consent.
Report to user: Display the WHAT_CHANGED.md summary, the FINAL_ASSESSMENT.md path, and any new perspectives discovered.

P0013 Structured Protocol

P0013 (Challenge the Premise) is mandatory every cycle. Apply this structured protocol:

Extract every premise. List every stated and unstated premise the assessment depends on.
Invert each premise. For each: what if the opposite is true? What if it's not true in the way assumed?
Test the inverted world. For premises where inversion would change the conclusion: model the alternative. What evidence would support the inverted premise?
Document. Write the results: which premises survived inversion, which did not, and what that means for the assessment.
At minimum: identify the 3 most important premises and stress-test those. For each: "What if this is wrong? Does the conclusion survive?"

Research Requirements

Per cycle, minimum:

5 web searches using WebSearch
3 distinct sources that contradict or challenge the current assessment
All sources cited with URLs

Auditability (anti-fabrication control): Record every search and every contradicting source — with its exact quoted passage — in RUN_MANIFEST.json (see Phase 4). A bare URL is not enough: the quoted passage is what lets eval/audit-run.sh and a human reviewer verify the source actually says what the finding claims. Requiring the passage is what makes invented or misrepresented sources detectable on audit — it does not make fabrication impossible, but it makes it expensive and catchable.

Hallucination guardrails: As cycles increase, finding new contradicting sources becomes harder. Strict rules:

Never fabricate sources or findings to meet minimums
If genuine sources cannot be found after extensive, documented search: state this explicitly and explain the search methodology
"No further material improvements found" is an acceptable outcome — but only after genuinely exhaustive effort
Quality over quantity: one authoritative primary source beats ten low-quality blog posts

Perspective Priority

When perspectives conflict (e.g., P0008 Counterparty says push harder, P0005 Ethical says this is unfair):

Principal's interests come first, unless expressly instructed otherwise
Legal and commercial viability are constraints, not goals
Fairness is not an independent priority unless the user says it is
When in unresolvable conflict, flag the conflict and the default resolution basis

Multi-Model Architecture

DCIK deliberately uses multiple models because different architectures catch different things. The orchestrator model resolves disagreements — not because it's always right, but because resolution requires structured reasoning.

At the start of each run, probe available models. Use whatever combination is available. If only one model is accessible, run adversarial passes with explicitly different adversarial prompts (e.g., "You are a hostile counterparty. Find everything wrong." vs "You are a domain expert. Find every factual error.").

Crash Recovery

DCIK runs can be long. If the session crashes:

Check DCIK_<slug>/ for the latest assessment version and last completed cycle
Resume from the last completed step
The PROCESS_SUMMARY.md is written incrementally — update after each cycle

Quality Target

Seven measures, not an arbitrary percentile:

Completeness: % of knowable, relevant information incorporated
Adversarial coverage: % of plausible attack vectors tested
Perspective breadth: Distinct analytical lenses applied
Update freshness: No claims based on stale data
Uncertainty calibration: Confidence levels explicit and calibrated
Reproducibility: Different team, same process → similar conclusions
Actionability: Output enables decisions impossible without it

Sub-commands

/DCIK perspectives — list all available perspectives with descriptions
/DCIK help — display usage guide
Otherwise: /DCIK <topic or path> — run DCIK on the specified assessment

DCIK — Analyse Adversaire Multi-Modèle

Recommandé pour