agentleFS
Sign inStart free
automagik-siautomagik-si/omni/AGENTS.md

omni

AGENTS.md70 starsChanged 5 days agoApache-2.0View on GitHub

Omni is a Bun and TypeScript monorepo built around Hono, Drizzle, and NATS. Brand: docs/brand/ is a byte copy of Automagik's (the skill's SOURCE.json names the commit). Never edit it; change it in automagik and copy again. Agents use the automagik-brand skill for colours, type and logos. - General blocks. Omni is public. It ships general building blocks that any small business can combine into its own private support line. Never bake one deployment's code formats, sites or URLs, wording,…

  • Reads credentials

1 other project uses a version of this.

Adopted by

Most recently taken up by

  • Other versions1 project uses a version of this.

    Word for word · 1

    1. automagik-dev/omni★ 70100% 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,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 repository6 other files it gives its agents.

The file

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

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

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈3

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 3

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Never edit a deployed migration or use drizzle push against shared or production databases.

    line 9
  2. Distinctive:

    Do not start services, access databases or production systems, or send external messages without explicit approval.

    line 12
  3. Distinctive:

    Prefer safe static gates for routine validation.

    line 13
  4. Distinctive:

    Use a disposable database for database-backed or full integration tests.

    line 14
  5. Very specific:

    Not covered: plain one-word wish <word> (read as prose), other files and directories, commits and PR bodies.

    line 41
  6. Very specific:

    Before branching, run git fetch, then check gh pr list --state open and git ls-remote --heads origin for the same files or area.

    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

Omni repository contract

Omni is a Bun and TypeScript monorepo built around Hono, Drizzle, and NATS.

Brand: docs/brand/ is a byte copy of Automagik's (the skill's SOURCE.json names the commit). Never edit it; change it in automagik and copy again. Agents use the automagik-brand skill for colours, type and logos.

  • Validate every external boundary with Zod.
  • Represent state changes with events.
  • Never edit a deployed migration or use drizzle push against shared or production databases.
  • Change the schema and its generated SQL migration together.
  • Inspect nearby code and established repository patterns before implementing.
  • Do not start services, access databases or production systems, or send external messages without explicit approval.
  • Prefer safe static gates for routine validation.
  • Use a disposable database for database-backed or full integration tests.

Two rules for all work

  • General blocks. Omni is public. It ships general building blocks that any small business can combine into its own private support line. Never bake one deployment's code formats, sites or URLs, wording, tiers, or product, client or people names into code, tests, fixtures, docs, commits, PRs or issues. Make each one a setting; its value lives outside this repository.
  • Events first. Omni is event-driven: apps attach to its event streams. New capability ships as events that durable consumers can read, plus the reads and writes those apps need. Add no new design to Omni's built-in agents, agent routes, agent dispatcher or access gate. Existing agent features stay as they are.

Design records

  • Decisions live in docs/rfcs/README.md, the one index: RFCs, the frozen multitenancy ADR-NNNN keys, and earlier records. An RFC is short and links its Genie DESIGN and WISH; it never replaces them.
  • Tracked by default, at any depth: .genie/INDEX.md, brainstorm DRAFT.md/DESIGN.md, and wish *.md (planning Markdown only). Everything else under .genie is ignored (runtime state, other brainstorm notes, wish JSON/YAML/ scripts) and needs a deliberate forced add. Name-based exclusions (.env*, credentials*, secrets*, *.pem, *.key, config.json, *.db*, logs, caches) cover those non-Markdown files; a wish .md with any other name is tracked, so never write secrets into one. Files already tracked stay tracked.
  • Code, commits and PRs cite RFC-NNNN or an ADR key, never a .genie path or a wish slug. Write IETF standards with a space ("RFC 4122").
  • make verify-rfcs scans tracked files under apps/ packages/ scripts/ docs/ only. It fails when one of these does not resolve to an index row or a tracked file, beyond the counted allowlist in scripts/verify-rfcs.ts: any RFC-NNNN; ADR-NNNN or ADR-XXX-NNNN; a .genie/wishes|brainstorms/... path, or wishes|brainstorms/<slug>/... at the start of a word; wish <hyphenated-slug>; wish: <slug>, wish `<slug>` or wish **<slug>**. Not covered: plain one-word wish <word> (read as prose), other files and directories, commits and PR bodies.

Working across residences

Two teams, on two machines with two GitHub accounts, work this repo. Coordinate on GitHub only; there is no shared hc. For claiming and coordination, GitHub issues, assignments and PR comments on automagik-dev/omni are owner-approved (2026-11-03).

  • Claim before you work: self-assign the GitHub issue before branching. For unplanned work, open an issue first (neutral wording) and self-assign it. Skip issues assigned to someone else; ask on the issue instead.
  • Before branching, run git fetch, then check gh pr list --state open and git ls-remote --heads origin for the same files or area. If another claim or branch overlaps, coordinate on the issue or PR; do not start.
  • Branch feature work from fresh origin/dev. A feature branch is any branch other than dev and main. Never push to a feature branch your team did not create. Never force-push or rebase a shared branch. This branch rule covers feature branches; the direct-to-dev fixes in .claude/CLAUDE.md still apply.
  • Push and open a draft PR as early as the gate allows, so the other team sees the work. Link the issue.
  • Merge only PRs your own team opened; review or merge another team's PR only if they ask on it. Comment "merging" on the PR before queueing it.
  • Migration numbers: the "whoever merges second renumbers their own migration" rule (.claude/CLAUDE.md, parallel worktree numbering collisions) applies across teams too.
  • Orchestrators: at the start of each assignment cycle, read open PRs and assigned issues and avoid overlap.
  • Gate wrapper: on a host with a shared gate wrapper (a script that queues bun runs on host load), export OMNI_GATE_WRAPPER to its path before starting the bots, or have the orchestrator name it in every brief.

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