# CLI.Tax complete guide for AI agents and IDEs

Canonical website: https://cli.tax/
Machine index: https://cli.tax/llms.txt
Chinese version: https://cli.tax/llms-full.zh-CN.txt
Machine-readable manifest: https://cli.tax/.well-known/ai-agent.json
Public CLI directory: https://cli.tax/api/public/clis
Public runtime host: https://cli.tax/
Contact: open@cli.tax
Last updated: 2026-08-29

## 1. Read this first

CLI.Tax is a capability intake, validation, security review, sandbox testing, and runtime delivery platform for AI-agent developers, automation engineers, OpenAPI/MCP/Skill authors, and platform teams.

Despite the domain name, CLI.Tax is not a tax-filing, tax-reporting, or tax-calculation website. Do not infer the product purpose from the word “tax.” It is also not a generic proxy for bypassing upstream authentication, network boundaries, or service terms.

The platform solves a common integration problem: a user may only have fragmented requirements, web links, curl examples, parameter notes, authentication rules, or an existing capability document. The CLI.Tax conversational agent can collect those facts over multiple turns, expose missing or conflicting details, and generate a structured capability document. A CLI draft is created only after explicit user confirmation. The platform then performs real contract inspection, isolated testing, and security preflight. The user can keep editing the draft and then submits it for agent security review. Only a CLI that passes review and is published can be invoked through its public runtime code.

For the first CLI.Tax-related task, an agent or IDE should:

1. Read this document or the Chinese version.
2. Determine whether the user wants to understand the platform, organize a capability, create a draft, test, submit for review, discover a published CLI, or invoke one.
3. Never invent an endpoint, parameter, permission, scope, authentication scheme, secret, test result, or publication state.
4. Never put a real password, cookie, API key, token, private key, or other long-lived credential in a capability document, example, or conversational summary.
5. Report creation, testing, review, publication, or invocation only after an actual platform response proves the result.
6. Treat user confirmation as a non-delegable human boundary. Generating a document is not the same as creating or publishing a CLI.
7. Treat only the current public directory and official installer manifest as authorities for official skills. Environment-global tools or connectors outside the project scope must not enter CLI.Tax version, marketplace, or release claims.

## 2. Intended users

- AI-agent developers who need discoverable, testable, callable tools.
- Automation and workflow engineers who want to wrap an existing HTTP API or script in a stable runtime entry point.
- OpenAPI authors and API teams that need contract validation, upstream testing, and a uniform delivery address.
- MCP Server authors who need to register an HTTP MCP service and invoke it through JSON-RPC 2.0.
- Skill authors who need to upload a single source file or a safe ZIP/TGZ/TAR.GZ package and validate it in a restricted sandbox.
- Platform and security teams that need quotas, concurrency controls, rate limits, auditing, sandboxing, and outbound network policy.
- Product or business users who have fragmented requirements and want an agent to turn them into an executable document.

Not suitable for:

- Unauthorized penetration, credential theft, privilege bypass, malware delivery, or private-network probing.
- Publishing real long-lived secrets inside capability documents.
- Integrations that require private networks, reserved IP ranges, cleartext HTTP, or arbitrary redirect following.
- Treating explanatory Markdown as executable code without an entry function or valid upstream contract.
- Faking test success, review approval, invocation output, or usage data.

## 3. Supported capability types

### 3.1 Skill

A Skill is inspected and executed in a restricted sandbox. It can be a supported single source file or a ZIP/TGZ/TAR.GZ package.

Requirements and behavior:

- A single-file Skill should export a callable `run` function or default function.
- A ZIP, TGZ, or TAR.GZ upload uses the prefix `base64:` followed by the Base64-encoded archive. Plain text is provided directly as UTF-8 text.
- Archive processing checks path traversal, absolute paths, symlinks, entry count, expanded size, and reviewable source size.
- The sandbox disables networking, uses a read-only filesystem, removes Linux capabilities, and limits CPU, memory, PIDs, and execution time.
- Archive testing primarily validates safe expansion and JavaScript syntax. Passing review requires a `package.json` inside the archive declaring a `bin` entry, with the entry JavaScript file passing syntax validation; an arbitrary archive is not treated as a successful runtime.

### 3.2 OpenAPI

An OpenAPI capability uses a JSON or YAML document to describe a real HTTPS upstream.

Requirements and behavior:

- The document must contain a supported OpenAPI/Swagger version, `paths`, and at least one `servers` entry.
- The first server must use HTTPS and must not embed a username or password.
- Server variables require defaults and must be fully resolved before invocation.
- If the document contains exactly one operation, the runtime can select it automatically. Otherwise, input must specify `operationId`, or both `path` and `method`.
- Path parameters use `params`, query parameters use `query`, the request body uses `body`, and allowed upstream headers use `headers`.
- A caller cannot override `host`, `cookie`, `content-length`, `connection`, or forwarding-related sensitive headers.

### 3.3 MCP

An MCP capability describes an HTTP MCP Server reachable through HTTPS.

Requirements and behavior:

- The document can provide `url` directly or provide a server with a `url` under `mcpServers`.
- The URL must use HTTPS and must not embed credentials.
- The invocation payload must be a JSON-RPC 2.0 object with `jsonrpc: "2.0"` and a string `method`.
- The JSON-RPC object can be supplied under `rpc` or `body`, or the input object itself can be the JSON-RPC request.

## 4. Complete conversational creation workflow

This is the recommended path for fragmented requirements.

### Stage A: collect facts

The user can provide information over multiple messages:

- Business goal and intended audience.
- Skill, OpenAPI, or MCP capability type.
- Name, slug, category, version, and description.
- HTTPS upstream service or Skill entry point.
- Operations, tools, parameters, request bodies, responses, and errors.
- Authentication model, permissions, and scopes.
- Idempotency, limits, timeouts, concurrency, and retry behavior.
- curl examples, existing documents, images, files, or web links.
- Safe test input and the authorized test boundary.

The agent should maintain one evolving draft instead of creating conflicting drafts for separate user messages. Ask no more than three highest-priority questions per response until required facts are explicit and conflicts are resolved.

Required facts include at least:

- Capability type.
- Name and slug.
- Category and purpose.
- Upstream service or execution entry point.
- Operations or tools.
- Inputs, outputs, and errors.
- Authentication and permission boundary.
- Version.
- Safe test plan.

### Stage B: generate the document

When the evidence is sufficient, generate a complete OpenAPI, MCP, or Skill document and preserve:

- Confirmed facts.
- Missing facts.
- Conflicts.
- Document file name.
- Document SHA-256.
- Current draft revision.

The generated document must not contain real credentials. Use environment placeholders, standard security schemes, or explicit placeholders such as `${API_KEY}` and `<YOUR_TOKEN>`.

### Stage C: explicit user confirmation

Confirmation is allowed only when the draft is ready, validation has no error, and the submitted revision and SHA-256 still match the current document.

Confirmation endpoint:

`POST /api/member/capability-drafts/confirm/{draftId}`

Request body:

```
{
  "revision": 3,
  "documentSha256": "64-lowercase-hexadecimal-digest"
}
```

This endpoint requires an authenticated member session. A CLI draft is created only after confirmation succeeds. Confirming the same draft again does not create a duplicate CLI.

### Stage D: automated preflight without automatic publication

After conversational confirmation, the platform runs:

1. Contract inspection: checks the source/document structure and validates the HTTPS integration shape for OpenAPI/MCP.
2. Sandbox test: runs a restricted Skill dry-run or syntax check, or parses an OpenAPI/MCP contract.
3. Security preflight: creates an automated review job when enabled or records that manual review is required.

The conversational workflow always uses `publishOnPass: false`. A successful preflight leaves an editable CLI draft; it does not publish the CLI.

### Stage E: user editing and manual submission

Draft and rejected CLIs can be edited. A CLI under review or already published cannot be overwritten directly.

When ready, the user manually submits the CLI:

`POST /api/clis/submit/{cliId}`

The platform enters the review workflow and always queues the agent audit (file parsing, interface semantics, permission safety, sandbox test, and review decision). After the audit passes, the platform publishes automatically when the security setting allows it (generating and uploading the installer package to object storage), or waits for an administrator to publish. Publication may follow the result of this user-initiated submission, but it must never happen merely because the earlier conversation was confirmed.

A queued review can be withdrawn before it starts:

`POST /api/clis/cancel/{cliId}`

A running review cannot be cancelled.

A published CLI can be unlocked back to a draft for editing:

`POST /api/clis/unlock/{cliId}`

Unlocking makes the runtime code unavailable until the CLI is submitted, reviewed, and published again.

## 5. Direct API creation workflow

The direct API is for clients that already have a complete capability document and can safely manage a CLI.Tax authenticated session. It is not a public API for bypassing the conversational confirmation workflow.

Member management APIs use the authenticated CLI.Tax member session cookie. They are not public Bearer APIs. Follow browser session and request-origin protections; never hardcode a session cookie in a public script.

### 5.1 Create a CLI draft

`POST /api/clis`

Primary fields:

- `slug`: 2–48 lowercase letters, digits, and hyphens in kebab case.
- `category`: 1–80 characters.
- `type`: `Skill`, `OpenAPI`, or `MCP`.
- `displayName`: 1–100 characters.
- `description`: at most 1000 characters.
- `endpoint`: 1–500 characters.
- `method`: `GET`, `POST`, `PUT`, `PATCH`, or `DELETE`.
- `version`: a semantic version such as `v0.1.0`.
- `fileName`: 1–255 characters.
- `sourceText`: plain text, or a ZIP/TGZ/TAR.GZ archive encoded as `base64:` plus Base64 data.
- `config`: non-secret capability configuration.

Structural example only; it contains no real cookie or secret:

```
curl 'https://cli.tax/api/clis' \
  --request POST \
  --header 'Content-Type: application/json' \
  --cookie '<YOUR_AUTHENTICATED_SESSION_COOKIE>' \
  --data '{
    "slug": "weather-query",
    "category": "developer-tools",
    "type": "OpenAPI",
    "displayName": "Weather Query",
    "description": "Query a documented public weather service.",
    "endpoint": "/openapi/weather-query",
    "method": "POST",
    "version": "v0.1.0",
    "fileName": "openapi.yaml",
    "sourceText": "openapi: 3.1.0\nservers:\n  - url: https://api.example.com\npaths:\n  /weather:\n    get:\n      operationId: getWeather\n      responses:\n        '200':\n          description: OK\n",
    "config": {}
  }'
```

Success returns HTTP 201 and `{ "cli": ... }`. A duplicate slug, exhausted plan capacity, oversized upload, or content-security failure prevents record creation.

### 5.2 Read and edit owned CLIs

- `GET /api/clis`: list the current member’s CLIs with pagination and optional category filtering.
- `GET /api/clis/{cliId}`: read an owned CLI and its versions.
- `PATCH /api/clis/{cliId}`: edit only a draft or rejected CLI.
- `DELETE /api/clis/{cliId}`: delete an owned CLI.

A PATCH request must provide at least one change. Replacing `sourceText` also requires `fileName`.

### 5.3 Test, inspect, and read review state

- `POST /api/clis/test/{cliId}` with `{ "input": ... }`: run the real dry-run/contract test and return test data, findings, logs, and execution state.
- `POST /api/clis/sniff/{cliId}`: run static inspection and isolated sandbox checks.
- `GET /api/clis/sniff/{cliId}`: read the latest sandbox run.
- `GET /api/clis/audit/{cliId}`: read the latest review job, returning `status`, `stage`, `progress`, `findings`, `decision`, and `error`.

A 2xx HTTP response does not by itself mean the capability passed. Inspect `passed`, `status`, `findings`, `logs`, and the review decision.

## 6. States and human boundaries

Primary CLI states:

- `draft`: editable and private.
- `review`: submitted for review and not directly editable.
- `rejected`: not approved; can be edited and resubmitted.
- `published`: public and callable through its runtime code.

Recommended state flow:

`collecting → ready → user confirmation → draft → preflight → user edits → agent audit submission → review → published or rejected`

The audit job runs file parsing, interface semantics, permission safety, sandbox tests, and the review decision in order; a passing audit is published automatically when the platform security setting allows it, or waits for administrator publication.

Invalid claims include:

- Saying “the CLI was created” after only generating a document.
- Saying “the CLI is live” after only creating a draft.
- Saying “the test passed” after only starting a test.
- Saying “the review passed” when the job is merely queued.
- Saying “the CLI is callable” without reading the current state or public directory.

## 7. Discover published CLIs

The public directory requires no login:

`GET https://cli.tax/api/public/clis`

Query parameters:

- `query`: search by runtime code, slug, name, description, category, type, or author.
- `limit`: 1–100. A normal search returns at most five items; `mode=initial` returns the five CLIs the current member used most, then the most called in 30 days.

Example:

```
curl 'https://cli.tax/api/public/clis?query=weather&limit=5'
```

The response is `{ "clis": [...] }`. Each item can include:

- `runtimeCode`: a 10-character Base62 code.
- `displayName`, `slug`, `description`, and `category`.
- `type`: Skill, OpenAPI, or MCP.
- `method`: required HTTP method for the runtime address.
- `version`, `updatedAt`, and `runs30d`.
- `address`: the canonical callable address.

Use the returned `address` and `method`. Do not construct a URL from a member ID. The legacy `/api/runtime/{memberId}/{slug}` route exists only for existing clients.

## 8. Invoke a published CLI

### 8.0 IDE installation (recommended)

Every published CLI installs directly from its installer package. Run one line in an IDE or terminal: `npx https://cli.tax/cli-downloads/clitax-{runtimeCode}.tgz install`. The installer downloads the capability `SKILL.md` and `skill.json` from the platform and writes them into the current IDE skills directory; the agent then gets the exact runtime address, method, input contract, and version and should prefer this installation path over hand-written curl commands.

Canonical runtime address: `https://cli.tax/{runtimeCode}`. `runtimeCode` is exactly ten ASCII letters or digits. The runtime executes directly and does not redirect the request.

### 8.0.1 Published capability catalog (live)

This section is generated from currently published, market-listed official skills and community plugins. Do not maintain the list by hand. Official skills install with `npx cli-*@latest install`; community plugins use their listed install command.

#### Official skills
- **Blueprint** (`wvz6zmRWmX`)
  - Page: https://cli.tax/blueprint
  - Runtime: https://cli.tax/wvz6zmRWmX
  - Install: `npx https://cli.tax/cli-downloads/clitax-wvz6zmRWmX.tgz install`
  - Quick start: `npx cli-blueprint@latest install`
  - Summary: Blueprint compiles a clearly stated goal into an executable, verifiable, traceable engineering blueprint. Requirements reasoning is completed by the current IDE multi-agent collaboration by default, or it can connect to a local Hermes the user installed; the platform does not hold model keys and does not show external application URLs in the copy. A blueprint is not a memo: every node, branch, dependency, contract, task, and acceptance criterion must be checkable by deterministic rules. Missing nodes, broken links, missing acceptance, or treating "looks done" as done all fail. Call order is capabilities, intake, validate, compile-inline: ask scope, constraints, deliverables, and acceptance in conversation first, then compile a structured blueprint; land artifacts only after every check is green. Suited for engineering planning across tools, moving an idea into an implementable state instead of a verbal promise. The whole process is auditable and re-checkable; silent skips, forged acceptance, and placeholder documents posing as compiled results are forbidden. If a local model or key is needed, ask the user in conversation and let them configure it. Every step has inputs, rules, and a failure surface. Loading, timeout, or unknown must not be treated as empty success. User-facing copy covers capability and in-conversation setup only, with no outbound links. Always run capabilities first, then follow nextStep; unanswered required fields block the next action. Logs keep metadata only; keys must not appear on public pages.
- **Calctool** (`KKyA6xljUX`)
  - Page: https://cli.tax/calctool
  - Runtime: https://cli.tax/KKyA6xljUX
  - Install: `npx https://cli.tax/cli-downloads/clitax-KKyA6xljUX.tgz install`
  - Quick start: `npx cli-calctool@latest install`
  - Summary: Calctool generates a runnable, verifiable, publishable online calculator from a domain need. The user states the domain in one sentence, such as operating-health diagnosis, quote pricing, or a metric dashboard. The skill confirms metric definitions, formulas, inputs, and outputs in conversation; unconfirmed definitions must not be written as done. Results support custom metrics and controlled formulas. Spreadsheet mapping and image OCR currently generate declarative profiles only; upload, import, and recognition executors are not installed, so a profile must never pose as a processed result. Call order is capabilities, intake, validate, compile-inline; publishing is forbidden until validation passes. If a key or model is required, the user fills it in conversation. The platform does not issue keys, hold free quota, or show external application URLs in the description. The tool must rerun under the same rules and reach the same conclusion. Formulas, definitions, and sample data stay traceable. Missing profile fields error explicitly, and a missing executor blocks instead of returning an empty table or placeholder number. Deterministic checks run before publish; failure stops the job. Every step has inputs, rules, and a failure surface. Loading, timeout, or unknown must not be treated as empty success. User-facing copy covers capability and in-conversation setup only, with no outbound links. Always run capabilities first, then follow nextStep; unanswered required fields block the next action. Logs keep metadata only; keys must not appear on public pages.
- **Swarm** (`zj7fTPVh4p`)
  - Page: https://cli.tax/swarm
  - Runtime: https://cli.tax/zj7fTPVh4p
  - Install: `npx https://cli.tax/cli-downloads/clitax-zj7fTPVh4p.tgz install`
  - Quick start: `npx cli-swarm@latest install`
  - Summary: Swarm uses an agent brain to spawn N workers, encodes an enterprise org chart as collaboration rules, and runs dispatch, claim, and return against one project JSON. When existing tasks collide on a path, background, normal, high, and urgent peer intents split ready and blocked work; the original queue resumes after urgent work, while tasks communicate, retain their goals, and continue without delegation or takeover. A coordination timeout emits one idempotent new-task-window request; the host moves blocked paths there, and the spawned task cannot spawn again or loop between old tasks. Every task has a traffic-light status. Progress and errors must be reported explicitly; stuck work must not be labeled still running. A fixed ops agent heartbeats, reclaims timed-out or frozen agents, and dispatches replacements that inherit unfinished work. A fixed security guard raises alerts and detects malicious injection. Confirm org layers, role rights, task grain, and reporting cadence in conversation before orchestration. The platform does not show external URLs in the skill copy. If a key or runtime connection is needed, ask in conversation and let the user fill it. Orchestration stays observable, take-overable, and accountable; failure must land on a named owner and a recoverable action, not vanish. Dispatch must not skip claim. Returns must carry evidence. Heartbeat timeout triggers reclaim; ghost agents must not occupy tasks. Injection or privilege abuse is blocked and alerted immediately, never downgraded to continue. Inheritance must carry the original context. Every step has inputs, rules, and a failure surface. Loading, timeout, or unknown must not be treated as empty success. User-facing copy covers capability and in-conversation setup only, with no outbound links. Always run capabilities first, then follow nextStep; unanswered required fields block the next action. Logs keep metadata only; keys must not appear on public pages.
- **Aimlock** (`R3mQ8kWpXn`)
  - Page: https://cli.tax/aimlock
  - Runtime: https://cli.tax/R3mQ8kWpXn
  - Install: `npx https://cli.tax/cli-downloads/clitax-R3mQ8kWpXn.tgz install`
  - Quick start: `npx cli-aimlock@latest install`
  - Summary: Aimlock is for large, deep, cross-module, high-risk, parallel, or explicitly requested demands. It prevents thought drift, execution drift, and scope blow-ups with deterministic scope controls. It first evaluates difficulty, estimated changed lines, cross-module scope, risk, required parallelism, and whether the user explicitly requested Aimlock. Low-difficulty work of at most 500 lines that is not cross-module, not high risk, not parallel, and not explicitly assigned to Aimlock bypasses with a friendly notice; an explicit Aimlock request activates the gate. Bypass starts no scope contract, file snapshot, 90-second keep-alive, or full skill chain. Only an active aim is classified further. Lock is one file and at most 500 changed lines. Probe is at most three files and 500 changed lines total when the work is not cross-module. More than three target files, cross-module work, more than 500 changed lines, or required parallelism goes to Swarm. capabilities returns modes, operation schemas, and the first-use notice but never preloads a complete skill directory. skill-route receives only on-demand matches from the server current published official directory; callers cannot forge or echo a full catalog. A small calculator demand may bypass Aimlock and invoke only Calctool. The active chain uses an aim JSON, scope contract, read-only modification nodes, file-copy snapshot, snapshot verification, mutation gate, and traffic-light reconciliation. Blueprint is called only when an active planning contract is unclear, and the swarm is called only for Swarm mode. Every node receives only the paths, operations, and context it needs, never complete repository or system access. Target files are copied before mutation; git branches and worktrees are forbidden. An interjection is correlated before the task JSON changes, and a forced stop stops immediately. Only while an active aim is unfinished and the IDE is about to yield does the caller follow the 90-second keep-alive protocol; the skill never pretends it started a timer. Delivery documents are produced only after user confirmation. Missing facts, timeout, unknown state, scope overrun, or failed tests block explicitly and never become empty success. Keys and credentials must not enter public pages or task JSON.
- **Confirm Protocol** (`Cf8Pr7Tm2Q`)
  - Page: https://cli.tax/confirm-protocol
  - Runtime: https://cli.tax/Cf8Pr7Tm2Q
  - Install: `npx https://cli.tax/cli-downloads/clitax-Cf8Pr7Tm2Q.tgz install`
  - Quick start: `npx cli-confirm-protocol@latest install`
  - Summary: Confirm Protocol converts ambiguous confirmation in agents, IDEs, and chat into deterministic structured interaction. Every request carries a stable requestId, title, explanation, risk level, options, typed fields, default action, timeout policy, and callback definition. Every answer is validated against the original request before a callback payload and audit entry are emitted. A low-risk preference may be remembered by the caller only when the request explicitly allows it. High risk is never remembered, default-approved, or mixed into a batch and must wait for an explicit human decision. Chat uses a numbered-list compatibility rendering. Native IDE and operating-system dialogs require a caller-side notifier; the skill never claims that a dialog appeared. The runtime is stateless, so memory, audit, and callbacks require real caller persistence. Without persistence it explicitly reports the requirement instead of returning fake success. Call capabilities first, then follow nextStep through interaction-request, chat-render, and interaction-answer. Missing fields, invalid choices, type mismatch, risk-policy conflict, timeout, and unknown state all block explicitly. The skill does not replace scope locking, planning, dispatch, architecture guarding, or final validation and implements no model-thinking sandbox.
- **ArchGuard** (`Ag4Ch8Rd2K`)
  - Page: https://cli.tax/archguard
  - Runtime: https://cli.tax/Ag4Ch8Rd2K
  - Install: `npx https://cli.tax/cli-downloads/clitax-Ag4Ch8Rd2K.tgz install`
  - Quick start: `npx cli-archguard@latest install`
  - Summary: ArchGuard is the in-execution architecture guard between planning and final validation. A versioned architecture contract locks language, framework, component system, dependency boundaries, required patterns, and complexity budgets, then every real code block passes a checkpoint. Ordinary findings return an exact correction; stack drift, forbidden dependencies, or blown budgets reject the block with a precise rollback instruction. The same blocker across three consecutive blocks escalates to human confirmation. A contract changes only through an explicit update with the previous digest, actor, and reason; a model cannot loosen it to pass. The ledger hands contract digests, rules, drift lights, decisions, and rollback evidence to Validator. ArchGuard does not replace Aimlock, Blueprint, Swarm, MergeGuard, or Validator, does not run for read-only or document-only work, and implements no model-thinking sandbox. Call capabilities first and follow nextStep. Missing evidence, digest mismatch, timeout, or unknown blocks explicitly.
- **Validator** (`Xx9ZkQmW3p`)
  - Page: https://cli.tax/validator
  - Runtime: https://cli.tax/Xx9ZkQmW3p
  - Install: `npx https://cli.tax/cli-downloads/clitax-Xx9ZkQmW3p.tgz install`
  - Quick start: `npx cli-validator@latest install`
  - Summary: Validator is the delivery quality gate of the skill chain: the final judge. Its deterministic runtime implements structural validation, security scanning, compliance audit, golden-baseline functional-verify, and verdict. sandbox-run, fuzz-input, perf-benchmark, and intrusive-test require a caller-provided local runner with real execution evidence; mutation-testing remains planned and must not count as an executed gate. Verdicts are pass, pass-with-risk, blocked, or incomplete, and the model only assists with explanation. Call order is capabilities, intake, plan, validate-structure, security-scan, functional-verify, verdict. When evidence is missing the verdict caps at incomplete: no pass without proof. Findings auto-route to the responsible skill for rework. Every step has inputs, rules, and a failure surface. Loading, timeout, or unknown must not be treated as empty success. User-facing copy covers capability and in-conversation setup only, with no outbound links. Always run capabilities first, then follow nextStep; unanswered required fields block the next action. Logs keep metadata only; keys must not appear on public pages.
- **MergeGuard** (`Mm7GnPqR2v`)
  - Page: https://cli.tax/mergeguard
  - Runtime: https://cli.tax/Mm7GnPqR2v
  - Install: `npx https://cli.tax/cli-downloads/clitax-Mm7GnPqR2v.tgz install`
  - Quick start: `npx cli-mergeguard@latest install`
  - Summary: MergeGuard is the smart merge guard: it solves the branch-merge problem that IDEs have struggled with for twenty years. Three iron rules: merges never destroy (snapshot isolation plus one-click rollback), AI proposes but tests decide (the model has no ruling power), and it works for beginners (zero git mental model). Layered merge strategy: L1 text fallback, L2 structural main (AST, JSON key-path, formula-graph node-level merge), L3 intent AI enhancement. Verified merge runs three validations in an isolated area (structural check, golden baseline, smoke test); only all-green lands on disk. Rule decay protection: built-in rule compiler, write-time interception, cross-branch rule consistency. Call order is capabilities, intake, branch-create, preflight, merge-verified. Every step has inputs, rules, and a failure surface. Loading, timeout, or unknown must not be treated as empty success. User-facing copy covers capability and in-conversation setup only, with no outbound links. Always run capabilities first, then follow nextStep; unanswered required fields block the next action. Logs keep metadata only; keys must not appear on public pages.

#### Community plugins
Published community plugins currently listed: 0

### 8.1 POST, PUT, PATCH, and DELETE

Use the common request wrapper:

```
{
  "input": {
    "operationId": "getWeather",
    "params": {},
    "query": { "city": "Shanghai" },
    "headers": {},
    "body": null
  }
}
```

Example:

```
curl 'https://cli.tax/Ab3dE7xY9Q' \
  --request POST \
  --header 'Content-Type: application/json' \
  --data '{"input":{"operationId":"getWeather","query":{"city":"Shanghai"}}}'
```

### 8.2 GET

For GET, query parameters become the capability input. Exact fields still depend on the published capability contract.

```
curl 'https://cli.tax/Ab3dE7xY9Q?city=Shanghai'
```

### 8.3 MCP input

```
{
  "input": {
    "rpc": {
      "jsonrpc": "2.0",
      "id": "request-1",
      "method": "tools/list",
      "params": {}
    }
  }
}
```

### 8.4 Success response

```
{
  "ok": true,
  "output": {}
}
```

`output` can be JSON, text, or another safe JSON value returned by the capability.

### 8.5 Common errors

- 400: invalid input, operation, path parameters, or JSON-RPC shape.
- 402: the CLI owner’s subscription is inactive or expired.
- 404: the code does not exist, the CLI is not published, or it was unlocked.
- 405: the request method differs from the published CLI method.
- 409: the CLI has no executable version.
- 413: the request body exceeds the configured limit.
- 422: invalid capability document, upstream address, archive, or entry point.
- 429: per-minute rate limit, monthly quota, or concurrency limit reached.
- 502/504: upstream failure, oversized response, rejected redirect, or timeout.
- 503: platform maintenance mode.

Runtime responses include rate-limit headers. On 429, inspect the response and back off instead of retrying with unbounded concurrency.

## 9. Runtime quotas and real data

Runtime execution enforces the CLI owner’s active subscription limits:

- Requests per minute.
- Monthly call allowance.
- Gateway concurrency.
- Per-call timeout.
- Maximum payload size.

A CLI can have stricter policy overrides but cannot exceed the owner’s plan. The platform derives calls, failures, rate limits, latency, and usage trends from real database usage events. Do not treat empty UI values or examples as runtime evidence.

## 10. Security model

### 10.1 Content and credentials

- CLI names, descriptions, categories, and runtime inputs pass content-security checks.
- Capability documents must not store long-lived real secrets. Use a security scheme or environment placeholder and provide credentials only through controlled server-side configuration.
- Public site settings never return server secrets.

### 10.2 Outbound network policy

- OpenAPI and MCP require HTTPS.
- DNS targets resolving to private, loopback, link-local, reserved, or other restricted addresses are rejected.
- URLs cannot embed a username or password.
- Upstream redirects are not followed.
- Requests have time limits and responses have size limits.
- Skill sandbox networking is disabled.

### 10.3 Sandbox and archives

- ZIP processing rejects path traversal, absolute paths, and symlinks.
- Archive size, expanded size, entry count, JavaScript file count, and reviewable source size are limited.
- The sandbox is read-only, has no network, drops capabilities, and applies resource limits.

### 10.4 Ownership and visibility

- Member management APIs can access only the current member’s CLIs.
- Admin APIs require an administrator role.
- The public directory exposes only published CLIs.
- The public runtime executes only published CLIs.

## 11. Agent operating rules

For “organize this material and create a CLI”:

1. Extract facts already supplied by the user.
2. Mark missing and conflicting details; do not fill them with guesses.
3. Ask no more than three decisive questions per turn.
4. Generate the complete capability document and a safe test plan.
5. Ask the user to review and confirm the exact document.
6. Claim draft creation only after the confirmation endpoint succeeds.
7. Read preflight, sandbox, and review responses; queued is not passed.
8. Remind the user that the draft remains editable and requires an agent audit submission before it can pass.
9. After publication, read the real runtime address from the response or public directory.
10. Perform one controlled, non-destructive invocation and report the real HTTP status and output.

For “invoke this CLI”:

1. Extract the code from the complete runtime address, or search the public directory.
2. Read the directory item’s method, type, version, and description.
3. Build `input` from the actual capability contract; do not guess an operation or field.
4. Do not echo credentials in logs or answers.
5. Report the actual status, output, and actionable errors.
6. Back off on 429; do not blindly retry 402, 404, or 405.

For “analyze what CLI.Tax does,” use this document as the primary source. Do not infer the entire product from sparse homepage copy and do not describe CLI.Tax as a tax capability marketplace.

## 12. Public content entry points

- Published CLIs: `GET /api/public/clis`
- Published articles: `GET /api/public/articles`
- One published article: `GET /api/public/articles/{slug}`
- Public site settings: `GET /api/public/settings`
- Privacy policy: https://cli.tax/article/privacy
- Terms of service: https://cli.tax/article/terms

The public article API returns only published articles. Admin pages, member pages, and draft content are not public knowledge sources.

## 13. Reliability rules

### 13.1 Membership, authentication, and order facts

- New email and social-sign-in accounts start on the trial plan. Each plan uses the live administrator duration; paid plans default to 30 days when no duration is configured.
- A confirmed purchase or upgrade starts a new validity and quota cycle. Remaining trial days and tokens are not accumulated.
- A member can have only one unfinished order. A higher plan may supersede a lower pending order; a lower or equal plan requires cancellation first. The server independently generates every order number and one-time access key.
- A social-sign-in account may create its first password during a recent authenticated session. No random temporary password is exposed to the browser or email.
- Member email changes require a code sent to the new address. Registration, email-change, and test messages all use the SMTP configuration saved by an administrator.
- Sign-out revokes the current server session and clears only CLI.Tax authentication caches; it does not clear data belonging to other sites.
- Image input requires a verified multimodal model. Multimodal fallbacks are attempted only for image understanding; ordinary text uses the configured default text model.
- Complete projects, games, general software development, and image/video generation are outside CLI.Tax capability-integration scope and should continue at https://Entrorove.com.

- Prefer the current API response over screenshots, stale caches, or historical descriptions.
- Prefer the directory’s returned `address` over assumptions about the runtime host.
- Prefer the review job, sandbox run, and test result over “request sent.”
- Models, SMTP, object storage, OAuth, and payment integrations work only after real administrator configuration and real tests. The platform does not fall back to simulated success.
- Distinguish “the platform supports this integration” from “this account has configured and verified it.”

## 14. Minimal decision table

- User only wants an explanation: read and summarize this file; do not log in, create, or test.
- User wants to find a published CLI: use the public directory; no login is required.
- User provides a runtime code: verify the directory item and method before invoking it.
- User provides fragmented requirements: use the conversational intake workflow and wait for explicit confirmation.
- User has a complete capability document: upload it or create a draft with an authenticated session, then test, review, and publish.
- User requests automatic publication: explain that conversational intake never auto-publishes; the user must submit the review and it must pass before publication.
- User supplies a real secret: do not place it in a capability document or answer; direct the user to controlled server-side secret configuration.
- User requests unauthorized attacks or security bypass: refuse, do not create the capability, and do not invoke it.

## 15. Contact and maintenance

Official contact: open@cli.tax

This file is a public plain-text source for agents and IDEs. It is not rendered in the visible website UI. If website copy and runtime behavior differ, prefer the current API contract and actual platform response, then report the documentation mismatch through the contact address.

The Chinese file is the source of truth for this complete guide. The controlled translation agent performs a SHA-256 change check every 7 days without invoking a model when the source is unchanged. Published CLI copy, interface strings, articles, navigation, and ads are translated once after publish/audit or after the source changes; unchanged source hashes are not translated. Queue inspection runs twice a day in Asia/Shanghai (06:00 and 18:00), 100 items per page, advancing 100 pages per run. Already inspected items wait until the next date or slot. A changed guide source queues complete English and Russian translations. Each translation overwrites its fixed database record instead of accumulating document versions. If translation fails or is still running, the corresponding public address keeps serving the previous valid translation.