Imported from L-666-888/Field-Progression-Research-Skill (SKILL.md). Install upstream with npx skills add L-666-888/Field-Progression-Research-Skill. Copyright stays with the author.

Field progression

Turn a research field into a document set a newcomer can actually read, where every number is checked and every unchecked claim is labeled.

The output is not a summary of papers. It is an argument about how a field moved, supported by verified evidence, with the weak points named.

When this applies

Use it when someone wants the history or development of a research area: "how did X evolve", "trace the progression of Y", "literature review of Z organized by era", "what led to the current state of W".

Do not use it for a single paper (just read the paper), for a snapshot of current best practice (no history needed), or for a news-style roundup of recent releases.

Before starting, settle four things

Ask only if the answer would change the work. Otherwise pick sensible defaults and say what you picked.

1. The field and its boundary. "Prompt optimization" and "everything about LLMs" are very different jobs. Get the edge of the topic.
2. Time range. Where does the story start, and does it run to today?
3. Audience. Default to a beginner who is technical but new to this field. That default drives the glossaries and the plain-language explanations.
4. Depth. Default is 3 to 5 anchor papers per era with the full treatment, plus up to 6 short entries. See the scope table below.

Working with whatever setup you have

This skill assumes nothing beyond web access and a file system. Adapt as follows and say in your handover which path you took.

Subagents available. Dispatch researchers in parallel, all in one message. Use one agent per two or three papers, not one per era, and cap each at roughly 25 to 30 tool calls. This is both the biggest speedup and the biggest cost saving, for the reason measured under Cost and scale.

No subagents. Work era by era yourself, using the same brief as a checklist. Same output, longer wall clock. Warn the user up front that it will take a while.

Other skills installed. If the environment has a research skill, an editing skill, or a citation checker, use it in addition to what is here, never instead of it. The rules in references/verification.md and references/writing-style.md are the floor, and another skill's conventions do not override them. In particular, if a humanizing or copy-editing skill is available, run the finished prose through it after check_style.py passes, since that catches judgment-level problems (rhythm, uniform paragraph length, manufactured emphasis) that no regular expression can see.

No other skills installed. Nothing is missing. The verification protocol and the writing rules are bundled here precisely so this case works.

Python unavailable. The scripts are a convenience, not a dependency. Do their job by hand: fetch each figure and confirm it is a real image rather than a placeholder, and grep for the patterns listed in references/writing-style.md. Tell the user you verified manually.

Restricted web access. Stop and say so. Do not write a history from memory. This skill's entire value is that its claims were checked, and an unverified version of it is worse than nothing because it looks identical.

Cost and scale

This skill can burn a very large amount of budget if you let it. The cost model is not the obvious one, so read the measured section below before dispatching anything.

Set the scope before starting, and say it out loud.

Where the tokens actually go, measured

Two real runs of this skill were instrumented. The result is counter-intuitive and it should change how you dispatch work.

Researcher agents are 75 to 82% of total cost. The main session is a minority of the bill. Optimizing the main session barely matters.

Inside one agent, cost grows with the square of its tool calls. Every call re-reads the agent's whole accumulated context. Measured on a real run: an agent starts at about 32,000 tokens of fixed context and grows by about 1,400 tokens per tool call. So an agent's total read is roughly calls x (32,000 + 700 x calls).

One measured agent made 81 tool calls and read 6.6 million tokens by itself. Its context grew from 31,532 to 125,884 tokens, a 4x expansion, and every intermediate call paid for the growth up to that point.

The consequence: many short agents are dramatically cheaper than few long ones, for identical work. Splitting the same total calls across more agents divides the quadratic term while leaving everything else unchanged. Projected against the measured run:

What does not drive cost, contrary to the obvious guess:

• Fetch count per paper. The measured run averaged about 9 fetches per paper, comfortably inside the 6 to 10 budget. Fetch count was fine. The problem was how many calls sat inside one growing context.
• Output length. Output tokens were under 1% of gross usage in both runs.
• The verification scripts. They run in the main session, cost almost nothing, and in the measured run were never invoked at all.

Dispatch rules that follow from this

• Cap each researcher at roughly 25 to 30 tool calls. Say so explicitly in the brief. When an era needs more, split it by paper rather than letting one agent run long.
• Prefer one agent per two or three papers over one agent per era. For six eras with five anchors each, that is roughly 12 to 15 short agents, not 6 long ones.
• Do not let researchers spawn their own subagents. A measured run launched 6 agents and produced 33 agent transcripts because agents recursively spawned more. Nesting multiplies the quadratic term. State in the brief that researchers must not delegate.
• Give each agent a self-contained brief. An agent that has to go discover its own scope spends its early calls on orientation, which then sits in its context for every later call.

Choose anchors on evidence, not on what you found first

An anchor paper is not "an important-looking paper I found early". Select on signals that reflect the field's own judgment:

• Later papers cite it as the origin of the idea. This is the strongest signal available and it is the field telling you what mattered.
• Surveys name it as a turning point. A good survey already did the selection work. Verify its choices rather than redoing them from scratch.
• Its method became a common noun that people use without citing.
• It introduced the benchmark that later work optimizes against.
• It reversed a consensus, or reported the result that made a line of work stop.
• Citation count relative to age, used as a weak tiebreak and never as the primary signal, since it favours old and fashionable work.

Cheap ways to gather those signals: read two or three surveys of the field first, read the related-work section of the most recent important paper you can find, and note which older papers the papers you already selected keep citing.

The completeness check that catches a wrong anchor

After drafting an era, before moving on, run one cheap check:

Look at what your own selected papers cite as their antecedents. If a paper is cited as foundational by three or more of your anchors and is not in your era, you have probably missed something. You already have the papers, so this costs almost nothing and it catches most selection errors.

Then ask two questions in writing:

• What would a specialist in this era say is missing? If you cannot answer, you have not read enough of the field's own summaries.
• Does the era's thesis survive if I drop each anchor in turn? A paper whose removal changes nothing is a short entry, not an anchor. A missing paper often shows up here as a gap in the causal chain, where era N does not actually explain era N+1.

Record what you deliberately left out and why, in the era's gaps section. A named omission is a limitation. An unnoticed one is an error.

The rest of the savings, none of which touch coverage

• Ask researchers for fields, not essays. A researcher returning polished narrative has spent tokens on text you will rewrite. Compact field-value output is cheaper and more useful.
• Do figure discovery in one batch per era with scripts/find_figures.py, rather than fetching pages repeatedly while writing.
• Tier the papers. Demoting papers from full treatment to short entries is the largest saving available and it improves the document. Note this is a writing decision made after discovery, not a decision to skip reading.
• Do not re-verify what was already verified. Re-check only load-bearing numbers, meaning anything going into the overview.
• Use a smaller model for extraction if your runner supports it, and keep the strong model for selection, synthesis, and the limitations sections. Extraction is easy. Judgment is not.

When the field is very large

Some fields cannot be covered thoroughly at any sane budget. Be honest about this rather than producing a thin document that looks complete.

Narrow the scope instead of thinning the coverage. A verified history of one technique is worth more than a superficial history of a discipline, and the superficial version is actively misleading because its gaps are invisible. Say plainly that the field is too large and propose a narrower cut, or several documents.

Ship a map first, then drill in. Produce the overview with the through-line table, the era theses, and short entries only. That is cheap and it is genuinely useful on its own. Then let the reader pick which eras get full treatment. Most people want depth in two eras and orientation in the rest, and this way you never spend the budget before finding out which two.

Vary depth across eras deliberately. Background eras get short entries. The eras carrying the argument, and the eras nearest the reader's actual interest, get anchors. Uniform depth across a large field is how budget gets spent on material nobody needed.

Lean on the field's own surveys for discovery. In a large field, surveys exist. Verifying a survey's selections is far cheaper than rediscovering them, and disagreeing with a survey is itself a finding worth writing down.

Split by subfield, not by time. A large field usually contains several parallel lines of work that only interact occasionally. Three focused documents beat one that switches subject every few paragraphs.

Scale to the request. "Give me a quick overview of how X developed" is three eras, anchors only, no corrections file. "Do a thorough history of X" is the full treatment. Ask if it is unclear, and say which you are doing.

Phase 1: find the shape

This is the wide, cheap pass, and it is the one place you should not economize. Read broadly and shallowly: survey papers, the related-work sections of recent important papers, and which older papers keep getting cited as origins. You are reading abstracts and reference lists, not full texts, so breadth here is affordable.

Produce a candidate list that is deliberately longer than what you will cover, then cut it using the anchor criteria above. Selecting from a wide pool and discarding is correct. Stopping as soon as you find something important is not, because the paper you never saw cannot be compared against the one you took.

Then divide the field into eras.

An era is not a date range. It is a period with a single thesis, and the thesis is the era's title. Good eras look like "the year reasoning was unlocked by prompting" or "when the prompt became a program". Bad eras look like "2022 to 2023".

Aim for 4 to 6 eras. For each, write one sentence stating what changed. If you cannot, the era is not real and should be merged with a neighbor.

Then find the through-line: the one axis along which the whole field moved. In the worked example, it was that the object being optimized kept getting larger while the optimizer kept getting less human. The through-line becomes a table at the top of the overview and is the reason the document is worth reading rather than a list.

Phase 2: research each era, with verification

Read references/verification.md before this phase. It is the part of this skill that matters most.

If you can run subagents in parallel (Claude Code Task or Agent tool, or any multi-agent runner), dispatch one per era using the brief in references/research-brief.md, all in one message so they run concurrently. That is what makes this affordable.

If you cannot, work through eras one at a time using the same brief as your own checklist. The output is the same; it just takes longer. Nothing in this skill requires subagents.

Non-negotiable rules while researching:

• Verify every paper identifier against the title. A plausible-looking arXiv ID attached to the wrong paper is the most common fabrication in this genre.
• Take numbers from the paper's own tables. Secondary sources on famous results are unreliable at a rate that will surprise you.
• Carry the model name and the baseline with every number. Most misquotes in circulation are a number that got separated from one or the other.
• Verify code repositories resolve before linking them.
• If you cannot confirm something, write UNVERIFIED and move on. Never soften an unconfirmed claim into a confident one. A gap you disclose costs the reader nothing; a fabricated citation costs them their trust in everything else.
• Keep a running note of results you find misquoted in secondary sources. These become the corrections file, which is often the most valuable single artifact you produce.

For figures, run scripts/find_figures.py <paper-id> rather than guessing URLs. Guessing does not work, and the failure is silent. See references/verification.md for why.

Phase 3: write

Read references/document-structure.md and references/writing-style.md first.

Structure is hub and spoke:

README.md          overview, through-line table, era summaries, links out
01-<era>.md        one file per era
02-<era>.md
...
corrections.md     results that circulate in a wrong form

Every paper inside an era file gets the same six sections, with these exact headings, in this order:

### Citation                     authors, venue, links, code, version warnings
### The question                 one sentence, plainly asked
### Result                       the paper's proposed answer, then the evidence
### Mechanism
    #### Data                    what the dataset actually contains
    #### Setup                   models, sizes, sample counts, key settings
    #### Method                  numbered steps
    #### Metric                  what it measures and why it matters
### Impact and innovation        what changed, what descends from it
### Limitations and what could be improved

Citation and question are separate sections, so a reader scanning for sources does not have to read prose to find them. The four Mechanism parts each get their own heading. Merging them into one paragraph is the most common drift and it makes the section useless for reference.

Two rules that decay fastest over a long session, so check yourself against them:

• Bullets and tables are the default, prose is the exception. Findings go in bullets. Any comparison of more than three numbers goes in a table. Around 20 bullets per 1,000 words reads well; at 4 per 1,000 the document has drifted into prose and needs restructuring. A Result section with no bullets and no table is a failure.
• Define every specialized term at first use, inline, in a clause. Never make the reader leave the page.

The limitations section is where most of the value is and it is the part a summarizer would skip. It is not a restatement of the paper's own limitations. Read the results and ask what the paper avoids testing, what its baseline choice flatters, what its headline framing obscures, and what a skeptical reviewer would attack. Where later published work confirmed a weakness, cite it. Where it is your judgment, write it as judgment.

Each era file opens with a short glossary of the terms used on that page.

Not every paper gets all six sections. Three to five anchor papers per era get the full treatment. The rest become short entries of three to six lines at the end of the file. See references/document-structure.md.

Phase 4: verify the artifact

Run these. A measured run skipped all three and shipped anyway. In your handover, state each script's exit code. If you cannot show the exit codes, you did not run them.

All three checks are required before delivering. None is optional, and none is a substitute for reading the document yourself.

python scripts/verify_assets.py path/to/docs/
python scripts/check_structure.py path/to/docs/
python scripts/check_style.py path/to/docs/

check_structure.py is the one that catches template drift. It verifies the six sections are present and in order, that Mechanism carries its four labelled parts, that every Result section has bullets or a table, and that bullet density and file length have not slid into prose. Run it early and often, not only at the end, because drift compounds and is far cheaper to fix in one file than in seven.

verify_assets.py downloads every image and inspects the bytes, because status codes lie. It also checks local images exist and internal links resolve. Fix everything it reports. If a figure cannot be made to work, delete it and its caption, or describe the figure in prose where the content genuinely matters.

check_style.py enforces the mechanical half of references/writing-style.md: em dashes, curly quotes, emoji, the AI vocabulary, title-case headings, and runs of bolded label bullets. Hard failures must be fixed. Warnings are judgment calls, so read each one and keep it only if you meant it.

A clean run on both means no obvious defects. It does not mean the document is good. Confirm by hand:

• Every number carries its model and its baseline.
• Every specialized term is defined at first use.
• Gaps and unverified items are stated at the end of each era file.
• Sentence lengths vary, and no section opens by restating its heading.

Phase 5: hand over

Tell the user what you built, where it is, and what you could not verify. Lead with anything that changes how they should use it: a misquote you found, a contradiction between two sources, a claim you had to leave unconfirmed.

The four rules that carry the most weight

1. A citation you cannot confirm gets dropped, not hedged. Gray zone means fail.
2. A number without its model and baseline is not a number. It is a rumor.
3. Status codes lie about images. Check bytes.
4. Write the limitations honestly, including when they undercut a paper you admire. That section is why the document is worth more than the abstracts it draws on.

Reference files

Scripts

Both are stdlib-only Python 3, no installation needed.