Is cm-terminal-21382c safe to install?

SaferSkills independently audited cm-terminal-21382c (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.

CategoryWeightCategory scoreContribution

Securityprompt, exec, net, exfil, eval

35%

100

35.0 pts

Supply chainhash, typosquat, maintainer, lockfile

20%

100

20.0 pts

Maintenancestaleness, pinning, CI

15%

100

15.0 pts

TransparencySKILL.md, perms, README

15%

100

15.0 pts

Communityinstalls, verify, response

15%

100

15.0 pts

Findings & checks · 0 flagged

Securityscore 100 · 0 findings

✓—All security checks passedNo findings in this category for the latest scan.pass

Supply chainscore 100 · 0 findings

✓—All supply chain checks passedNo findings in this category for the latest scan.pass

Maintenancescore 100 · 0 findings

✓—All maintenance checks passedNo findings in this category for the latest scan.pass

Transparencyscore 100 · 0 findings

✓—All transparency checks passedNo findings in this category for the latest scan.pass

Communityscore 100 · 0 findings

✓—All community checks passedNo findings in this category for the latest scan.pass

The primary manifest — the file an agent reads to learn what this artifact does.

.amazonq/skills/cm-terminal/SKILL.md · 1 file

.amazonq/skills/cm-terminal/SKILL.md6.3 KB · Markdown

name: cm-terminal

description: Use when running ANY terminal command - enforces clear progress logging, output reading, and error-stop behavior so terminal processes are never left unchecked

Terminal Process Monitoring

Overview

Running commands without checking output is flying blind. Users MUST see what's happening at every step.

Core principle: Every command gets announced, monitored, and verified. No exceptions.

Violating the letter of this rule is violating the spirit of this rule.

The Iron Law

NO COMMAND RUNS WITHOUT READING ITS OUTPUT.
NO ERROR GOES UNREPORTED.
NO NEXT STEP WITHOUT PREVIOUS STEP CONFIRMED.

When to Use

ALWAYS when running terminal commands via run_command. This includes:

Build commands (npm run build, npm run dev)
Test commands (npx vitest run)
Install commands (npm install)
Deploy commands (npx wrangler pages deploy)
Git commands (git push, git commit)
Any script or CLI tool

The Protocol

Step 1: Announce Before Running

BEFORE calling `run_command`:

Update task_boundary TaskStatus to describe what you're about to run and why.

TaskStatus: "Running npm build to compile production bundle"
TaskStatus: "Installing dependencies with npm install"
TaskStatus: "Deploying to Cloudflare Pages"

Step 2: Set Appropriate Wait Time

Choose WaitMsBeforeAsync based on expected command duration:

Command Type	WaitMsBeforeAsync	Strategy
Quick (< 3s) — `git status`, `ls`, `cat`	3000-5000	Synchronous, read output directly
Medium (3-30s) — `npm install`, `build`	5000-10000	Wait for initial output, then poll
Long (> 30s) — `deploy`, `test suites`	2000-5000	Send to background, poll actively

Step 3: Read Output Immediately

After `run_command` returns:

If command completed synchronously → read output in the response
If command sent to background → call command_status immediately with WaitDurationSeconds: 10
NEVER proceed to next step without reading output

Step 4: Check for Errors

Scan output for error indicators:

ERROR PATTERNS TO DETECT:
- Exit code ≠ 0
- "error", "Error", "ERROR"
- "fail", "FAIL", "failed", "FAILED"
- "ENOENT", "EACCES", "EPERM"
- "not found", "No such file"
- "Cannot find module"
- "SyntaxError", "TypeError", "ReferenceError"
- "Build failed"
- "Command failed"
- "Permission denied"
- "FATAL"
- Stack traces (lines with "at " prefix)
- npm ERR!
- Warning patterns that indicate real problems

Step 4b: Compress Before Quoting

Before pasting stdout into TaskSummary or model context:

Command pattern	Rule
`git status`	Keep only changed entries + branch line + `(N changed)` count. Drop "use git add…" boilerplate.
`npm test` / `vitest` / `jest`	Keep failing tests + summary line. Drop `PASS` lines.
`npm run build` / `tsc`	Keep `error` / `warning` / final status. Drop incremental progress.
Any output	Collapse runs of ≥ 3 identical lines into `<line> … (× N)`.

Helper: src/utils/output-compress.ts — compressGitStatus, compressNpmTest, summarizeBuildLog, collapseRepeatedLines, compressFor(command, stdout).

Anti-pattern: Pasting full stdout (> 50 lines) into TaskSummary when only the failing portion matters. Compress first, then quote.

Step 5: Stop on Error

If ANY error is detected:

1. STOP — Do not run any more commands
2. IDENTIFY — Extract the exact error message and context
3. REPORT — Call notify_user with error if critical
4. FIX — Use cm-debugging if proceeding to fix

Step 6: Poll Long-Running Commands

For background commands (returned a CommandId):

Poll command_status every 10-15 seconds
After EACH poll, update task_boundary TaskStatus with latest output summary
Continue until command completes (status: "done")
Read final output and check for errors

Step 7: Confirm Success

Only after reading output AND confirming no errors:

Update task_boundary TaskSummary with the result:

TaskSummary: "Build completed successfully (0 errors, 0 warnings)"
TaskSummary: "All 519 tests passed"
TaskSummary: "Deployed to https://prms-4pv.pages.dev successfully"

Red Flags — STOP and Follow Protocol

If you catch yourself doing ANY of these:

Running a command without updating TaskStatus first
Calling run_command while previous command is still running
Skipping command_status for a background command
Proceeding to next step without reading output
Ignoring warnings or errors in output
Assuming a command succeeded without checking exit code
Running 3+ commands in parallel without monitoring each

ALL of these mean: STOP. Follow the protocol.

Anti-Patterns

DON'T	DO
Run and forget	Run and read output
Assume success	Verify success from output
Chain commands blindly	Verify each before next
Ignore warnings	Report warnings to user
Multiple commands without checking	Sequential with verification

Special Cases

Interactive Commands (dev servers, watch mode)

Start with WaitMsBeforeAsync: 3000-5000
Check initial output for startup success/failure
Look for "ready" / "listening on" / "compiled successfully" signals
Report the URL/port to user
Note the CommandId for future reference

Parallel Commands

If running multiple commands at once:

Track ALL CommandIds
Poll each one separately
If ANY fails → report which one failed

Piped/Chained Commands (`&&`, `|`)

The exit code reflects the LAST command in the chain
Read full output — errors from earlier commands may appear but the chain continues
Be extra careful with cd dir && npm run build — if cd fails, build won't run

Severity Levels

Level	Action	Example
🟢 Success	Update TaskSummary, proceed	"Build succeeded"
🟡 Warning	Report to user, ask if proceed	"Deprecated dependency"
🔴 Error	STOP immediately, notify_user or fix	"Build failed", "Test failed"
⚫ Fatal	STOP immediately, notify_user	"ENOENT", "Permission denied"

The Bottom Line

Every command tells a story through its output. READ the story. SHARE it with the user. STOP if the story is bad.

cm-terminal-21382c— agent skill

Is cm-terminal-21382c safe to install?

Terminal Process Monitoring

Overview

The Iron Law

When to Use

The Protocol

Step 1: Announce Before Running

Step 2: Set Appropriate Wait Time

Step 3: Read Output Immediately

Step 4: Check for Errors

Step 4b: Compress Before Quoting

Step 5: Stop on Error

Step 6: Poll Long-Running Commands

Step 7: Confirm Success

Red Flags — STOP and Follow Protocol

Anti-Patterns

Special Cases

Interactive Commands (dev servers, watch mode)

Parallel Commands

Piped/Chained Commands (`&&`, `|`)

Severity Levels

The Bottom Line

Audit the pieces. Scan the whole. Decide.

Is cm-terminal-21382c safe to install?

Terminal Process Monitoring

Overview

The Iron Law

When to Use

The Protocol

Step 1: Announce Before Running

Step 2: Set Appropriate Wait Time

Step 3: Read Output Immediately

Step 4: Check for Errors

Step 4b: Compress Before Quoting

Step 5: Stop on Error

Step 6: Poll Long-Running Commands

Step 7: Confirm Success

Red Flags — STOP and Follow Protocol

Anti-Patterns

Special Cases

Interactive Commands (dev servers, watch mode)

Parallel Commands

Piped/Chained Commands (&&, |)

Severity Levels

The Bottom Line

Audit the pieces. Scan the whole. Decide.

Piped/Chained Commands (`&&`, `|`)