ant-design-cli
AGENTS.md261 starsChanged 4 months agoMITView on GitHub
This file provides guidance to Codex (Codex.ai/code) when working with code in this repository. Principles inspired by andrej-karpathy-skills. Bias toward caution over speed. For trivial tasks, use judgment. Don't assume. Don't hide confusion. Surface tradeoffs. Minimum code that solves the problem. Nothing speculative. Ask yourself: "Would a senior engineer say this is overcomplicated?" If yes, simplify. Touch only what you must. Clean up only your own mess. When editing existing code: When your changes create orphans: The test: Every changed…
- Commits and pushes
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
Show its rules and text
We split this AGENTS.md into the rules it gives an agent
23 rules. About 0 are common, 16 are distinctive, and 7 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈16
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
- Distinctive: line 14
If multiple interpretations exist, present them — don't pick silently.
- Distinctive: line 15
If a simpler approach exists, say so.
- Distinctive: line 16
If something is unclear, stop.
- Distinctive: line 22
No features beyond what was asked.
- Distinctive: line 23
No abstractions for single-use code.
- Distinctive: line 25
No error handling for impossible scenarios.
- Distinctive: line 26
If you write 200 lines and it could be 50, rewrite it.
- Distinctive: line 28
Ask yourself: "Would a senior engineer say this is overcomplicated?" If yes, simplify.
- Distinctive: line 34
When editing existing code:
- Distinctive: line 36
Don't "improve" adjacent code, comments, or formatting.
- Distinctive: line 37
Don't refactor things that aren't broken.
- Distinctive: line 39
If you notice unrelated dead code, mention it — don't delete it.
- Distinctive: line 41
When your changes create orphans:
- Very specific: line 43
Remove imports/variables/functions that YOUR changes made unused.
- Distinctive: line 44
Don't remove pre-existing dead code unless asked.
- Very specific: line 106
Create src/commands/<name>.ts exporting registerXxxCommand(program: Command): void
- Very specific: line 107
Import and call it in src/index.ts under the appropriate comment block
- Very specific: line 108
Follow the pattern: read global opts via program.opts<GlobalOptions>(), call detectVersion(), load metadata, then output() or printError()
- Distinctive: line 152
Never commit directly to main: Always create a feature branch and submit a PR.
- Distinctive: line 156
Every publish (including beta/pre-release) must follow this checklist:
- Very specific: line 158
Update CHANGELOG.md with a version section describing all changes
- Very specific: line 162
Create GitHub Release: gh release create v{version} --title "v{version}" --notes "<changelog content>" (add --prerelease for beta)
- Very specific: line 177
All commands support --format json|text|markdown and --lang en|zh
≈ “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.
Files
AGENTS.md
This file provides guidance to Codex (Codex.ai/code) when working with code in this repository.
Coding Principles
Principles inspired by andrej-karpathy-skills. Bias toward caution over speed. For trivial tasks, use judgment.
1. Think Before Coding
Don't assume. Don't hide confusion. Surface tradeoffs.
- State your assumptions explicitly. If uncertain, ask.
- If multiple interpretations exist, present them — don't pick silently.
- If a simpler approach exists, say so. Push back when warranted.
- If something is unclear, stop. Name what's confusing. Ask.
2. Simplicity First
Minimum code that solves the problem. Nothing speculative.
- No features beyond what was asked.
- No abstractions for single-use code.
- No "flexibility" or "configurability" that wasn't requested.
- No error handling for impossible scenarios.
- If you write 200 lines and it could be 50, rewrite it.
Ask yourself: "Would a senior engineer say this is overcomplicated?" If yes, simplify.
3. Surgical Changes
Touch only what you must. Clean up only your own mess.
When editing existing code:
- Don't "improve" adjacent code, comments, or formatting.
- Don't refactor things that aren't broken.
- Match existing style, even if you'd do it differently.
- If you notice unrelated dead code, mention it — don't delete it.
When your changes create orphans:
- Remove imports/variables/functions that YOUR changes made unused.
- Don't remove pre-existing dead code unless asked.
The test: Every changed line should trace directly to the user's request.
4. Goal-Driven Execution
Define success criteria. Loop until verified.
Transform tasks into verifiable goals:
- "Add validation" → "Write tests for invalid inputs, then make them pass"
- "Fix the bug" → "Write a test that reproduces it, then make it pass"
- "Refactor X" → "Ensure tests pass before and after"
For multi-step tasks, state a brief plan:
1. [Step] → verify: [check]
2. [Step] → verify: [check]
3. [Step] → verify: [check]Strong success criteria let you loop independently. Weak criteria ("make it work") require constant clarification.
Spec
See spec.md for the full design specification.
Always update spec.md after modifying any functionality, commands, flags, or output formats.
Development
npm run build # Build with tsup (required before running e2e tests)
npm run dev # Watch mode
npm run test # Run all tests with vitest
npm run typecheck # TypeScript type check
node dist/index.js # Run built CLITo run a single test file:
npx vitest run src/__tests__/cli.test.tsNote: The e2e tests in src/__tests__/cli.test.ts run against the built dist/index.js — always npm run build first.
Architecture
Data Flow
CLI invocation
→ src/index.ts (parses global flags, dispatches to command)
→ src/commands/*.ts (command logic)
→ src/data/version.ts (resolves antd version: --flag > node_modules > package.json > fallback)
→ src/data/loader.ts (loads data/v4.json | v5.json | v6.json)
→ src/output/ (formats output as text/json/markdown)Adding a New Command
- Create
src/commands/<name>.tsexportingregisterXxxCommand(program: Command): void - Import and call it in
src/index.tsunder the appropriate comment block - Follow the pattern: read global opts via
program.opts<GlobalOptions>(), calldetectVersion(), load metadata, thenoutput()orprintError()
Key Modules
src/types.ts— All shared types (ComponentData,MetadataStore,GlobalOptions,CLIError) and thelocalize()helper for en/zh switchingsrc/data/loader.ts—loadMetadata(majorVersion)loads bundled JSON;findComponent()does case-insensitive lookupsrc/data/version.ts—detectVersion(flagVersion?)returns{ version, majorVersion, source }; also exportscompare()andvalid()semver helperssrc/output/error.ts—createError(),printError(),fuzzyMatch()(Levenshtein-based typo suggestions), andErrorCodesconstantssrc/output/formatter.ts—output(data, format)andformatTable(headers, rows, format)for aligned text/markdown/json tablessrc/utils/scan.ts—collectFiles(dir)andgetJSXElementName(node)used bylintandusagecommands
Project Structure
src/
index.ts # CLI entry point, registers all commands
types.ts # Shared TypeScript types + localize() helper
commands/ # One file per command (list, info, demo, token, semantic, changelog/diff, doctor, usage, lint, migrate, mcp)
mcp/ # MCP server: tools.ts (7 tool definitions + handlers), prompts.ts (prompt constants)
data/ # loader.ts, version.ts, cache.ts
output/ # formatter.ts, error.ts
utils/ # scan.ts (file collection + antd import parsing)
__tests__/ # e2e CLI tests (require built dist/), unit tests in commands/ subdir
data/
v4.json # Bundled antd v4 metadata
v5.json # Bundled antd v5 metadata
v6.json # Bundled antd v6 metadata
scripts/
extract.ts # Data extraction from antd source checkout
extractors/ # Per-data-type extractor modulesTech Stack
- TypeScript + Node.js (ESM,
"type": "module") - CLI framework:
commander - Build:
tsup - Tests:
vitest - Node minimum: 20+
Git Workflow
- Never commit directly to main. Always create a feature branch and submit a PR.
Release Workflow
Every publish (including beta/pre-release) must follow this checklist:
- Update
CHANGELOG.mdwith a version section describing all changes - Run tests (
npm run test) npm publish --otp=<code>(add--tag betafor pre-releases)git tag v{version} && git push origin v{version}- Create GitHub Release:
gh release create v{version} --title "v{version}" --notes "<changelog content>"(add--prereleasefor beta)
CHANGELOG.md and GitHub Release notes must have identical content. Never use auto-generated release notes — always write them manually to match the CHANGELOG.
Testing Safety
Tests must NEVER cause real-world side effects. Any function that interacts with external services (GitHub API, npm registry, network requests, file system outside temp dirs, etc.) must be fully mocked in tests. Specifically:
submitViaGh,checkGhAvailableand any function that callsghCLI or creates GitHub issues must usevi.fn()with a safe default implementation (e.g.vi.fn(() => false)), nevervi.fn(actualFunction)which would use the real function as fallbackvi.restoreAllMocks()resets mocks to their default implementation — if the default is the real function, it will execute after restore. Always use safe no-op defaults invi.mock()factories- Network-calling functions (
node:https,fetch, etc.) must be mocked to prevent real HTTP requests - Tests that create temp files/directories must clean up in
finallyblocks orafterEach
Key Conventions
- All commands support
--format json|text|markdownand--lang en|zh - JSON output must be machine-parseable with no decoration
- Error output follows the standard shape:
{ error, code, message, suggestion }; errors go to stderr, normal output to stdout - Exit codes:
0success,1user error,2system error - Data is fully bundled — no remote fetch at runtime
- CLI version flag is
-V/--cli-version(not--version, which targets antd version) - Bilingual data stored as paired fields:
description/descriptionZh, uselocalize(en, zh, lang)to pick
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
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.

