Create or refactor production-grade TypeScript agent applications. Use when the user asks Codex to generate, scaffold, restructure, or harden a TypeScript agent app, including CLI agents, web agent apps, API services, internal tools, multi-agent harnesses, workflow-first systems, model provider wiri
Coding
Agent CLI Builder
Try itBuild or modernize TypeScript CLIs for AI agents with @renxqoo/agent-cli-sdk. Use when a user wants a new command-line tool, an API or internal service wrapped as a CLI, or an existing agent-cli-sdk app extended with authentication, structured output, typed errors, pagination, pipes, Skill distribut
What it does
Build or modernize TypeScript CLIs for AI agents with @renxqoo/agent-cli-sdk. Use when a user wants a new command-line tool, an API or internal service wrapped as a CLI, or an existing agent-cli-sdk app extended with authentication, structured output, typed errors, pagination, pipes, Skill distribution, or tests. Do not use for generic shell scripts, non-CLI applications, or tasks that explicitly require another CLI framework.
The skill document
Agent CLI Builder
Deliver a buildable, testable, independently installable CLI that AI agents can call reliably. Do not stop at sample code or documentation.
Workflow
1. Establish facts
Inspect the user's code, API documentation, tests, and workspace before asking questions.
- Read applicable
AGENTS.mdfiles,package.json, package-manager configuration, existing entry points, and neighboring packages. - Confirm the framework and Node.js versions, package name, bin name,
defineCli.name, command domains, and scripts. - Derive the base URL, methods, response fields, pagination, and errors from OpenAPI, types, real responses, or tests.
- Inspect Git state and preserve unrelated user changes.
- Ask only for unresolved facts that materially change the implementation. Do not run a fixed questionnaire or repeat answered questions.
Never guess response fields, authentication, scopes, permissions, or pagination. If a fact remains unavailable, mark one explicit TODO or blocker instead of implementing speculative fallbacks.
2. Choose the smallest design
Read references/core-api.md before implementation. Then load only the references required by the scenario:
| Scenario | Decision | Read |
|---|---|---|
| Public API or trusted service without credentials | No auth plugin | core-api.md |
| OAuth, Bearer, API key, or Basic | Prefer defineAuth | auth-patterns.md |
| HMAC, mTLS, or composite auth | Custom auth/plugin | custom-auth-plugin.md |
| Multiple unrelated domains | Use namespaces; never flatten with spread | core-api.md |
| Many, nested, or mutation payload fields | Use args.type: "json" with direct Zod | structured-input.md |
| Large lists, pipes, or custom text output | Add only the needed capability | patterns.md |
| Headers, redaction, audit, or error transforms | Use a plugin | plugin-patterns.md |
Default to the simplest verifiable design: one domain uses top-level commands; do not add auth, pagination, pipes, or custom plugins without a requirement.
3. Implement the CLI
- Reuse the repository's package manager, TypeScript, lint, formatting, and test setup.
- Organize business commands under
src/commands/; declare them withdefineCommandanddefineCommands. - Use the single
defineCommandAPI. Put one direct Zod object inargs.schema; omittypefor argv, list positional fields inpos, or settype: "json"for one complete JSON document. Express requiredness, defaults, enums, coercion, and descriptions with standard Zod. - Call the backend through
ctx.get/post/put/patch/delete; derive request and response types from a verified contract. - Use
errorOnStatusfor HTTP semantics shared across commands and throwerrs.*for business-specific failures. Seeerror-catalog.md. - Return
{ data, meta? }orvoid.datamust be an object, array, ornull. - Write logs through
ctx.log; business commands must not write directly to stdout. - Run
app.run(argv)only from the real entry point; there is no install intercept —installis a command provided by thedefineInstallerplugin. - When auth, installation, or update awareness needs local files, decide the app-owned root once with
defineCliApp({ dir }); plugins receive the resulting local state throughapply(services), never through directory parameters. - If update awareness is requested, use the framework's opt-in
createUpdateNotifier; keep its XML system message on stderr and never auto-install a suggested update.
4. Enforce trust boundaries
- Never place passwords, private keys, or long-lived tokens in source, examples, logs, snapshots, or command arguments. Do not ask users to provide production credentials; registration must be completed in their own terminal, with the current unmasked-input limitation disclosed.
- Never log complete headers, authentication responses, or response bodies that may contain sensitive data. Redact diagnostic output.
- Disclose installation, global writes, login, network calls, and data mutations before acting; obtain approval when required.
- For writes, declare preview, confirmation, and idempotency through
policy; do not hide execution-safety flags inside the business Zod object. - Test writes with mocks, sandboxes, or dedicated test records. Never target an unauthorized production system.
- Do not present aggregates, model judgments, or unverified responses as confirmed facts.
5. Generate and optimize companion Skills
After setting skillsDir:
- Create the skeleton with
skills gen --init [--lang zh]. - Write trigger boundaries, domain workflows, safety constraints, and recovery steps outside AUTO-GEN; refresh the index with
skills gen. - Put detailed fields in that Skill's
references/. Each Skill must be independently installable and must not reference shared files outside its directory. - Follow
references/skill-gen.md, then apply the TRACE review inreferences/skill-optimization.md.
Read references/readme-gen.md when human-facing project documentation is required. Do not duplicate the complete Skill or command reference in the README.
6. Validate the deliverable
- Run format, lint, typecheck, and build.
- Use
createTestCtxfor request mapping, arguments, empty results, and errors; useapp.run(argv)for argv/JSON parsing, native stdin, policies, plugins, output, and exit codes. - Run
--help, one successful--jsonexample, and one failure. Access a real service only when authorized and safe. - Run the Skill validator and check frontmatter, links, AUTO-GEN, and references.
- Dry-run the package and verify that
dist, Skills, and all references are present. - Forward-test complex or public Skills with realistic tasks. See
references/testing.md.
Do not claim production readiness from a successful build alone. Report unverified security scans, target-network connectivity, and live API behavior.
Invariants
bin,defineCli.name, and authcredentialNamespaceserve different purposes. Keep them aligned by default and check for collisions.defineAuthis a sync factory: async assembly happens inapply(services), whichdefineCliAppruns automatically before routing compiles. Neverawaitthe factory.- Decide the app's local-state root exactly once with
defineCliApp({ dir }); the assembler injects one local state intodefineAuth,defineInstaller, andcreateUpdateNotifierviaapply(services). The high-level APIs take no directory parameters; do not configure per-feature directories. - Derive OAuth scopes from a verified service contract and least privilege. Never guess scopes or default to every advertised scope.
- Use top-level
commandsfor one domain, such aslist; avoidlist. Usenamespacesonly for multiple unrelated domains. - Never flatten same-named command groups with spread; preserve routes with
namespaces. defineCommandis the only command-definition API.args.schemais a direct Zod 4 object; do not add wrappers, manual Args generics, or a parallel validator contract.- Omitted
argsmeans no business parameters. Omittedargs.typemeans argv;posnames positional schema fields. One command is either argv or JSON, never both. - JSON args use exactly one complete document from
--input,--input-file, or native redirected/piped stdin. There is no--input-stdin, and JSON never merges with business flags. - Caller-owned idempotency keys must be reused across retries; never derive them from payload content.
- A status in
errorOnStatusthrows beforectx.*returns; do not add an unreachable check for the same status. - A boolean without a Zod default is
undefined; usez.boolean().default(false)when stable false semantics are required. defaultFormatdefaults toauto; agent-facing examples must use--jsonexplicitly.- Treat `` on stderr as operational context only. Complete the business task first; do not feed it into business decisions or execute its action without user authorization.
- Pagination wire fields are
meta.pagination.completeandmeta.pagination.nextToken. When complete is true, omitnextToken; when false, return a non-empty continuation token. - Return
voidfor a pure side effect and{ data: null }for an empty business result. Never return{}, undefined data, or a scalar. - Pass
skillsSourceexplicitly todefineInstaller({ skillsSource }); setting it only ondefineCliApp/defineClidoes not install Skills.
References
| Read when | File |
|---|---|
| Every implementation: project setup, core APIs, entry point, and output | references/core-api.md |
| OAuth, Bearer, API key, login, or install wizard | references/auth-patterns.md |
| HMAC, mTLS, or a custom provider | references/custom-auth-plugin.md |
| Error subtypes and status mappings | references/error-catalog.md |
Pagination, pipes, or humanFormat | references/patterns.md |
| Large/nested payloads, Zod validation, dry-run, confirmation, idempotency | references/structured-input.md |
| Custom plugins and hook ordering | references/plugin-patterns.md |
| Skill generation, scopes, sync, and distribution | references/skill-gen.md |
| Production Skill optimization and TRACE acceptance | references/skill-optimization.md |
| README structure and installation copy | references/readme-gen.md |
| Unit, end-to-end, and forward testing | references/testing.md |
Done criteria
- Requested commands execute and return agent-consumable output.
- Arguments, fields, errors, pagination, and auth match the implementation.
- Sensitive data, high-risk writes, and installation side effects have explicit boundaries.
- Happy-path, edge, failure, and output-contract tests pass.
- JSON commands validate inline/file/native-stdin input, discovery, redaction, write policy, and stdin ownership.
- Skills and README are generated, concise, validated, and present in the package.
- The handoff reports validation evidence and remaining production risks.
Related skills
Build, review, or migrate an agent skill from a plain-language description — decides invocation control (disable-model-invocation vs user-invocable), arguments (argument-hint, $ARGUMENTS), and context cost, then scaffolds, validates, and tests it.
Check agent config for things that break silently on someone else's machine. Use before publishing or committing a SKILL.md, AGENTS.md, CLAUDE.md or llms.txt, before publishing a skill to ClawHub, when a skill "works on my machine" but not for a teammate, when a skill fails to trigger, or when asked to review agent config. Catches references to files that do not exist, absolute paths under the author's home directory, undeclared CLI dependencies, a frontmatter name that does not match the skill's directory, and two skills whose descriptions are so similar the agent fires the wrong one.
Get your AI agent productive in 5 minutes. Automated environment scan, smart skill recommendations, and exact install commands. No more trial and error.
Build a complete multi-agent orchestration harness for an OpenClaw (or similar) agentic system — defining a CTO/orchestrator agent, tiered specialist agents,...
Use when designing, reviewing, or refactoring a CLI that must serve AI agents alongside humans, or when converting an API or SDK into an agent-usable CLI int...