cli-self-check

The "new function rationality" self-check skill for te-cli. It solidifies the structured checks repeatedly used in manual code reviews into executable scripts + judgment rules.

When to Use

Merged new command domains (
```
src/commands/te-*
```
) or new commands
Added/modified skills under
```
skills/
```
Pre-release self-check, or evaluating whether the CLI functions of a branch are "fully implemented"

How to Run

bash

# Full scan (recommended for pre-release)
node self-check/scan.mjs

# Only check changed domains relative to a branch (recommended after merging/PR, focus on current changes)
node self-check/scan.mjs --since master

# Machine-readable, suitable for CI integration
node self-check/scan.mjs --json

Exit code: Returns

when P1 issues exist, otherwise

, which can be directly used for CI checks.

The script is pure Node, zero new dependencies, read-only and does not modify the repository. Judgment and repair are done by you (agent) based on the rules below—the script is responsible for "discovering", and you are responsible for "confirming + fixing".

Six Detection Dimensions

Dimension	Name	What to Check	Consequences of Missing
D1	Command Registration	Whether the new domain is registered in `src/index.ts` ; whether the MCP service has registered mapping	The command does not load at all; `buildMcpUrl` throws an error at runtime
D2	Domain ↔ Skill Pairing	Whether each business domain has a corresponding skill; tool commands should not have skills	The agent doesn't know how to use the new command
D3	Skill Document Coverage	Whether commands ↔ `references/*.md` are in one-to-one correspondence	The agent lacks command documents and is forced to guess parameters
D4	Skill Internal Consistency	Whether the CRITICAL rule "+cmd→cmd.md" matches the actual filename; whether links in SKILL.md are invalid	The agent reads empty documents according to the rules and guesses IDs/parameters randomly
D5	Document Synchronization	Whether README (Chinese/English) covers all services; version number vs CHANGELOG	Users follow the README and think the new function doesn't exist
D6	Engineering Robustness	Whether each domain has a verify script; whether it is connected to `tsc --noEmit`	No automatic interception for regression; type errors are only exposed during build

Severity and Handling Principles

🔴 P1 (Blocking)：Will cause command loading failure, or agent behavior errors (reading empty documents → random guessing). Must be fixed, CI should block.
🟡 P2 (Obvious deviation for users/agents)：Missing/outdated documents, invalid links. Should be fixed before release.
🟢 P3 (Engineering Robustness)：Gaps in verify/typecheck, inconsistent styles. Fix at an optional time, does not block release.
ℹ️ info：Confirmation items that comply with conventions (e.g., tool commands have no skills), no handling required.

Judgment + Repair Guidelines for Each Dimension

D1 Command Registration

"Domain not registered in src/index.ts": Add
```
import('./commands/<dir>/index.js')
```
to
```
loadCommands()
```
(business domains) or
```
registerXxxCommand()
```
(tool commands) in
```
src/index.ts
```
.
"MCP service not registered with mapping": Call
```
registerMcpMappings({ '<service>': { componentName, mappingPath } })
```
at the top of the domain
```
index.ts
```
that still uses MCP transport (refer to
```
te-community/index.ts
```
). The Analysis domain only allows Capability Gateway and should not register MCP mapping.
Note the difference between two types of "service": commander group name (e.g.,
```
engage
```
) ≠ MCP routing key (e.g.,
```
engage_config
```
). The script only checks the latter and only extracts literal parameters; variable parameters are not reported (prefer under-reporting over false positives).

D2 Domain ↔ Skill Pairing

Convention: Business domains are paired with skills, tool commands (interactive/operation and maintenance) are not. It is correct that
```
sync
```
,
```
model
```
,
```
auth
```
,
```
config
```
,
```
api
```
have no skills.
If a new business domain is added, register the mapping in
```
DOMAIN_TO_SKILL
```
at the top of
```
scan.mjs
```
; register new tool commands in
```
TOOL_DIRS
```
. Missing registration will be reported as P2, reminding you to supplement the mapping or confirm the classification.

D3 Skill Document Coverage

Judgment uses "normalization + inclusion" matching, which can recognize that
```
create-team.md
```
covers
```
+create
```
, so what is reported here is genuine missing documents.
Fix method: Add a
```
.md
```
file in
```
references/
```
of the corresponding skill, and add a link in the command list in SKILL.md.
Skills that adopt the "group/inline document" strategy (
```
ae-dataops
```
,
```
ae-kb
```
) are exempt from per-command checks in
```
GROUPED_DOC_SKILLS
```
—if a new skill also uses this strategy, add it to the list.

D4 Skill Internal Consistency (Most Prone to P1)

Rule Conflict: If the top of SKILL.md states "reference filename equals the command name (+cmd → references/cmd.md)", then every command must have a strictly identically named file. If the document for
```
+list
```
is named
```
list-teams.md
```
, the agent will try to read the non-existent
```
list.md
```
.
- Two Fix Methods (choose one): ① Rename the file to be strictly identical to the command (
```
list.md
```
  ) — recommended, as the rule is most self-consistent; ② Rewrite the top rule to "follow the links in the command list below" and delete the assertion that "filename = command name".
Invalid Links: The
```
references/xxx.md
```
links in SKILL.md point to non-existent files — supplement the files or fix the links.

D5 Document Synchronization

New domains/new commands should be synchronized to the command tables in
```
README.md
```
and
```
README.zh.md
```
.
The version number must have a corresponding entry in CHANGELOG.md during release.

D6 Engineering Robustness

It is recommended to add a
```
scripts/verify-te-<domain>.mjs
```
for new domains (refer to the existing
```
verify-te-analysis-tools.mjs
```
: traverse command source code and verify registration, flags, description and document contracts), and add a
```
verify:<domain>
```
script in
```
package.json
```
.
It is recommended to add
```
"typecheck": "tsc --noEmit"
```
to move type checking forward from build.

Maintain the Script

There are adjustable configurations at the top of

scan.mjs

, update as needed when adding modules:

```
DOMAIN_TO_SKILL
```
: Mapping from business domain directory → skill name
```
COMMAND_SKILL_OVERRIDES
```
: Mapping from command paths in the same command domain that are handled by overlay skills → skill name
```
TOOL_DIRS
```
: Tool command directories (exempt from skill checks)
```
GROUPED_DOC_SKILLS
```
: Skills that adopt the group/inline document strategy (exempt from per-command reference checks)

Judgment Philosophy: The script only reports clues that "are worth a human look", and confirmation and repair are done by the agent combined with the source code. When adding new detection dimensions, prioritize ensuring zero false positives — a false P1 is more harmful to tool credibility than under-reporting.

cli-self-check

NPX Install

Tags

SKILL.md Content (Chinese)

cli-self-check

When to Use

How to Run

Six Detection Dimensions

Severity and Handling Principles

Judgment + Repair Guidelines for Each Dimension

D1 Command Registration

D2 Domain ↔ Skill Pairing

D3 Skill Document Coverage

D4 Skill Internal Consistency (Most Prone to P1)

D5 Document Synchronization

D6 Engineering Robustness

Maintain the Script