agentleFS
caol64caol64/wenyan-cli/AGENTS.md

wenyan-cli

AGENTS.md235 starsChanged 4 months agoApache-2.0View on GitHub

  • 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,700 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 repository3 other files it gives its agents.

The file

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

5 rules. About 0 are common, 1 is distinctive, and 4 are 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.

  • 4

    Very specific

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

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

    Use pnpm for all package management and repo scripts.

    line 5
  2. Very specific:

    Run one test file: pnpm exec node --import tsx --test tests/serve.test.ts

    line 12
  3. Very specific:

    Run one test by name: pnpm exec node --import tsx --test --test-name-pattern "should return health status" tests/serve.test.ts

    line 13
  4. Very specific:

    Keep the codebase in ESM TypeScript ("type": "module", moduleResolution: "NodeNext").

    line 33
  5. Distinctive:

    When adding input-related behavior, keep the existing precedence rules and do not break stdin-based usage for CI/CD pipelines.

    line 38

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

Build, test, and lint

  • Use pnpm for all package management and repo scripts.
  • Install dependencies: pnpm install
  • Lint: pnpm run lint
  • Type-check: pnpm run typecheck
  • Build: pnpm run build
  • Full test suite: pnpm run test
  • Watch tests: pnpm run test:watch
  • Run one test file: pnpm exec node --import tsx --test tests/serve.test.ts
  • Run one test by name: pnpm exec node --import tsx --test --test-name-pattern "should return health status" tests/serve.test.ts
  • CLI/manual smoke flows already scripted in package.json:
    • pnpm run test:bin
    • pnpm run test:serve
    • pnpm run test:serverPublish
    • pnpm run test:realPublish

High-level architecture

  • This repository is a thin TypeScript CLI/server layer over @wenyan-md/core/wrapper. Rendering, theme management, credential storage, and WeChat publishing are mostly delegated to the core package; repo-local logic mainly handles command wiring, input resolution, and the HTTP server wrapper.
  • src/cli.ts is the real entrypoint. It defines the publish, render, theme, serve, and credential commands with Commander, exports createProgram() for tests, and only calls program.parse() behind import.meta.main.
  • src/utils.ts centralizes content ingestion. Input precedence is inline argument > file/URL via --file > stdin. File input is normalized with getNormalizeFilePath() and returns absoluteDirPath so core rendering can resolve relative assets correctly.
  • src/commands/serve.ts implements the remote publish server used by wenyan publish --serve .... The flow is:
    1. /upload accepts Markdown, CSS, JSON, and image files into configDir/uploads
    2. clients reference uploaded assets via asset://...
    3. /publish loads an uploaded JSON render payload, rewrites asset:// references back to temp files, and calls publishToWechatDraft()
  • The project supports both direct local publish and client-server publish. Local mode calls WeChat APIs from the CLI process; server mode pushes render/publish work to a remote Express server to avoid local IP whitelist issues.

Key conventions

  • Keep the codebase in ESM TypeScript ("type": "module", moduleResolution: "NodeNext"). Prefer import/export, not CommonJS.
  • Preserve the current error-handling split:
    • CLI commands should go through the shared runCommandWrapper() pattern and exit with code 1 on failure.
    • Server routes should throw AppError for expected client errors so the shared JSON error shape stays { code: -1, desc }.
  • Preserve user-facing Chinese success/error messages unless there is a strong reason to change them. Tests assert on specific Chinese output and error text.
  • When adding input-related behavior, keep the existing precedence rules and do not break stdin-based usage for CI/CD pipelines.
  • Server uploads are temporary and live under configDir/uploads with a 10-minute TTL cleanup job. Features that rely on uploaded files should fit that lifecycle instead of introducing permanent storage here.
  • Publishing assumes Wenyan article metadata conventions from the README: Markdown frontmatter should provide at least title, with optional cover, author, and source_url. WeChat publishing also depends on WECHAT_APP_ID and WECHAT_APP_SECRET unless credentials are managed through the CLI/server credential flow.
  • Tests use the native Node test runner (node:test) plus node:assert/strict and mock. Follow the existing style instead of introducing Jest/Vitest.

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.