agentleFS
851-labs851-labs/tokenmaxxing/AGENTS.md

tokenmaxxing

AGENTS.md88 starsChanged 44 days agoMITView on GitHub

  • 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,700 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 repositoryOne other file it gives its agents.

The file

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

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

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈2

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 7

    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:

    Prefer native Effect errors over plain JavaScript Error subclasses in Effect code.

    line 5
  2. Very specific:

    Use Data.TaggedError for internal typed errors that stay inside the Effect error channel.

    line 6
  3. Very specific:

    Use Schema.TaggedError when an error is part of a public schema or wire contract.

    line 7
  4. Very specific:

    Avoid throw for expected domain failures.

    line 8
  5. Distinctive:

    Prefer local declarations first and grouped exports at the end of each authored source file.

    line 12
  6. Very specific:

    Use export { ... } for runtime values and export type { ...

    line 13
  7. Very specific:

    Put default exports at the end too, using a named local value before export default name;.

    line 14
  8. Distinctive:

    Do not hand-edit generated files just to satisfy this style rule.

    line 15
  9. Very specific:

    Keep bun run test output clean.

    line 26

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

Effect Error Style

  • Prefer native Effect errors over plain JavaScript Error subclasses in Effect code.
  • Use Data.TaggedError for internal typed errors that stay inside the Effect error channel.
  • Use Schema.TaggedError when an error is part of a public schema or wire contract.
  • Avoid throw for expected domain failures; return Effect.fail(...) with a typed error instead.

Export Style

  • Prefer local declarations first and grouped exports at the end of each authored source file.
  • Use export { ... } for runtime values and export type { ... } for type-only exports.
  • Put default exports at the end too, using a named local value before export default name;.
  • Do not hand-edit generated files just to satisfy this style rule.

Conventions

  • Daily usage rows are keyed (deviceId, date, source, model) and upserted; sync must stay idempotent.
  • Cost is frozen at first upload unless the usage (token counts) changes: the usage_days upsert keeps the stored cost_usd when all token columns match (ccusage re-prices unmarked Codex history with the device's current speed tier), takes the incoming cost when any token count differs, and prices a row stored at 0. Fixing already-stored cost means editing D1 directly; re-ingesting payloads with the same tokens is a no-op for cost.
  • Only a parser change may lower a re-sent day. Each raw-ingested usage_days row records counted_by, the server PARSER_VERSION that produced it. A re-sent (device, day, source) is kept when every stored row has the current counted_by and the uploading owner, and the stored total is higher than the re-count. Kept means never lowered or pruned, though models that are new or grew are still taken. A lower re-count from the same parser means the device lost logs (deleted or pruned, a narrower source root, a full re-sync past Claude Code's 30-day cleanup), not a correction. The decision is per whole day, so a model relabeled without a loss is still replaced and pruned. Any other re-send replaces the day as before. So a correction that has to lower or drop stored usage ships as a PARSER_VERSION bump, also when it comes from a ccusage or CLI-side counting fix. A bump is required for any server change to the rows a report yields (parsing, model labels, plausibility limits). A bump re-counts every device's trailing window once, losses included. The structured /usage/sync path writes NULL, which is always replaced. Known gaps: a timezone change moves usage near midnight into the next day while the earlier day keeps its higher count, and two concurrent ingests from one device can race the check.
  • date columns are opaque YYYY-MM-DD strings (ccusage local-time buckets); never parse them into Date objects for bucketing. Do day arithmetic with shiftDayKey/utcDayKey from @tokenmaxxing/api-contract (API windows live in apps/api/src/date-keys.ts).
  • Published CLIs bundle a frozen contract. packages/api-contract/fixtures/ (recorded CLI requests + the CLI endpoint OpenAPI slice) is a compatibility contract: review diffs there as breaking-change reviews, and add a legacy/ fixture before changing a shape a released CLI sends. Responses go the other way: apps/api/src/http/cli-compat.test.ts decodes every replayed response and typed CLI error with frozen copies of the released CLI decoders, so fields may be added but never dropped, renamed or retyped, and error _tags never change. fixtures/full-api.openapi.json snapshots the whole API as a review aid; only the CLI slice is frozen.
  • CLI tokens (tmx_ prefix) never expire; revocation (revokedAt) is the only kill switch.
  • D1 caps a statement at 100 bound parameters, and the sqlite test harness (apps/api/src/testing/sqlite-d1.ts) enforces it. Never bind an unbounded list: chunk it, or pass it as one JSON parameter through json_each.
  • Keep bun run test output clean. A test that exercises a logging path captures and asserts the log (makeTestLogger in apps/api/src/testing/logger.ts; vi.spyOn(console, ...) outside Effect) instead of letting it print. makeTestApp already captures into app.logs. Captured Effect logs are replayed when a test fails.

Reference Repos

  • .repos/ holds upstream source as git submodules, for reading how a dependency actually behaves. It is read-only: never edit, import from, or build it (lint, format and tests already ignore it).
  • .repos/effect-smol and .repos/alchemy-effect are pinned to the release tags matching the catalog versions in the root package.json (effect@X and vX tags). When bumping effect or alchemy in the catalog, move the submodule to the matching tag in the same PR: git -C .repos/effect-smol fetch --tags && git -C .repos/effect-smol checkout effect@X, then stage .repos/effect-smol. Don't use git submodule update --remote.
  • .repos/opencode is not a dependency; it tracks upstream dev as a reference for OpenCode's data and CLI patterns.
  • Fetch them with git submodule update --init .repos/<name>. If a checkout is missing, stale or disagrees with the installed version, node_modules is the source of truth.

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.