agentleFS
vllm-projectvllm-project/speculators/AGENTS.md

speculators

AGENTS.md945 starsChanged 7 days agoApache-2.0View on GitHub

Read CONTRIBUTING.md before contributing. Install the git hooks once per clone, after installing the [dev] extras: Fill in the PR template's Purpose and Tests sections (see PULL_REQUEST_TEMPLATE.md). A reviewer should get the point in under 30 seconds: Training, eval, and vLLM-launch scripts write reproducibility artifacts so runs can be recreated later. Always pass --provenance-dir when running scripts/launch_vllm.py — point it at the associated run's output/checkpoint directory (e.g. --provenance-dir <output_dir>) so the vLLM provenance is co-located with the training/eval it belongs…

  • Where files are headingNew AGENTS.md files have more rules about keeping secrets out of the code, and fewer about code style.

    Of the AGENTS.md files we read, the 31,774 first seen in the last six months, against the older ones: the kind of rule that gained most share, and the kind that lost most. About files like this in general, not this one, and an estimate, since a kind is a pattern in the words.

  • In this repository2 other files it gives its agents.

The file

We split this AGENTS.md into the rules it gives an agent

7 rules. About 0 are common, 5 are distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈5

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Read CONTRIBUTING.md before contributing.

    line 5
  2. Distinctive:

    Keep the description proportional to the diff.

    line 15
  3. Distinctive:

    Do not state unverified hypotheses as facts.

    line 16
  4. Distinctive:

    No emoji headings, no "comprehensive"/"robust"/"production-ready", no per-file summary tables.

    line 18
  5. Distinctive:

    Do not hard-wrap the description at a fixed column.

    line 19
  6. Distinctive:

    Leave the "I (a human) have written or reviewed the code" checkbox unchecked.

    line 20
  7. Very specific:

    When publishing a model or eval results (HuggingFace, GitHub comments, etc.), always include the provenance artifacts (train_command.txt, …

    line 34

≈ “Common” is an estimate: at least 1 in 5 of the 40,246 AGENTS.md files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
AGENTS.md

Speculators — Agent Guide

Pull requests

Read CONTRIBUTING.md before contributing. Install the git hooks once per clone, after installing the [dev] extras:

pre-commit install

Fill in the PR template's Purpose and Tests sections (see PULL_REQUEST_TEMPLATE.md). A reviewer should get the point in under 30 seconds:

  • Purpose: 1–3 sentences or a few bullets on why, plus the issue link if available. Not a restatement of the diff.
  • Tests: the command a reviewer can run, and whether it passed. Do not paste the output — CI prints it, and a wall of captured log pushes the point of the PR off the screen. Never claim a run you did not do, or numbers you did not measure.
  • Keep the description proportional to the diff. A few changed lines do not need a paragraph each; if the description is longer than what it describes, cut it.
  • Do not state unverified hypotheses as facts.
  • In a stacked PR, do not restate where it sits in the stack ("first of N", "stacked on #1234", "top of the stack") or list the other PRs. GitHub renders the stack already. Reference another PR only for something the stack view does not carry, such as which commit a measurement was taken against.
  • No emoji headings, no "comprehensive"/"robust"/"production-ready", no per-file summary tables.
  • Do not hard-wrap the description at a fixed column. GitHub reflows it, so manual line breaks only make the diff of a later edit noisy.
  • Leave the "I (a human) have written or reviewed the code" checkbox unchecked.

Provenance

Training, eval, and vLLM-launch scripts write reproducibility artifacts so runs can be recreated later.

  • Training (src/speculators/train/utils.py): save_train_command() writes train_command.txt (timestamp, git SHA, world size, package versions, full argv) and speculators.patch (uncommitted diff) into the checkpoint directory.
  • Eval (scripts/evaluate/evaluate.py): save_eval_provenance() writes eval_command.txt (timestamp, git SHA, package versions, full argv) into the output directory.
  • vLLM launch (scripts/launch_vllm.py): _save_vllm_provenance() writes vllm_command.txt, vllm.patch, and checkpoint_sha256.txt (plus drafter_checkpoint_sha256.txt in eval mode) — but only when --provenance-dir is passed. Two subcommands:
    • launch_vllm.py train MODEL (default): hidden-states extraction for training data generation.
    • launch_vllm.py eval MODEL --spec-model DRAFTER: speculative decoding serving for evaluation.

Always pass --provenance-dir when running scripts/launch_vllm.py — point it at the associated run's output/checkpoint directory (e.g. --provenance-dir <output_dir>) so the vLLM provenance is co-located with the training/eval it belongs to.

When publishing a model or eval results (HuggingFace, GitHub comments, etc.), always include the provenance artifacts (train_command.txt, eval_command.txt, vllm_command.txt, checkpoint_sha256.txt, drafter_checkpoint_sha256.txt, patches) so the run can be reproduced.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.