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.