agentleFS
Sign inStart free
krmisystemskrmisystems/fantasy-football-manager/AGENTS.md

fantasy-football-manager

AGENTS.md91 starsChanged 2 months agoMITView on GitHub

These instructions apply to this repository and its subdirectories. After repository updates, complete these checks before the final handoff: A successful checker process does not prove that all distribution channels are current. Do not mark distribution verification complete while required evidence remains pending or unknown. Distinguish completed code changes from external publication or synchronization that remains incomplete. Use --strict when the calling process must fail for any pending, stale, failed, or unknown check, including local state. The current checker cannot…

  • 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,439 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 repository4 other files it gives its agents.

The file

Show its rules and text

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

19 rules. About 1 is common, 14 are distinctive, and 4 are very specific to this project.

  • ≈1

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈14

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 4

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  • could be automatic: a setting could enforce it
  1. Very specific:

    Use the write-ste-technical-content skill for technical writing.

    line 7
  2. Distinctive:

    Use short sentences, active voice, and consistent terms.

    line 8
  3. Distinctive:

    Do not claim formal ASD-STE100 conformity without a formal review.

    line 11
  4. Distinctive:

    After repository updates, complete these checks before the final handoff:

    line 15
  5. Distinctive:

    Run the tests that apply to the change.

    line 17
  6. Very specific:

    Run uv run python scripts/validate_release.py for release metadata and privacy checks.

    line 18
  7. Distinctive:

    Run the distribution checker:

    line 19
  8. Distinctive:

    Read the JSON report and Markdown summary.

    line 25
  9. Distinctive:

    After an authorized push, merge, or publication, repeat the distribution check against the new remote state.

    line 27
  10. Distinctive:

    Do not mark distribution verification complete while required evidence remains pending or unknown.

    line 30
  11. Very specific:

    Use --strict when the calling process must fail for any pending, stale, failed, or unknown check, including local state.

    line 32
  12. Distinctive:

    Do not perform these actions solely to make a status check pass.

    line 38
  13. Distinctive:

    Use existing user authorization when an external action is part of the task.

    line 39
  14. Very specific:

    Keep private reports under the ignored .local-state/ directory.

    line 45
  15. Common:

    Do not commit credentials, personal team data, server names, or private paths.

    line 46
  16. Distinctive:

    Never log tokens or session values.

    line 47
  17. Distinctive:

    Use fictional fixtures for public tests and screenshots.

    line 48
  18. Distinctive:

    Do not infer a hosted build commit from matching README content or version text.

    line 50
  19. Distinctive:

    Do not claim a full tool schema comparison when only names and descriptions were checked.

    line 51

≈ “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

Repository instructions

These instructions apply to this repository and its subdirectories.

Technical writing

  • Use the write-ste-technical-content skill for technical writing.
  • Use short sentences, active voice, and consistent terms.
  • Separate verified results, estimates, planned work, and untested behavior.
  • Preserve exact commands, paths, identifiers, and protocol fields.
  • Do not claim formal ASD-STE100 conformity without a formal review.

Completion checks

After repository updates, complete these checks before the final handoff:

  1. Run the tests that apply to the change.
  2. Run uv run python scripts/validate_release.py for release metadata and privacy checks.

  3. Run the distribution checker:

    python scripts/check_distribution_status.py --output .local-state/distribution-status/report.json --summary .local-state/distribution-status/summary.md
  4. Read the JSON report and Markdown summary.
  5. Report each pending, stale, failed, or unknown local and external state.
  6. After an authorized push, merge, or publication, repeat the distribution check against the new remote state.

A successful checker process does not prove that all distribution channels are current. Do not mark distribution verification complete while required evidence remains pending or unknown. Distinguish completed code changes from external publication or synchronization that remains incomplete. Use --strict when the calling process must fail for any pending, stale, failed, or unknown check, including local state. The current checker cannot attest to the hosted Glama build commit, so strict mode cannot report all checks current. Report this evidence limit instead of weakening the check.

The checker reads public service data and optional authenticated GitHub data. Its execution does not authorize publication, a Glama sync, configuration changes, or messages to maintainers. Do not perform these actions solely to make a status check pass. Use existing user authorization when an external action is part of the task. These instructions and the GitHub Actions workflow apply only to this repository. They do not configure global Codex settings or native plugin hooks.

Evidence and privacy

  • Keep private reports under the ignored .local-state/ directory.
  • Do not commit credentials, personal team data, server names, or private paths.
  • Never log tokens or session values.
  • Use fictional fixtures for public tests and screenshots.
  • Preserve separate version labels for the Python package and the Glama image.
  • Do not infer a hosted build commit from matching README content or version text.
  • Do not claim a full tool schema comparison when only names and descriptions were checked.

See Distribution status for the check scope and operating limits.

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.

Check your setup, free