lhl/realitycheck/rc-analyze

Manual 3-Stage Analysis

Perform a full 3-stage analysis following the Reality Check methodology. Use for manual analysis without automatic database registration.

Usage

/skill:rc-analyze <url_or_source_id>

Perform a full 3-stage analysis following the Reality Check methodology. Use this for manual analysis when you want to review claims before registering them.

Prerequisites

Environment

Set REALITYCHECK_DATA to point to your data repository:

export REALITYCHECK_DATA=/path/to/realitycheck-data/data/realitycheck.lance

The PROJECT_ROOT is derived from this path - all analysis files go there.

CLI Commands

Reality Check provides CLI tools (rc-db, rc-validate, rc-export, rc-embed).

Check availability:

which rc-db  # Should show path if pip-installed

If commands are not found, either:

1. Install: pip install realitycheck (recommended)
2. Use uv run from framework directory: uv run python scripts/db.py ...
3. Add framework as submodule and use: .framework/scripts/db.py ...

Red Flags: Wrong Repository

IMPORTANT: Always write to the DATA repository, never to the framework repository.

If you see these directories, you're in the framework repo (wrong place for data):

• scripts/
• tests/
• integrations/
• methodology/

Stop and verify REALITYCHECK_DATA is set correctly.

Data Source of Truth

LanceDB is the source of truth, not YAML files.

• Query sources: rc-db source get <id> or rc-db source list
• Query claims: rc-db claim get <id> or rc-db claim list
• Search: rc-db search "query"

Ignore YAML files like claims/registry.yaml or reference/sources.yaml - these are exports/legacy format.

Fetching Content

To retrieve and parse source content:

• Primary: WebFetch for most URLs
• Alternative: curl -L -sS "URL" | rc-html-extract - --format json
• rc-html-extract returns structured {title, published, text, headings, word_count}

Methodology

Stage 1: Descriptive Analysis

• Summarize the source neutrally
• Extract key claims, predictions, and assumptions
• Identify theoretical lineage (what traditions/thinkers it builds on)
• Map argument structure (chain arguments, logical flow)
• Note scope and domain (what does this attempt to explain?)
• Define key terms with operational proxies

Stage 2: Evaluative Analysis

• Assess internal coherence and logical consistency
• Evaluate evidence quality using Evidence Hierarchy (E1-E6)
• Verify key factual claims (especially crux claims)
• Search for disconfirming evidence (5 min minimum)
• Check for internal tensions/self-contradictions
• Note persuasion techniques and rhetorical devices
• Identify unstated assumptions and dependencies
• Flag unfalsifiable claims

Stage 3: Dialectical Analysis

• Steelman the strongest version of the argument
• Identify strongest counterarguments and counterfactuals
• Consider base rates and historical analogs
• Map relationships to other theories (supporting/contradicting)
• Synthesize: where does this fit in the broader landscape?

Neutral Analyst Prose Pass

Before finalizing an analysis or synthesis, run a short pass over the analyst-authored prose.

Scope:

• Applies to the analyst's prose: summaries, thesis statements, evidence

assessments, credence reasoning, synthesis notes, and recommendations.

• Does not apply to source text, direct quotes, titles, quoted slogans, or

sections that intentionally analyze rhetoric/persuasion techniques.

• Preserve source wording when it is evidence for rhetoric, framing, or

persuasion. Label it as source language instead of adopting it as the analyst's voice.

Rewrite rules:

• State facts, claim IDs, dates, sources, methods, search results, evidence

levels, credences, falsifiers, and open questions directly.

• Remove rhetorical setup, marketing language, reassurance frames, vague

intensifiers, hedge stacks, and conclusion recaps from analyst prose.

• Replace vague quantifiers (many, several, various) with counts, IDs,

bounded scopes, or unknown.

• Do not change claim IDs, evidence levels, credences, source-backed facts, or

quotes unless the analysis records why.

Evidence Hierarchy

Use this hierarchy to rate strength of evidential support for claims.

Claim Types

Output

Generate:

1. Analysis document following the 3-stage methodology
2. Extracted claims formatted for database registration

Rigor contract (v1):

• Claim tables should include Layer, Actor, Scope, and Quantifier fields (see docs/WORKFLOWS.md → “Analysis Rigor Contract (v1)”).
• Include a Corrections & Updates section (including capture failures and recency checks) for auditability.

After analysis, register manually:

rc-db source add --id "..." --title "..." --type "..." --author "..." --year YYYY --url "..."
rc-db claim add --id "..." --text "..." --type "[F]" --domain "..." --evidence-level "E2" --credence 0.XX --source-ids "..."

Or use /skill:check for fully automated analysis + registration.

Web Access

This workflow may require web fetch and/or web search. Use whatever web tools are available in your environment.

If you have no web tools installed, fall back to:

curl -L -sS "URL" | rc-html-extract - --format json

We recommend installing one of these pi web packages:

pi install npm:pi-web-access        # web search + fetch + video, zero-config (most popular)
pi install npm:pi-smart-fetch       # best content extraction, browser-like TLS
pi install npm:@the-forge-flow/camoufox-pi  # stealth browser for bot-protected pages

Related Skills

• /skill:check
• /skill:rc-extract