agentleFS
lyh843lyh843/AgentSkills/skills/book-to-skill/AGENTS.md

AgentSkills / book-to-skill

AGENTS.md1 starsChanged 5 months agoMITView on GitHub

This file is the repository-wide execution contract for coding agents. book-to-skill converts books and documents into structured, on-demand Agent Skills. The repository has two distinct halves: Do not blur those responsibilities without a measured reason. Before changing code, read the smallest relevant set of files: For the progressive-disclosure research/evaluation initiative, also read: That document is the execution ledger and defines task order, evidence gates, and which paper-derived ideas are hypotheses rather than product requirements. For any non-trivial task, use this…

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

17 rules. About 0 are common, 17 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈17

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Do not blur those responsibilities without a measured reason.

    line 12
  2. Distinctive:

    Before changing code, read the smallest relevant set of files:

    line 16
  3. Distinctive:

    Measure, do not assert: No claimed quality, token, routing, accuracy, or cost improvement without reproducible evidence.

    line 32
  4. Distinctive:

    Never commit raw copyrighted book text: Use synthetic, public-domain, or explicitly licensed fixtures.

    line 35
  5. Distinctive:

    Do not weaken security checks, path hardening, sanitization, or generated-skill scanning to make an experiment pass.

    line 39
  6. Distinctive:

    Read this file and the relevant source-of-truth files.

    line 46
  7. Distinctive:

    Prefer reuse of existing utilities over parallel implementations.

    line 53
  8. Distinctive:

    Keep the diff focused.

    line 57
  9. Distinctive:

    Add deterministic tests with the implementation.

    line 58
  10. Distinctive:

    Do not opportunistically refactor unrelated code.

    line 59
  11. Distinctive:

    Run the task-specific checks.

    line 62
  12. Distinctive:

    Run the repository gates below.

    line 63
  13. Distinctive:

    Update the task status/evidence section in the research plan when that plan is in scope.

    line 67
  14. Distinctive:

    If extraction behavior changes, also run the relevant extractor smoke/reproduction command and its targeted tests.

    line 89
  15. Distinctive:

    If generated-skill behavior changes, provide a before/after generated artifact or benchmark result that demonstrates the intended …

    line 91
  16. Distinctive:

    Do not jump to 10/20-book sweeps before smaller-scale gates justify them.

    line 103
  17. Distinctive:

    If a cheaper test can falsify the hypothesis, run it first.

    line 104

≈ “Common” is an estimate: at least 1 in 5 of the 36,368 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

AGENTS.md

This file is the repository-wide execution contract for coding agents.

Project intent

book-to-skill converts books and documents into structured, on-demand Agent Skills. The repository has two distinct halves:

  1. a deterministic Python extractor (scripts/extract.py -> book_to_skill/), and
  2. a spec-driven generator (SKILL.md) executed by an agent.

Do not blur those responsibilities without a measured reason.

Sources of truth

Before changing code, read the smallest relevant set of files:

  1. CONTRIBUTING.md — contribution rules and required checks.
  2. docs/architecture.md — current architecture and component ownership.
  3. SKILL.md — only when generation behavior or generated-skill structure is in scope.
  4. SECURITY.md and SECURITY-NOTICE.md — when touching parsing, files, subprocesses, generated content, or dependencies.
  5. Existing tests closest to the code being changed.

For the progressive-disclosure research/evaluation initiative, also read:

  • docs/research/progressive-disclosure-evals.md

That document is the execution ledger and defines task order, evidence gates, and which paper-derived ideas are hypotheses rather than product requirements.

Non-negotiable rules

  • Measure, do not assert. No claimed quality, token, routing, accuracy, or cost improvement without reproducible evidence.
  • Do not turn a paper hypothesis into production behavior before its gate passes. In particular, do not add KEY_ELEMENTS-style metadata, library mode, deeper routing, or new SKILL.md content merely because it sounds plausible.
  • Keep SKILL.md lean. It is always-loaded converter context. Any net growth needs evidence that the added context earns its cost.
  • Never commit raw copyrighted book text. Use synthetic, public-domain, or explicitly licensed fixtures. Keep private evaluation corpora and raw live trajectories out of git.
  • Avoid new runtime dependencies for evaluation work. Evaluation-only dependencies belong outside the core runtime and must be justified.
  • Do not edit CHANGELOG.md by hand.
  • Preserve backwards compatibility unless the task explicitly authorizes a breaking change.
  • Do not weaken security checks, path hardening, sanitization, or generated-skill scanning to make an experiment pass.

Execution loop

For any non-trivial task, use this loop. Do not skip directly from idea to implementation.

  1. Orient
    • Read this file and the relevant source-of-truth files.
    • Inspect current code/tests before proposing new modules or abstractions.
    • For research-plan work, locate the first task whose status is READY and whose dependencies are complete.
  2. Plan the smallest coherent change
    • State the hypothesis or bug being addressed.
    • State what will not change.
    • Prefer reuse of existing utilities over parallel implementations.
    • Define the acceptance command(s) before editing code.
  3. Implement one task
    • Keep the diff focused.
    • Add deterministic tests with the implementation.
    • Do not opportunistically refactor unrelated code.
  4. Prove it
    • Run the task-specific checks.
    • Run the repository gates below.
    • Capture actual command output or machine-readable result artifacts; prose such as "looks good" is not evidence.
  5. Record state
    • Update the task status/evidence section in the research plan when that plan is in scope.
    • Record blockers as blockers; never mark a task complete because the intended code was written.
  6. Continue only after the gate is green
    • Move to the next dependency-ready task only after the current task is proven.
    • Respect PR boundaries defined in the plan. A task that changes production behavior must not be silently bundled with unrelated research infrastructure.

Validation gates

Minimum local checks for code changes:

pytest -q
ruff check .

If SKILL.md changes:

python3 tools/validate_skill.py SKILL.md

If extraction behavior changes, also run the relevant extractor smoke/reproduction command and its targeted tests.

If generated-skill behavior changes, provide a before/after generated artifact or benchmark result that demonstrates the intended difference without committing copyrighted source text.

A task is not DONE if a required check is skipped, failing, or replaced by an unverified claim.

Evaluation-work cost discipline

Live model experiments are expensive and are never the first validation step.

  • Unit/fixture tests first.
  • Small discriminating sample before a large sweep.
  • Cache/reuse generated packs keyed by source/config/model/prompt identity.
  • Pre-register the condition, corpus, questions, model/harness, repetitions, and token/cost ceiling before a live run.
  • Do not jump to 10/20-book sweeps before smaller-scale gates justify them.
  • If a cheaper test can falsify the hypothesis, run it first.

Instruction scope

This root file applies repository-wide. A more deeply nested AGENTS.md may add narrower instructions for its subtree; the more specific file wins when instructions conflict. Direct user/system instructions take precedence over repository guidance.

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.