agentleFS
Sign inStart free
krishhggkrishhgg/t3term/AGENTS.md

t3term

AGENTS.md11 starsChanged 27 days agoMITView on GitHub

t3term is a Rust terminal client for the T3 Code server. README.md documents the CLI contract, including the exit codes and --json output. .greptile/config.json lists the rules reviews apply. docs/parity.md is the feature plan, and docs/sprint.md records the sprint that builds it. Tests show what each branch of the code does. They don't show that a feature works in the built binary, so a pull request that changes what a user sees or does also gets driven there. The skills…

  • Reads credentials
  • 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 repository8 other files it gives its agents.

The file

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

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

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈4

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Keep them small and frequent.

    line 14
  2. Distinctive:

    Keep the description short and lead with what the pull request changes.

    line 15
  3. Very specific:

    verify-t3term drives the built binary in tmux against a fake T3 server, through scripts/t3v.

    line 28
  4. Distinctive:

    verify-pr gives a pull request its verdict, PASS, PASS+NOTES or FAIL, from the same drive on its base and its head.

    line 29
  5. Distinctive:

    verify-this proves or disproves one claim with a baseline and a treatment.

    line 30

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

Working on t3term

t3term is a Rust terminal client for the T3 Code server. README.md documents the CLI contract, including the exit codes and --json output. .greptile/config.json lists the rules reviews apply. docs/parity.md is the feature plan, and docs/sprint.md records the sprint that builds it.

Who does what

  • The user sets scope and merges every pull request. No agent merges a pull request, whether it changes the UI or not.
  • GPT-6.1 Sol (xhigh) orchestrates the sprint. It runs all testing and computer use itself, reviews each pull request, gives it its verdict and prepares it for merge.
  • Claude Opus 5.5 (xhigh) writes the implementation, the tests and the fixes. It is the only agent that writes code.
  • The agent that wrote a pull request never gives it its verdict. Sol does, or a fresh agent on another model that didn't write it.

Pull requests

  • Keep them small and frequent. Open a draft early, push at each checkpoint and mark it ready when the work is done.
  • Keep the description short and lead with what the pull request changes. End it with a decision log under these five headings:
    • What I noticed: the problem or gap that started the work.
    • How I confirmed it: the code, contract or run that showed it.
    • Options: the approach chosen and the ones rejected, with why.
    • What review changed: what Greptile, Sol or the user asked for and what changed as a result.
    • Known limits: what the pull request leaves out or doesn't handle.
  • Changes to how the TUI looks carry screenshots or recordings. Keep UI and non-UI changes in separate pull requests where practical.
  • Greptile reviews every pull request. A pull request is ready for the user when CI passes, every Greptile finding is fixed or answered, and its head commit has a PASS or PASS+NOTES verdict (see Verification).

Verification

Tests show what each branch of the code does. They don't show that a feature works in the built binary, so a pull request that changes what a user sees or does also gets driven there. The skills under .claude/skills/ hold the procedures:

  • verify-t3term drives the built binary in tmux against a fake T3 server, through scripts/t3v. Its features/ map says how to reach and drive each feature, and scripts/smoke runs every recipe in it.
  • verify-pr gives a pull request its verdict, PASS, PASS+NOTES or FAIL, from the same drive on its base and its head.
  • verify-this proves or disproves one claim with a baseline and a treatment.
  • tdd covers regression tests, blast-radius what a change could break outside its diff, and benchmark-checklist any performance number.
  • maintain-verify-t3term keeps the feature map true to the app.

A pull request that changes what a user sees or does updates its file under features/, or adds one. A bug fix carries a test that fails with the fix reverted. A verdict covers one patch, so a push that changes the patch needs a new verdict. verify-pr says when a rebase keeps it.

Checks

CI runs these on macOS for every pull request, with Rust pinned to 1.95.0 in .github/workflows/ci.yml:

cargo fmt --all -- --check
cargo clippy --locked --all-targets -- -D warnings
cargo test --locked

Tests must not read the real ~/.t3, use the Keychain or reach a real T3 server. tests/fake_server.rs drives the RPC client against a fake WebSocket server, and tests/cli.rs runs the binary with a temporary HOME and T3CODE_HOME against fake servers on 127.0.0.1. Follow one of those.

CI needs no secrets. Never read .env files or print tokens. If a feature ever needs a real secret, request it through tokenstash.

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