agentleFS
Sign inStart free
ProviderProtocolProviderProtocol/ai/CLAUDE.md

ai

CLAUDE.md4 starsChanged 10 months agoMITView on GitHub

.env contains all AI provider keys. Be sure to use the LSP tool to help get / understand code. Code documentation MUST use TSDoc style. When using TSDoc consider what tags are stripped by TSDoc, and if stripped don't put user valuable information in them - only relevant knowledge for developers or code skimmers belongs there. When running tests only run live tests relevant to the changes, full live tests will and should be asked for to be done manually.…

  • Reads credentials

The file

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

10 rules. About 0 are common, 2 are distinctive, and 8 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.

  • 8

    Very specific

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

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

    Import management: - Do not re-export ever, the only allowed place is when it _FULLY MAKES SENSE_ to do so with index.ts files.

    line 15
  2. Distinctive:

    Commenting: - Avoid needless comments, if you make comments they should purely be documentational not inlined model reasoning.

    line 16
  3. Distinctive:

    Add / Update Tests: - When making changes or adding functionality ensure you add and/or update both LIVE and UNIT tests.

    line 18
  4. Very specific:

    Default to using Bun instead of Node.js.

    line 26
  5. Very specific:

    Use bun <file> instead of node <file> or ts-node <file>

    line 28
  6. Very specific:

    Use bun install instead of npm install or yarn install or pnpm install

    line 31
  7. Very specific:

    Use bunx <package> <command> instead of npx <package> <command>

    line 33
  8. Very specific:

    Prefer Bun.file over node:fs's readFile/writeFile

    line 43
  9. Very specific:

    Use bun test to run tests.

    line 48
  10. Very specific:

    Use HTML imports with Bun.serve().

    line 60

≈ “Common” is an estimate: at least 1 in 5 of the 26,980 CLAUDE.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
CLAUDE.md

Project Rules

  1. 100% TypeScript – No any, implicit types, or unchecked assumptions
  2. No library abstractions – Use library APIs directly; never truncate/morph library data
  3. AirBnB style – Follow AirBnB TypeScript/JavaScript conventions
  4. Zero lint/type errors – bun lint and bun typecheck must pass
  5. Electron-first – Desktop app; web security assumptions don't apply
  6. No re-exports – Import library types directly; don't create barrel files
  7. No tooling suppressions – No eslint-disable, @ts-ignore, etc.
  8. Shared UI components – Reusable components for shared styling/views
  9. Small files – Target ~300 LOC; refactor when beneficial
  10. Icon libraries only – No custom inline SVGs
  11. Intentional testing – Unit tests + live API tests; all tests must pass
  12. Persist atomic values only – Compute derived fields (duration, netCost) at runtime
  13. Import management - Do not re-export ever, the only allowed place is when it FULLY MAKES SENSE to do so with index.ts files.
  14. Commenting - Avoid needless comments, if you make comments they should purely be documentational not inlined model reasoning.
  15. Error Handling - Prioritize pro-active error handling, use modern try catch patterns and be mindful of plausible error spots.
  16. Add / Update Tests - When making changes or adding functionality ensure you add and/or update both LIVE and UNIT tests.

.env contains all AI provider keys.

Be sure to use the LSP tool to help get / understand code. Code documentation MUST use TSDoc style. When using TSDoc consider what tags are stripped by TSDoc, and if stripped don't put user valuable information in them - only relevant knowledge for developers or code skimmers belongs there. When running tests only run live tests relevant to the changes, full live tests will and should be asked for to be done manually. All providers are fully isolated 'modules', no cross provider utilization should occur.

Default to using Bun instead of Node.js.

  • Use bun <file> instead of node <file> or ts-node <file>
  • Use bun test instead of jest or vitest
  • Use bun build <file.html|file.ts|file.css> instead of webpack or esbuild
  • Use bun install instead of npm install or yarn install or pnpm install
  • Use bun run <script> instead of npm run <script> or yarn run <script> or pnpm run <script>
  • Use bunx <package> <command> instead of npx <package> <command>
  • Bun automatically loads .env, so don't use dotenv.

APIs

  • Bun.serve() supports WebSockets, HTTPS, and routes. Don't use express.
  • bun:sqlite for SQLite. Don't use better-sqlite3.
  • Bun.redis for Redis. Don't use ioredis.
  • Bun.sql for Postgres. Don't use pg or postgres.js.
  • WebSocket is built-in. Don't use ws.
  • Prefer Bun.file over node:fs's readFile/writeFile
  • Bun.$ls instead of execa.

Testing

Use bun test to run tests.

import { test, expect } from "bun:test";

test("hello world", () => {
  expect(1).toBe(1);
});

Frontend

Use HTML imports with Bun.serve(). Don't use vite. HTML imports fully support React, CSS, Tailwind.

Server:

import index from "./index.html"

Bun.serve({
  routes: {
    "/": index,
    "/api/users/:id": {
      GET: (req) => {
        return new Response(JSON.stringify({ id: req.params.id }));
      },
    },
  },
  // optional websocket support
  websocket: {
    open: (ws) => {
      ws.send("Hello, world!");
    },
    message: (ws, message) => {
      ws.send(message);
    },
    close: (ws) => {
      // handle close
    }
  },
  development: {
    hmr: true,
    console: true,
  }
})

HTML files can import .tsx, .jsx or .js files directly and Bun's bundler will transpile & bundle automatically. <link> tags can point to stylesheets and Bun's CSS bundler will bundle.

<html>
  <body>
    <h1>Hello, world!</h1>
    <script type="module" src="./frontend.tsx"></script>
  </body>
</html>

With the following frontend.tsx:

import React from "react";
import { createRoot } from "react-dom/client";

// import .css files directly and it works
import './index.css';

const root = createRoot(document.body);

export default function Frontend() {
  return <h1>Hello, world!</h1>;
}

root.render(<Frontend />);

Then, run index.ts

bun --hot ./index.ts

For more information, read the Bun API docs in node_modules/bun-types/docs/**.mdx.

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