VercelKnown publishervercel-labs/visual-json/AGENTS.md

visual-json

AGENTS.md946 starsChanged 7 months agoApache-2.0View on GitHub

Run pnpm type-check after every change to ensure there are no type errors. Use the shadcn CLI (npx shadcn@latest add <component>) to install UI components in apps/web. Never write shadcn components by hand. Never use native JS alert(), confirm(), or prompt(). Use custom UI components instead. All apps and examples with dev servers use portless to avoid hardcoded ports. Portless assigns random ports and exposes each app via .localhost URLs. Naming convention: When adding a new example that runs a…

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.

The file

Show its rules and text

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

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

≈0
Common · estimate
Many files like this have a rule of this kind.
≈0
Distinctive · estimate
This author's own choices. Worth a look.
13
Very specific
Tied to their project's names, files or tools. Probably skip.

Common
Distinctive
Very specific

Very specific:
Run pnpm type-check after every change to ensure there are no type errors.
line 5
Very specific:
Use the shadcn CLI (npx shadcn@latest add <component>) to install UI components in apps/web.
line 9
Very specific:
Never use native JS alert(), confirm(), or prompt().
line 13
Very specific:
All apps and examples with dev servers use portless to avoid hardcoded ports.
line 17
Very specific:
When adding a new example that runs a dev server, wrap its dev script with portless <name>:
line 43
Very specific:
Do not add --port flags -- portless handles port assignment automatically.
line 53
Very specific:
Create a branch (e.g. prepare-v0.5.0)
line 61
Very specific:
Run pnpm version:sync to update all other @visual-json/* packages
line 63
Very specific:
Write the changelog entry in CHANGELOG.md at the top, under a new ## <version> heading, wrapped in  and <!-- …
line 64
Very specific:
Add a matching entry to apps/web/src/app/docs/changelog/page.mdx at the top (below the # Changelog heading)
line 65
Very specific:
When the PR merges, CI compares packages/@visual-json/core/package.json version to what's on npm.
line 68
Very specific:
Use HTML <table> elements for tables in all documentation files (README.md, MDX docs).
line 72
Very specific:
When making a user-facing change (adding, removing, or renaming a component, prop, API, or feature), update all relevant documentation in …
line 74

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

Verification

Run pnpm type-check after every change to ensure there are no type errors.

UI Components

Use the shadcn CLI (npx shadcn@latest add <component>) to install UI components in apps/web. Never write shadcn components by hand.

User-Facing Dialogs

Never use native JS alert(), confirm(), or prompt(). Use custom UI components instead.

Dev Servers

All apps and examples with dev servers use portless to avoid hardcoded ports. Portless assigns random ports and exposes each app via .localhost URLs.

Naming convention:

<table>
  <thead>
    <tr>
      <th>Type</th>
      <th>Portless name</th>
      <th>URL</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Main web app</td>
      <td><code>visual-json</code></td>
      <td><code>http://visual-json.localhost:1355</code></td>
    </tr>
    <tr>
      <td>Examples</td>
      <td><code>[name]-example.visual-json</code></td>
      <td><code>http://[name]-example.visual-json.localhost:1355</code></td>
    </tr>
  </tbody>
</table>

When adding a new example that runs a dev server, wrap its dev script with portless <name>:

{
  "scripts": {
    "dev": "portless my-app-example.visual-json next dev --turbopack"
  }
}

Do not add --port flags -- portless handles port assignment automatically. Do not add portless as a project dependency; it must be installed globally.

Releasing

Releases are manual, single-PR affairs. There is no changesets automation. The maintainer controls the changelog voice and format.

To prepare a release:

Create a branch (e.g. prepare-v0.5.0)
Bump version in packages/@visual-json/core/package.json
Run pnpm version:sync to update all other @visual-json/* packages
Write the changelog entry in CHANGELOG.md at the top, under a new ## <version> heading, wrapped in  and  markers. Remove the markers from the previous release entry so only the new release has markers.
Add a matching entry to apps/web/src/app/docs/changelog/page.mdx at the top (below the # Changelog heading)
Open a PR and merge to main

When the PR merges, CI compares packages/@visual-json/core/package.json version to what's on npm. If it differs, it builds, publishes all @visual-json/* packages, and creates the GitHub release automatically. The GitHub release body is extracted from the content between the  and  markers in CHANGELOG.md.

Documentation

Use HTML <table> elements for tables in all documentation files (README.md, MDX docs). Do not use markdown pipe tables.

When making a user-facing change (adding, removing, or renaming a component, prop, API, or feature), update all relevant documentation in the same PR: web app docs (apps/web/src/app/docs/), package READMEs, and any SKILL.md files that reference the changed surface area.

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