# Math History Researcher

> Rigorous, source-traceable research workflow for History of Mathematics questions. Use this whenever the user asks for mathematician biography, chronology, attribution, historical significance, origin of concepts, conflicting historical claims, or paper-ready claim verification with citations/BibTeX candidates. Prefer this skill even for short factual answers. Run a serial 4-agent workflow (search -> verify -> write -> citation QA), with recursive and parallel sub-agent search in the retrieval stage.

- Skill: `sofarsogoodya/math-history-researcher` (Agent Skill, multi-file: 4 files)
- Install (CLI): `npx skillmds@latest add sofarsogoodya/math-history-researcher`
- Raw SKILL.md: https://api.skillmd.com/api/skills/sofarsogoodya/math-history-researcher/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: SoFarSoGoodya (https://skillmd.com/u/sofarsogoodya)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/sofarsogoodya/math-history-researcher

---


# Math History Researcher

## Purpose

Produce an English, citation-safe **Research Pack** for History of Mathematics tasks with claim-level traceability.

This skill is designed for workflows where factual errors are costly (course papers, claim ledgers, bibliography building, section drafting in LaTeX manuscripts).

## Execution Topology (Serial 4-Agent Pipeline)

Use **serial stages** end-to-end, and allow **parallelism only inside search**.

1. **Agent A1 — Search Orchestrator**
  - Decompose the task into claim units.
  - Launch tri-vector retrieval in parallel.
  - Use recursive branching when evidence is weak.
2. **Agent A2 — Evidence Verifier**
  - Rank source quality.
  - Resolve/flag conflicts with explicit rubric.
  - Reject weak or uncitable claims.
3. **Agent A3 — Research-Pack Writer**
  - Produce the human-readable English Research Pack.
  - Keep claims conservative and traceable.
4. **Agent A4 — Citation Binder & QA**
  - Bind claims to source IDs.
  - Validate citation completeness and BibTeX readiness.
  - Emit TODO markers for unresolved metadata.

**Stage gate rule:** A2 cannot start before A1 completes; A3 cannot start before A2; A4 is the final gate before output.

### A1 Parallel Dispatch Blueprint (Explicit Multi-Agent Search)

Within A1, use parallel fan-out with deterministic merge points:

1. **Claim fan-out (parallel):** split user request into claim units (`C1...Cn`).
2. **Tri-vector fan-out per claim (parallel):** run Vector A/B/C for each claim concurrently.
3. **Depth-2 recursive fan-out (conditional, parallel):** only for weak/conflicting claims, spawn focused sub-queries (edition year, translation lineage, archival anchor, DOI mapping).
4. **A1 merge barrier:** normalize all evidence into one claim-evidence map before handing off to A2.

Keep A2/A3/A4 strictly serial after A1 merge.

## Non-Negotiable Rules

1. **Search first** for factual historical claims. Do not rely on memory alone for dates, attributions, chronology, first-use claims, publication timelines, and historiographic disputes.
2. **Never fabricate** citations, quotes, metadata, or page numbers.
3. **Keep output in English**.
4. Every key factual claim must have at least **1 high-quality source**; if missing, mark as `TODO: missing high-quality source`.
5. Trigger a dispute section only when there are at least **2 materially conflicting sources**.
6. For **priority / first-use** claims, require at least **2 independent sources**.
7. For web sources, always include `url` and `urldate` (repository bibliography norm).
8. If an external web image is necessary and **cannot be reliably generated by AI drawing**, add an explicit marker: `TODO: add external web image` (include intended placement, why the image is needed, and source-attribution requirements).
9. Prose polishing is for clarity and academic quality only; do **not** use this workflow to conceal authorship provenance or misrepresent intellectual contribution.
10. Never let drafting/process artifacts, or anything that may imply the use of AI appear in final manuscript output (e.g., prompt scaffolds, placeholder markers, model disclaimers, markdown/render artifacts).
11. For mathematically substantive content (theorem/method/proof/derivation/conclusion about specific mathematical work), include meaningful formal artifacts (equations, derivation blocks, geometric or analytical figures, or compact technical tables) with **sufficient density for real technical rigor**, but never force a numeric quota that harms explanation quality.
12. Every formal artifact must be explained: define symbols/variables, state what the formula or figure demonstrates, and connect it to the historical claim.
13. Prefer historically faithful notation and proof style when presenting historical mathematics. If a modernized notation or streamlined proof is used, explicitly disclose this in the prose (e.g., "for simplicity" or "simplified treatment") and state that it differs from the historical notation/proof style.

## Trigger Conditions

Use this skill when requests involve any of the following:

- Mathematician life timeline (birth/death, schools, institutions, major periods)
- Priority/attribution claims ("who first", "earliest known", "invented by")
- Historical development of a theorem, method, notation, or concept
- Comparison of competing historical narratives
- Source-backed writing for paper sections, especially when citations are needed
- Claim ledger support and BibTeX candidate generation

Do not use this skill for pure creative writing or opinion-only brainstorming with no factual verification requirement.

## Search and Verification Workflow

### Step 1 — Decompose into Claims

Break the user request into discrete, testable claims.

Examples:
- "X was born in year Y"
- "Notation Z first appeared in work W"
- "Method A influenced B through C"

### Step 2 — Run Tri-Vector Retrieval (Parallel by Default)

Run three retrieval vectors in parallel whenever possible:

- **Vector A: Primary / Authoritative**
  - Primary texts, critical editions, authoritative historical repositories, high-authority encyclopedic references.
- **Vector B: Scholarly Secondary**
  - Peer-reviewed articles, scholarly monographs, chapter-level historical analysis.
- **Vector C: Institutional Context**
  - University, academy, museum, or similarly authoritative institutional summaries.

For subsection-scale writing (one mathematician section), parallelize at least:
- Track 1: biography and timeline evidence
- Track 2: one major work/contribution evidence

Then merge before synthesis.

### Step 2.1 — Recursive Parallel Search Policy (A1)

Inside A1, use recursive sub-agents when needed:

- **Depth 0:** top-level claims extracted from the user request.
- **Depth 1:** for each claim, run Vector A/B/C in parallel.
- **Depth 2 (conditional):** if evidence is weak/contradictory, spawn focused sub-queries (edition year, translation metadata, attribution lineage, etc.).

Stop recursion when either:
- evidence reaches Definition-of-Done thresholds, or
- no higher-quality source can be found after one refinement round.

### Step 2.2 — Parallel Search Lanes for Section Writing

For one `\subsubsection` target, run at least these lanes in parallel inside A1:

- **Lane L1 (Biography/Chronology):** dates, institutions, timeline claims.
- **Lane L2 (Technical Contribution):** theorem/method/notation claims.
- **Lane L3 (Attribution/Dispute):** priority claims, historiographic conflicts.

Merge L1/L2/L3 before A2 verification.

### Step 3 — Source Quality Ranking

Rank source quality before synthesis:

1. Primary/critical editions and direct historical scholarship
2. Peer-reviewed scholarly secondary sources
3. Institutional references (universities/academies/museums)
4. General web references

Prefer higher-ranked evidence when conflicts occur.

### Step 4 — Conflict Handling

If at least 2 sources materially conflict on a key claim:

- open `Disagreements & Variants`
- state each variant explicitly
- identify which variant is better supported and why
- avoid collapsing unresolved disputes into one "fact"

### Step 4.1 — Conflict Arbitration Rubric (A2)

When resolving conflicts, compare each candidate claim with these checks:

1. Is it directly grounded in a **primary source / critical edition**?
2. Is it supported by **peer-reviewed** scholarship?
3. Does it provide **verifiable bibliographic anchors** (edition/page/DOI/archival reference)?
4. Is it accepted by **authoritative institutional or scholarly consensus**?

Prefer the variant that wins more high-priority checks; if still unresolved, mark `Disputed`.

### Step 5 — Metadata and Citation Readiness

For each cited source, capture what is available:

- author/editor/translator
- title
- publication year / edition year
- source type (`primary`, `peer-reviewed`, `institutional`, `web`)
- DOI or URL
- access date for web sources
- candidate BibTeX key

If metadata is incomplete, mark explicit TODO fields.

## Output Contract (Research Pack v1)

Always output with this structure:

### 1) Direct Answer

A concise answer to the user’s main question.

### 2) Core Claims and Evidence

Claim-by-claim bullets:
- **Claim**
- **Evidence summary**
- **Best source(s)**
- **Citation marker(s)**

### 3) Disagreements & Variants (Conditional)

Include only when conflict threshold is met (>=2 conflicting sources).

### 4) Citation-Ready Source Table

A compact table with:
- source id
- author/title/year
- source type
- DOI/URL + access date (if web)
- candidate BibTeX key
- metadata completeness (`complete` / `partial`)

### 5) Claim Ledger Suggestions

Provide rows that can be copied into claim-ledger workflows:
- claim text
- supporting source ids
- confidence
- TODOs (if any)

### 6) Visual Asset TODO (Conditional)

If the section would materially benefit from a non-AI-drawable external web image, include:

- `TODO: add external web image`
- intended LaTeX placement (e.g., section/subsection or figure slot)
- purpose of the image (what claim/context it supports)
- required attribution metadata (`author/source URL/license/access date`)

### 7) Confidence Assessment (Mandatory)

End with:

- **Source Quality:** High / Medium / Low
- **Historical Consensus:** High / Medium / Disputed
- **Evidence Coverage:** Full / Partial
- **Open Gaps:** any unresolved metadata or source gaps

### 8) JSON Mirror (Optional but Recommended)

When downstream automation is expected, add a machine-readable block containing:

- `claims[]` with `claim_id`, `text`, `source_ids`, `confidence`, `todos`
- `sources[]` with normalized metadata and `candidate_bibtex_key`
- `disagreements[]` (if any)

This JSON mirror should be semantically aligned with the human-readable Research Pack.

### 9) Mathematical Formalism Coverage (Required for Technical Subsections)

When the target subsection discusses concrete mathematical work (not just context/history), include:

- equations/derivations and/or diagrams/tables with professional relevance,
- enough formal artifacts to preserve technical depth without compressing explanation,
- explanatory text after each formula/diagram (what it means, notation, historical significance).

For balance and readability, prefer an adequacy check over rigid percentages: technical readers should be able to reconstruct the mathematical idea, and general readers should still follow the argument.

Exemptions (allowed prose-dominant sections):

- broad historical background,
- historiography-only comparison,
- impact/significance conclusion with no technical claim.

If exempted, explicitly mark: `Formalism exemption: historical/context-only subsection`.

When a subsection uses modernized notation/proof for accessibility, add an explicit disclosure sentence such as: `For simplicity, we use modern notation; this is a simplified treatment and differs from the historical notation/proof style.`

## Citation Binding Contract (A4)

Use strict claim-source binding:

- assign each key claim a stable `C#` id (e.g., `C1`, `C2`)
- assign each source a stable `S#` id (e.g., `S1`, `S2`)
- each claim must cite at least one `S#`
- each `S#` row must include source type and metadata completeness

BibTeX-readiness rules (repository-aligned):

- candidate key format: `AuthorYYYYShortTitle`
- web entries must include `url` + `urldate`
- if metadata is incomplete, keep explicit TODO fields instead of guessing

## Definition of Done (DoD)

A response is complete only if all checks pass:

1. Every key claim has >=1 high-quality source.
2. Every priority/first-use claim has >=2 independent sources.
3. Source Table metadata completeness is >=80%.
4. If conflicts exist, `Disagreements & Variants` is present.
5. Claim-to-source binding coverage is 100% (no orphan key claims).
6. If an external web image is judged necessary and not AI-drawable, a `TODO: add external web image` marker is present with placement + attribution requirements.
7. Anti-trace scan gate passes for the current target (`high=0`; `medium` reviewed).
8. For technical subsections, formal artifacts are substantively sufficient for rigor (no token math), and each formula/diagram has local explanatory text.
9. Historical notation/proof fidelity is respected, or modernized treatment is explicitly disclosed with wording such as "for simplicity" / "simplified treatment" plus a note of divergence from historical practice.

## Writing Style

- Keep language precise, neutral, and academically conservative.
- Distinguish clearly between facts, interpretations, and unresolved disputes.
- Avoid overclaiming certainty when evidence is thin.
- For equations/figures, use explain-then-interpret style: notation first, mathematical meaning second, historical relevance third.

## Failure / Exception Behavior

Use graded failure levels:

- **Level A (full success):** retrieval succeeded and high-quality evidence is sufficient -> standard output.
- **Level B (partial evidence):** retrieval succeeded but key metadata/evidence is incomplete -> output with explicit `Partial` flags + TODO.
- **Level C (retrieval failure):** external retrieval unavailable -> provisional answer with strict uncertainty labeling + mandatory verification TODO.

If external retrieval fails completely (Level C):

- explicitly state that search was unavailable
- provide a provisional answer with clear uncertainty labeling
- include `TODO` markers for mandatory verification before manuscript use

## Writing Timing Decision for `writing-clearly-and-concisely`

For this repository, use a **hybrid policy with post-draft as default**:

1. **Default (recommended): post-draft pass**
  - Apply `writing-clearly-and-concisely` after A3+A4 complete and claim/citation integrity is stable.
  - Rationale: institutional writing-process guidance consistently separates drafting from revising/editing; the skill itself recommends "write draft first, then copyedit." This avoids polishing text that may later be structurally rewritten.
2. **Optional pre-writing micro-use (lightweight)**
  - Before drafting, load only a concise style checklist (active voice, concrete language, omit needless words).
  - Do not run full polishing before claim verification.

Operational rule:

- **First optimize correctness and traceability (A1→A4), then optimize prose naturalness.**

## Tooling & Skill Invocation Guide (How to Reuse Existing Capabilities)

When available in this workspace, use capabilities in this order:

1. **A1 discovery (default): Copilot web search**
  - Use `@websearch` / `#websearch` for current-info discovery and candidate URL collection.
  - This path is preferred for this repository's history-of-mathematics research tasks.
2. **A1 source fetch (default): recursive URL collection**
  - Use the `fetch` MCP (`mcp-server-fetch`) to read selected URLs and recursively fetch relevant linked pages.
  - Prefer this for citation-safe extraction from static pages, docs, and article-style sources.
3. **Scholarly indexing and metadata expansion**
  - Use `openalex-database` skill to find related works/DOIs and citation graph context.
4. **Citation normalization**
  - Use `citation-management` skill to convert verified metadata into BibTeX-ready entries.
5. **Interactive browser fallback (conditional)**
  - Use `web-access` only when needed: dynamic rendering, login-required pages, or interactive workflows.
  - Do not use browser automation by default when lighter retrieval layers already satisfy evidence needs.
6. **Writing/paper integration (optional)**
  - Use `latex-paper-en` for section drafting polish.
  - Use `paper-audit` for reviewer-style sanity checks.
7. **Clarity and concision pass (recommended after A4)**
  - Use `writing-clearly-and-concisely` to reduce robotic phrasing and improve sentence rhythm while preserving factual claims and citations.

Conflict-avoidance rule for this repository:

- Use a single primary retrieval path per claim by default: `websearch -> fetch -> openalex`.
- Escalate to `web-access` only when the default path cannot obtain required evidence.
- Do not run multiple retrieval stacks redundantly for the same claim unless conflict verification requires a second pass.

Suggested stage-to-tool map:

- **A1:** `@websearch/#websearch` + `fetch` MCP + `openalex-database` (fallback: `web-access`)
- **A2:** source-quality rubric + conflict arbitration
- **A3:** research-pack drafting (`latex-paper-en` )
- **A4:** `citation-management` + binding QA
- **Postflight:** anti-trace scanner + optional `paper-audit`

If one capability is unavailable, continue with remaining ones and mark the gap explicitly.

## Anti-Trace Postflight Gate (Required)

Use this gate to prevent visible drafting/tool artifacts from leaking into final PDF output.

### Script and checklist

- Script: `scripts/scan_ai_trace_artifacts.py`
- Checklist: `references/ANTI_TRACE_SCAN_CHECKLIST.md`

### One-click full-manuscript command

Run from manuscript root (`main.tex` directory):

- `python "$SKILL_DIR/scripts/scan_ai_trace_artifacts.py" --pdf main.pdf --source-root . --fail-on medium --json-output research/anti_trace_report.json`

### Recommended cadence (answer to "last step vs final 50 pages")

Use a two-tier strategy:

1. **During writing (fast gate):** source-only quick scan after each completed subsection.
2. **At integration milestones:** full scan after each chapter merge.
3. **Near-final manuscript (~50 pages):** mandatory full-manuscript gate before submission/export.

This catches leaks early while still enforcing a strict final integrated audit on the full PDF.

## Integration Notes for This Repository

- Main paper body is English: keep Research Pack output directly reusable in English drafting.
- Respect citation integrity: no fabricated references or quotations.
- Prioritize claim traceability so outputs can flow into bibliography and claim-ledger steps.
- For external web images, do not fabricate figures: emit TODO + attribution requirements so the user can add licensed assets manually.
- If the user asks for "human-like" prose, interpret this as readability/disciplinary tone improvement, not authorship concealment.