agentleFS
sstsst/opentui/AGENTS.md

opentui

AGENTS.md14k starsChanged 13 days agoMITView on GitHub

- Reuse existing seams; do not duplicate policy, ownership, or state across TypeScript, Zig, and framework layers. - For bug fixes, first add a focused regression test of observable behavior or invariants. If automation is impossible, record the evidence and remaining manual verification; do not substitute contract sketches or guesses. - Make native ownership explicit; clean up handles, callbacks, buffers, and listeners on every exit path. Bound input-driven work and test lifecycle failures. - Do not interchange byte lengths, code…

1 other project uses a version of this.

Trending

Quiet since August.about the whole repository

Dec 2025: 14 mentionsJan 2026: 2 mentionsFeb 2026: 0 mentionsMar 2026: 0 mentionsApr 2026: 0 mentionsMay 2026: 1 mentionJun 2026: 0 mentionsJul 2026: 0 mentionsAug 2026: 2 mentionsSep 2026: 0 mentionsOct 2026: 0 mentionsNov 2026: 0 mentions
Dec 2025Jun 2026Nov 2026
Mentions a month of the sst/opentui repository that our weekly crawl found. There is no adoption data for this file yet.

Most recently taken up by

Who's talking about sst/opentui

The biggest 5 of 53 mentions linking to the repository that our crawl found. Each line is their own headline.

See all 53

Talked about on GitHub, Bluesky and Hacker News (53 times).

On GitHub · 39

34 more on GitHub

On Bluesky · 13

8 more on Bluesky

On Hacker News · 1

  • Other versions1 project uses a version of this.

    Word for word · 1

    1. anomalyco/opentui★ 14k100% same

    Edited · 0

    None found.

    Wrote their own version · 0

    None found.

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • 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.

The file

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

11 rules. About 0 are common, 4 are distinctive, and 7 are 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.

  • 7

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Do not interchange byte lengths, code points, graphemes, and terminal display-cell widths.

    line 10
  2. Distinctive:

    Use concrete scopes such as frame parity, callback ordering, resource cleanup, or loopback SSH output tests.

    line 14
  3. Very specific:

    Use Bun for dependency management and development commands: bun install, bun run <script>, bun test, and bun <file>.

    line 19
  4. Distinctive:

    Run package scripts from the package directory unless the script is defined at the repository root.

    line 20
  5. Distinctive:

    Run the narrowest relevant test first, then the affected package suite.

    line 27
  6. Very specific:

    Run bun run build from the repository root after native or cross-package build/output changes, or when tests report a missing/stale native …

    line 30
  7. Very specific:

    Use root bun run fmt:check and bun run lint for final static checks when relevant.

    line 35
  8. Very specific:

    Prefer tests and TestRenderer for automated debugging.

    line 37
  9. Very specific:

    Default to buffer for transient, non-null TypedArray parameters and pass the view directly.

    line 47
  10. Very specific:

    Use ptr only when a parameter can be null, accepts a numeric native address, or is a callback.

    line 51
  11. Very specific:

    Use ptr(view) only when native code stores the address beyond the call.

    line 56

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

OpenTUI Agent Guide

Engineering

  • Reuse existing seams; do not duplicate policy, ownership, or state across TypeScript, Zig, and framework layers.
  • For bug fixes, first add a focused regression test of observable behavior or invariants. If automation is impossible, record the evidence and remaining manual verification; do not substitute contract sketches or guesses.
  • Make native ownership explicit; clean up handles, callbacks, buffers, and listeners on every exit path. Bound input-driven work and test lifecycle failures.
  • Do not interchange byte lengths, code points, graphemes, and terminal display-cell widths.
  • oxfmt is the formatting source of truth (semi: false, printWidth: 120); avoid unrelated formatting churn.
  • In delegated tasks, name the local rendering behavior, owned files, and required checks. Describe ordinary renderer work as correctness and compatibility testing; reserve security terminology for actual security work. Use concrete scopes such as frame parity, callback ordering, resource cleanup, or loopback SSH output tests. Request an independent correctness review and a separate reproduction check of actionable findings.

Tooling And Runtimes

  • Use Bun for dependency management and development commands: bun install, bun run <script>, bun test, and bun <file>.
  • Run package scripts from the package directory unless the script is defined at the repository root.
  • Shared runtime code must preserve the supported Bun and Node paths. Keep runtime-specific behavior behind existing platform/runtime/build seams; do not introduce Bun-only APIs into shared modules. Node checks use the minimum version enforced by scripts/node26.mjs.

Verification

  • Run the narrowest relevant test first, then the affected package suite.
  • Ordinary TypeScript source changes do not require the root build. Use the affected package's test, typecheck, build, or validation scripts as applicable.
  • Run bun run build from the repository root after native or cross-package build/output changes, or when tests report a missing/stale native artifact. It does not build web or examples; use their package scripts.
  • For native changes, run bun run test:native from packages/core. Filter with bun run test:native -Dtest-filter="test name" while iterating.
  • For runtime, FFI, build, or export changes, run the relevant Node and packed-distribution scripts from that package (such as test:js:node or test:dist) when present.
  • Use root bun run fmt:check and bun run lint for final static checks when relevant.

Prefer tests and TestRenderer for automated debugging. For interactive behavior, load the terminal-control skill and use its terminal tool to run, drive, and inspect the app; repository examples bind backtick to renderer.console.toggle() for captured console.log output. Ask for a user-run reproduction only when the required terminal or platform is unavailable locally.

Portable FFI

  • Portable symbol signatures must stay within the node:ffi/bun:ffi intersection. Use explicit widths such as u32/u64, not backend-only ABI names such as usize, napi_env, or napi_value; represent i64/u64 as bigint, native booleans as 0/1, and shared pointers as number | bigint.
  • Default to buffer for transient, non-null TypedArray parameters and pass the view directly. Do not call ptr().
  • For a raw ArrayBuffer, create one Uint8Array view over it, keep that view, and declare buffer. A buffer call costs less than a ptr call. buffer rejects an argument that is not a view with a TypeError. ptr sends a bad argument to native code as an address.
  • Use ptr only when a parameter can be null, accepts a numeric native address, or is a callback. Pass transient owner objects directly to ptr parameters. Do not pre-resolve them.
  • Bun 1.3 does not accept DataView directly for buffer or ptr parameters. Pass an equivalent typed array such as new Uint8Array(view.buffer, view.byteOffset, view.byteLength).
  • On Bun 1.4+, use buffer when you pass a DataView directly to FFI.
  • Use ptr(view) only when native code stores the address beyond the call. Before resolving it, access view.buffer to move any inline typed-array storage into a stable ArrayBuffer, then keep the view alive for the complete native lifetime. The order is required: const owner = view.buffer; const address = ptr(view). Calling ptr(view) first and accessing view.buffer later can move the storage and invalidate address.
  • Model C-string inputs as pointer parameters and pass owned, NUL-terminated byte buffers directly; string returns are not portable. Create callbacks through the loaded library/platform facade, not new JSCallback(...), and assume only same-thread callbacks.

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.