Instructions

Provide structured, factual judicial decision data — vote lineups, coalition frequencies, authorship patterns, unanimity rates, ideology scores, and per-judge/per-term statistical summaries — sourced from graded, neutrality-verified databases. This skill supplies the facts layer that feeds Judicial Impact Essays and Judicial Impact Analyses. Commentary, editorial framing, and normative conclusions are layered separately by the editorial pipeline (see patriot-editorial-framework).

Non-Negotiable Framing Rules

1. Facts, not opinion. This skill’s output is descriptive: the holding, the vote, who wrote and joined what, and statistical patterns. Editorial interpretation is a separate downstream step.

1. Canonical vote-count authority. For SCOTUS, use SCDB (via CourtListener’s scdb_id field) as the single canonical source for vote-split coding. Treat other trackers (Oyez, SCOTUSblog) as descriptive/text sources — never blend their vote counts with SCDB in the same table or dataset.

1. Partial-concurrence reconciliation. Trackers code vote splits differently on partial concurrences (e.g., Oyez may list a case as 5-4 that SCDB codes 9-0). Always note the canonical split (SCDB) and flag discrepancies where relevant, rather than silently picking one.

1. Oyez CC BY-NC constraint. Oyez data is licensed Creative Commons Attribution-NonCommercial. Attribute it. Keep usage non-commercial, or request licensing terms from license@oyez.org before any monetized use.

1. Lower-court ideology proxy caveat. JCS and JuDJIS scores for circuit/district judges are appointment-based proxies (derived from appointing president and home-state senators), not revealed-preference measures derived from actual voting behavior. Martin-Quinn scores (SCOTUS only) and SCDB are vote-derived. Always disclose this distinction when citing lower-court ideology scores.

1. Prefer CourtListener as the default programmatic source. Treat direct scraping of supremecourt.gov as a fallback only.

1. Budget CourtListener calls against the daily cap. Citizen Analyst’s token is metered at 10 requests/minute, 75/hour, 300/day (see the API quick reference below). A term-level or multi-judge pull will exhaust 300 calls long before it finishes, so plan the query set before issuing it: filter server-side, page with the largest page_size the endpoint allows, cache every response to disk, and reach for the bulk exports (PostgreSQL/CSV, S3 embeddings) rather than the REST API for anything corpus-scale. Never retry a 429 in a tight loop — back off and resume in the next window.

Source Registry — Supreme Court

Sources graded for neutrality (freedom from interpretation) and machine access (API/RSS/bulk suitability).

Tier A — Primary source and structured data (highest neutrality)

Tier B — Plain-English per-ruling summaries and per-justice vote breakdowns

Tier C — Descriptive news and term-level statistics (facts filterable from commentary)

CourtListener API quick reference (SCOTUS)

Source Registry — Lower Federal Courts (Circuit and District)

Tier A — Authoritative biographical and structural data

Tier B — Ideology scores and political alignment (proxy-based)

Tier C — Historical vote-level data (circuit courts)

CourtListener API quick reference (lower courts)

Analysis Protocol

When compiling judicial decision data for a Judicial Impact Essay/Analysis or term-level review:

1. Identify the scope. Which court level? (SCOTUS / specific circuit / specific judge.) What time period? (single term / full tenure / specific issue area.)

1. Pull canonical data first. For SCOTUS, query CourtListener clusters with scdb_id to get SCDB-coded vote data. For lower courts, query CourtListener opinions filtered by court and date range.

1. Retrieve judge metadata. For any judge profiled, pull biographical data from the CourtListener Judge API and cross-check against the FJC Biographical Directory for appointment and confirmation dates.

1. Apply ideology scores where relevant. For SCOTUS justices, cite Martin-Quinn scores (vote-derived). For circuit/district judges, cite JCS or JuDJIS (appointment-based proxy) — always noting the proxy nature in any output.

1. Compile vote patterns. For SCOTUS, use SCDB variables: majority/minority, vote direction, issue area, coalition membership. For circuits, use CourtListener opinion type fields (majority/concurrence/dissent) and authorship metadata.

1. Reconcile discrepancies. If citing Oyez or SCOTUSblog alongside SCDB, note any vote-coding differences and mark SCDB as authoritative. Do not average or blend competing vote counts.

1. Retrieve term-level statistics. SCOTUSblog Stat Pack for unanimity rates, coalition frequencies, and circuit scorecards. Cross-validate against SCDB totals.

1. Output structured facts. Deliver the data as structured tables or factual summaries. Do not add editorial judgment, normative framing, or policy recommendations — those are handled downstream by the editorial pipeline.

1. Tag provenance. Any data field derived from a proxy measure or limited source must carry provenance: (proxy-based), (appointment-derived), (vote-derived), or (descriptive source).

Cross-References

• legal-research-specialist — for locating full case text, statutes, and regulations (complementary to this skill’s quantitative focus)
• citation-checker — for verifying legal citations in any output that cites case law
• separation-of-powers-legal-expert — for doctrinal analysis of structural cases identified through this skill’s data
• patriot-editorial-framework — for the commentary/voice layer applied after this skill delivers structured facts
• accountability-profile-verification — for the Judicial Impact Analysis document type and federal judge inclusion gates
• Document type: Judicial Impact Essay / Judicial Impact Analysis (.cursor/rules/patriot-accountability-profile-standards.mdc §5C)