agentleFS
isaacsightisaacsight/kernel/AGENTS.md

kernel

AGENTS.md16 starsChanged 4 months agoMITView on GitHub

Codex auto-loads this file. It is the operating contract, not the full reference. Read the linked docs before design work. The canonical project reference is KERNEL.md. Two surfaces, one publication. (1) kbot — an open-source terminal AI agent. (2) kernel.chat — an editorial magazine. You will almost always be working on the magazine: interactive issues, spreads, and standalone artifacts. The room is a magazine; speak like one. The detailed design, interaction, and verification law lives outside this file. Before any…

  • Reads credentials

The file

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

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

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    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
  • could be automatic: a setting could enforce it
  1. Distinctive:

    Before any design or layout task, read:

    line 17
  2. Very specific:

    Never touch secrets: Do not read, edit, print, or commit .env, *.key, *.pem, or supabase/config.toml secrets.

    line 35

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

AGENTS.md — kernel.chat operating contract for Codex

Codex auto-loads this file. It is the operating contract, not the full reference. Read the linked docs before design work. The canonical project reference is KERNEL.md.

What this is (30 seconds)

Two surfaces, one publication. (1) kbot — an open-source terminal AI agent. (2) kernel.chat — an editorial magazine. You will almost always be working on the magazine: interactive issues, spreads, and standalone artifacts. The room is a magazine; speak like one.

Read before you design

The detailed design, interaction, and verification law lives outside this file. Before any design or layout task, read:

  • .agents/AGENTS.md — full design / interaction / verification law
  • KERNEL.md — project shape, directory map, ship flow
  • docs/design-language.md — visual grammar
  • docs/interaction-language.md — motion + calmness law

Non-negotiables (these override convenience)

  1. Magazine vocabulary in all user-visible copy: issue, feature, spread, folio, monument, colophon, dateline, postmark — never dashboard, panel, card, widget, modal. Never name the visual homage ("POPEYE") on the site.
  2. No emojis in code or user-visible copy. The single system asterisk ★ is the only exception.
  3. No JS animation runtimes (Framer Motion, motion.dev, Lottie) on editorial surfaces. Page/editorial motion is CSS-only. Script motion is allowed only inside a framed mechanism (plate/bore) and must collapse under prefers-reduced-motion.
  4. Never touch secrets. Do not read, edit, print, or commit .env, *.key, *.pem, or supabase/config.toml secrets. Never hardcode keys or tokens.
  5. Never push to main. See workflow below — main is the live publisher.

How you work (full-auto, one hard stop)

You work autonomously. Branch, edit, verify, commit, push the branch, open a PR — all without asking. You stop at exactly one line: merging or pushing to main. That is a human decision because it deploys.

  1. Branch off main: feat/<short-slug> (or fix/<slug>). Never commit directly on main.
  2. Edit freely within the repo.
  3. Verify — the gate below must pass before you call anything done.
  4. Commit with an evidence-cited message (cite the numbers/reason, per the project's commit discipline).
  5. Push the branch and open a PR. Then STOP and hand back to the human for the merge.

Verify gate (must pass before "done")

npx tsc --noEmit          # must be clean
npm run build             # must be clean (tsc && vite build)
npm run lint:adherence    # brand/adherence checks
npm run lint:editorial    # editorial checks

Plus a visual check: preview with npm run dev, confirm the issue accent is POPEYE-safe, the ★ glyph renders, and there is zero horizontal scroll at 390px and 393px. Print preview (Cmd+P) must stack all interactive states with no chrome.

Deploy — do not

npm run deploy is retired. main is the only publisher: any push to main triggers CI deploy (~90s). You never push to main and never run deploy scripts. Opening the PR is where your job ends.

Preview loop

npm run dev               # vite dev server → open the printed localhost URL

Iterate against the live preview. That is how the person next to you sees your work in real time.

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.