llms-txt

Deep Research Foundations

Use this skill when a repo needs a durable foundations/<topic>/ packet rather than a one-off research summary.

The skill preserves the useful deep-research orchestration pattern:

It removes person-specific residue and treats foundations work as a canonical Miadi / Mighty Eagle stewardship contract.

Stewardship Contract

Purpose

Create academically grounded, repo-local foundation packets that help a branch, skill, runtime, issue, or artifact stand on recognized fields, explicit provenance, and readable intent.

Stewardship Responsibilities

Default Placement

Every repo owns its own local packet root:

foundations/<topic>/

Default rule:

Packet Shape

Recommended minimum structure:

foundations/<topic>/
  README.md
  source-ledger.yaml
  context-layer.md
  intent-understanding.md
  synthesis.md

For fielded packets, add one file or folder per field:

foundations/<topic>/
  README.md
  source-ledger.yaml
  context-layer.md
  intent-understanding.md
  synthesis.md
  <field-slug>.md

Explicit Layer Separation

1) Context-Layer

The context-layer captures the shared framing and durable metadata around the packet.

Include:

Questions this layer answers:

2) Intent-Understanding

The intent-understanding layer captures why the packet exists and what structural tension it resolves.

Include:

Questions this layer answers:

Research Diamond

         [Broad: decompose question]
              /        \
    [Narrow: 3-6 parallel field agents]    ← Wave 1
              \        /
         [Evaluate: gaps, cautions]
              /        \
    [Deep: 1-2 targeted agents]            ← Wave 2 if needed
              \        /
         [Synthesize: foundations packet]

Start broad, go narrow in parallel, identify gaps, go deep on gaps, synthesize.

Workflow

Phase 0 — Establish Date Context

Record today’s date and include it in prompts, packet metadata, and the source ledger.

Phase 1 — Gather Local Context

Before external research:

Phase 2 — MECE Field Decomposition

Break the topic into mutually exclusive, collectively exhaustive fields.

Common field families:

Scale effort to complexity:

Phase 3 — Parallel Research

Each research lane should include:

  1. Date context
  2. Why the packet matters
  3. Specific field angle and boundaries
  4. Source strategy
  5. Source quality bar
  6. Expected output shape

Prompt skeleton:

You are researching [FIELD / ANGLE] for a repository-local foundations packet.
TODAY'S DATE: [date]
PURPOSE: [why this packet matters]
AUDIENCE: [who will use it]
ANGLE: [field scope]
BOUNDARIES: [what this lane does not cover]
SOURCE QUALITY: Prefer academic papers, standards, official docs, primary sources, and strong practitioner engineering writing.
OUTPUT: canonical concepts, key findings, cautions, engineering implications, provenance notes, and sources with URLs/DOIs.

Phase 3.5 — Source Compatibility Assessment

Before synthesizing, assess each source for paradigmatic compatibility:

  1. Check the Incompatible Sources Registry (counter_articles/incompatible-sources/README.md)
    • If a source is registered, flag it with its incompatibility type
    • Note the bias injection points for that source
    • Cite the source only with explicit paradigmatic contextualization
  2. Scan unregistered sources for compatibility signals
    • Does the source use problem-solving orientation language? (“solve”, “fix”, “eliminate deficiency”, “bridge gap”)
    • Does it assume extractive epistemology? (knowledge as neutral resource, transferable without transformation)
    • Does it embed autonomous agent ontology? (intelligence in discrete individuals, not relational webs)
    • Does it assume unmarked Western universalism? (framework presented as paradigm-neutral default)

  3. Record compatibility in source-ledger.yaml Add a paradigm_compatibility field to each source entry:

    sources:
  - id: <short-id>
    field: <field>
    title: <title>
    url: <url>
    paradigm_compatibility: <compatible|incompatible|mixed>
    incompatibility_notes: "<if incompatible or mixed, what specifically>"
    registered_incompatible: <true|false>

  4. Propose new registry entries If an unregistered source shows clear incompatibility, note it for potential registration in the Incompatible Sources Registry.

  5. Run the full checklist when signals are ambiguous Use llms-pollution-detection-checklist.md for structured scoring when quick detection signals are inconclusive.

Phase 3.6 — Compatibility Handoff Protocol

Based on the compatibility assessment from Phase 3.5, follow the appropriate path:

Rating Action
compatible Proceed to synthesis (Phase 5) normally. No special handling required.
mixed Cite with explicit paradigmatic contextualization. Extract specific compatible claims with scoped citations. Name the incompatible layer explicitly. See Mixed Compatibility Protocol.
incompatible Trigger the epistemological-counter-positioning workflow. Choose counter-article type using the mapping below. Register the source in the Incompatible Sources Registry before synthesizing.
Unregistered source scoring ≥ 9 on checklist Propose registry entry before synthesizing. Document the detection signals in the source ledger.

Incompatibility Type → Counter-Article Type Mapping:

Incompatibility Type Recommended Article Type Reasoning
Problem-solving orientation Type 4: Methodological Schism Core assumption incompatibility — the schism is at the methodological foundation
Extractive epistemology Type 2: Critical Review or Type 3: Genealogical Critique Systemic institutional origin requires either direct paradigm mapping or historical power analysis
Autonomous agent ontology Type 2: Critical Review Requires full paradigm mapping (ontology → epistemology → methodology → consequences)
Linear progress methodology Type 3: Genealogical Critique Historical/power analysis of how linearity became naturalized
Unmarked Western universalism Type 5: Epistemic Injustice or Type 6: Positioned Response Silencing mechanism requiring either injustice analysis or standpoint foregrounding

Phase 4 — Gap Analysis

After all lanes return:

Phase 5 — Synthesis

The final packet should synthesize, not concatenate.

Recommended outputs:

source-ledger.yaml should include at minimum:

meta:
  packet: <topic-slug>
  generated: <date>
  method: deep-research-foundations
  verification_status: live-web-verified | training-knowledge-only | mixed
sources:
  - id: <short-id>
    field: <field>
    title: <title>
    url: <url>
    doi: <doi-if-any>
    supports: <claim-or-decision>
    verified: true|false

Phase 6 — Placement, Crosswalk, and Verification

Before calling the packet done:

Quality Gate

Do not call the packet complete unless:

Common Pitfalls

This site is open source. Improve this page.