cm-terminal

Name: cm-terminal
Author: tody-agent

47stars23forks

How to install cm-terminal?

tody-agent/codymaster/cm-terminal

$npx -y skills add tody-agent/codymaster --skill cm-terminal

Installs into the current project.

Summary

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

Files · 1

View on GitHub

SKILL.md

1	# Terminal Process Monitoring
2
3	## Overview
4
5	Running commands without checking output is flying blind. Users MUST see what's happening at every step.
6
7	Core principle: Every command gets announced, monitored, and verified. No exceptions.
8
9	Violating the letter of this rule is violating the spirit of this rule.
10
11	## The Iron Law
12
13	```
14	NO COMMAND RUNS WITHOUT READING ITS OUTPUT.
15	NO ERROR GOES UNREPORTED.
16	NO NEXT STEP WITHOUT PREVIOUS STEP CONFIRMED.
17	```
18
19	## When to Use
20
21	ALWAYS when running terminal commands via `run_command`. This includes:
22	- Build commands (`npm run build`, `npm run dev`)
23	- Test commands (`npx vitest run`)
24	- Install commands (`npm install`)
25	- Deploy commands (`npx wrangler pages deploy`)
26	- Git commands (`git push`, `git commit`)
27	- Any script or CLI tool
28
29	## The Protocol
30
31	### Step 1: Announce Before Running
32
33	BEFORE calling `run_command`:
34
35	Update `task_boundary` TaskStatus to describe what you're about to run and why.
36
37	```
38	TaskStatus: "Running npm build to compile production bundle"
39	TaskStatus: "Installing dependencies with npm install"
40	TaskStatus: "Deploying to Cloudflare Pages"
41	```
42
43	### Step 2: Set Appropriate Wait Time
44
45	Choose `WaitMsBeforeAsync` based on expected command duration:
46
47	\| Command Type \| WaitMsBeforeAsync \| Strategy \|
48	\|-------------\|-------------------\|----------\|
49	\| Quick (< 3s) — `git status`, `ls`, `cat` \| 3000-5000 \| Synchronous, read output directly \|
50	\| Medium (3-30s) — `npm install`, `build` \| 5000-10000 \| Wait for initial output, then poll \|
51	\| Long (> 30s) — `deploy`, `test suites` \| 2000-5000 \| Send to background, poll actively \|
52
53	### Step 3: Read Output Immediately
54
55	After `run_command` returns:
56
57	1. If command completed synchronously → read output in the response
58	2. If command sent to background → call `command_status` immediately with `WaitDurationSeconds: 10`
59	3. NEVER proceed to next step without reading output
60
61	### Step 4: Check for Errors
62
63	Scan output for error indicators:
64
65	```
66	ERROR PATTERNS TO DETECT:
67	- Exit code ≠ 0
68	- "error", "Error", "ERROR"
69	- "fail", "FAIL", "failed", "FAILED"
70	- "ENOENT", "EACCES", "EPERM"
71	- "not found", "No such file"
72	- "Cannot find module"
73	- "SyntaxError", "TypeError", "ReferenceError"
74	- "Build failed"
75	- "Command failed"
76	- "Permission denied"
77	- "FATAL"
78	- Stack traces (lines with "at " prefix)
79	- npm ERR!
80	- Warning patterns that indicate real problems
81	```
82
83	### Step 4b: Compress Before Quoting
84
85	Before pasting stdout into TaskSummary or model context:
86
87	\| Command pattern \| Rule \|
88	\|-----------------\|------\|
89	\| `git status` \| Keep only changed entries + branch line + `(N changed)` count. Drop "use git add…" boilerplate. \|
90	\| `npm test` / `vitest` / `jest` \| Keep failing tests + summary line. Drop `PASS` lines. \|
91	\| `npm run build` / `tsc` \| Keep `error` / `warning` / final status. Drop incremental progress. \|
92	\| Any output \| Collapse runs of ≥ 3 identical lines into `<line> … (× N)`. \|
93
94	Helper: `src/utils/output-compress.ts` — `compressGitStatus`, `compressNpmTest`, `summarizeBuildLog`, `collapseRepeatedLines`, `compressFor(command, stdout)`.
95
96	Anti-pattern: Pasting full stdout (> 50 lines) into TaskSummary when only the failing portion matters. Compress first, then quote.
97
98	### Step 5: Stop on Error
99
100	If ANY error is detected:
101
102	```
103	1. STOP — Do not run any more commands
104	2. IDENTIFY — Extract the exact error message and context
105	3. REPORT — Call notify_user with error if critical
106	4. FIX — Use cm-debugging if proceeding to fix
107	```
108
109	### Step 6: Poll Long-Running Commands
110
111	For background commands (returned a CommandId):
112
113	1. Poll `command_status` every 10-15 seconds
114	2. After EACH poll, update `task_boundary` TaskStatus with latest output summary
115	3. Continue until command completes (status: "done")
116	4. Read final output and check for errors
117
118	### Step 7: Confirm Success
119
120	Only after reading output AND confirming no errors:
121
122	Update `task_boundary` TaskSummary with the result:
123	```
124	TaskSummary: "Build completed successfully (0 errors, 0 warnings)"
125	TaskSummary: "All 519 tests passed"
126	TaskSummary: "Deployed to https://prms-4pv.pages.dev successfully"
127	```
128
129	## Red Flags — STOP and Follow Protocol
130
131	If you catch yourself doing ANY of these:
132
133	- Running a command without updating TaskStatus first
134	- Calling `run_command` while previous command is still running
135	- Skipping `command_status` for a background command
136	- Proceeding to next step without reading output
137	- Ignoring warnings or errors in output
138	- Assuming a command succeeded without checking exit code
139	- Running 3+ commands in parallel without monitoring each
140
141	ALL of these mean: STOP. Follow the protocol.
142
143	## Anti-Patterns
144
145	\| DON'T \| DO \|
146	\|-------\|-----\|
147	\| Run and forget \| Run and read output \|
148	\| Assume success \| Verify success from output \|
149	\| Chain commands blindly \| Verify each

People who liked this also viewed

6 picks

Type

lark-openapi-explorer飞书/Lark 原生 OpenAPI 探索：从官方文档库中挖掘未经 CLI 封装的原生 OpenAPI 接口。当用户的需求无法被现有 lark-* skill 或 lark-cli 已注册命令满足，需要查找并调用原生飞书 OpenAPI 时使用。SkillsJul 2026378k16k
lark-skill-maker创建 lark-cli 的自定义 Skill。当用户需要把飞书 API 操作封装成可复用的 Skill（包装原子 API 或编排多步流程）时使用。SkillsJul 2026377k16k
azure-cost-optimizationOfficial agent plugin providing skills and MCP server configurations for Azure scenarios.SkillsJul 2026209k1.3k
vercel-react-native-skillsVercel's official collection of agent skillsSkillsJul 2026172k29k
mcp-builderGuide for creating high-quality MCP (Model Context Protocol) servers that enable LLMs to interact with external services through well-designed tools. Use when building MCP servers to integrate externaSkillsJul 202693k163k
gws-sharedgws CLI: Shared patterns for authentication, global flags, and output formatting.SkillsJul 202653k30k

cm-terminal

47stars23forks

View on GitHub

How to install cm-terminal?

tody-agent/codymaster/cm-terminal

$npx -y skills add tody-agent/codymaster --skill cm-terminal

Installs into the current project.

Summary

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

Files · 1

View on GitHub

SKILL.md

1	# Terminal Process Monitoring
2
3	## Overview
4
5	Running commands without checking output is flying blind. Users MUST see what's happening at every step.
6
7	Core principle: Every command gets announced, monitored, and verified. No exceptions.
8
9	Violating the letter of this rule is violating the spirit of this rule.
10
11	## The Iron Law
12
13	```
14	NO COMMAND RUNS WITHOUT READING ITS OUTPUT.
15	NO ERROR GOES UNREPORTED.
16	NO NEXT STEP WITHOUT PREVIOUS STEP CONFIRMED.
17	```
18
19	## When to Use
20
21	ALWAYS when running terminal commands via `run_command`. This includes:
22	- Build commands (`npm run build`, `npm run dev`)
23	- Test commands (`npx vitest run`)
24	- Install commands (`npm install`)
25	- Deploy commands (`npx wrangler pages deploy`)
26	- Git commands (`git push`, `git commit`)
27	- Any script or CLI tool
28
29	## The Protocol
30
31	### Step 1: Announce Before Running
32
33	BEFORE calling `run_command`:
34
35	Update `task_boundary` TaskStatus to describe what you're about to run and why.
36
37	```
38	TaskStatus: "Running npm build to compile production bundle"
39	TaskStatus: "Installing dependencies with npm install"
40	TaskStatus: "Deploying to Cloudflare Pages"
41	```
42
43	### Step 2: Set Appropriate Wait Time
44
45	Choose `WaitMsBeforeAsync` based on expected command duration:
46
47	\| Command Type \| WaitMsBeforeAsync \| Strategy \|
48	\|-------------\|-------------------\|----------\|
49	\| Quick (< 3s) — `git status`, `ls`, `cat` \| 3000-5000 \| Synchronous, read output directly \|
50	\| Medium (3-30s) — `npm install`, `build` \| 5000-10000 \| Wait for initial output, then poll \|
51	\| Long (> 30s) — `deploy`, `test suites` \| 2000-5000 \| Send to background, poll actively \|
52
53	### Step 3: Read Output Immediately
54
55	After `run_command` returns:
56
57	1. If command completed synchronously → read output in the response
58	2. If command sent to background → call `command_status` immediately with `WaitDurationSeconds: 10`
59	3. NEVER proceed to next step without reading output
60
61	### Step 4: Check for Errors
62
63	Scan output for error indicators:
64
65	```
66	ERROR PATTERNS TO DETECT:
67	- Exit code ≠ 0
68	- "error", "Error", "ERROR"
69	- "fail", "FAIL", "failed", "FAILED"
70	- "ENOENT", "EACCES", "EPERM"
71	- "not found", "No such file"
72	- "Cannot find module"
73	- "SyntaxError", "TypeError", "ReferenceError"
74	- "Build failed"
75	- "Command failed"
76	- "Permission denied"
77	- "FATAL"
78	- Stack traces (lines with "at " prefix)
79	- npm ERR!
80	- Warning patterns that indicate real problems
81	```
82
83	### Step 4b: Compress Before Quoting
84
85	Before pasting stdout into TaskSummary or model context:
86
87	\| Command pattern \| Rule \|
88	\|-----------------\|------\|
89	\| `git status` \| Keep only changed entries + branch line + `(N changed)` count. Drop "use git add…" boilerplate. \|
90	\| `npm test` / `vitest` / `jest` \| Keep failing tests + summary line. Drop `PASS` lines. \|
91	\| `npm run build` / `tsc` \| Keep `error` / `warning` / final status. Drop incremental progress. \|
92	\| Any output \| Collapse runs of ≥ 3 identical lines into `<line> … (× N)`. \|
93
94	Helper: `src/utils/output-compress.ts` — `compressGitStatus`, `compressNpmTest`, `summarizeBuildLog`, `collapseRepeatedLines`, `compressFor(command, stdout)`.
95
96	Anti-pattern: Pasting full stdout (> 50 lines) into TaskSummary when only the failing portion matters. Compress first, then quote.
97
98	### Step 5: Stop on Error
99
100	If ANY error is detected:
101
102	```
103	1. STOP — Do not run any more commands
104	2. IDENTIFY — Extract the exact error message and context
105	3. REPORT — Call notify_user with error if critical
106	4. FIX — Use cm-debugging if proceeding to fix
107	```
108
109	### Step 6: Poll Long-Running Commands
110
111	For background commands (returned a CommandId):
112
113	1. Poll `command_status` every 10-15 seconds
114	2. After EACH poll, update `task_boundary` TaskStatus with latest output summary
115	3. Continue until command completes (status: "done")
116	4. Read final output and check for errors
117
118	### Step 7: Confirm Success
119
120	Only after reading output AND confirming no errors:
121
122	Update `task_boundary` TaskSummary with the result:
123	```
124	TaskSummary: "Build completed successfully (0 errors, 0 warnings)"
125	TaskSummary: "All 519 tests passed"
126	TaskSummary: "Deployed to https://prms-4pv.pages.dev successfully"
127	```
128
129	## Red Flags — STOP and Follow Protocol
130
131	If you catch yourself doing ANY of these:
132
133	- Running a command without updating TaskStatus first
134	- Calling `run_command` while previous command is still running
135	- Skipping `command_status` for a background command
136	- Proceeding to next step without reading output
137	- Ignoring warnings or errors in output
138	- Assuming a command succeeded without checking exit code
139	- Running 3+ commands in parallel without monitoring each
140
141	ALL of these mean: STOP. Follow the protocol.
142
143	## Anti-Patterns
144
145	\| DON'T \| DO \|
146	\|-------\|-----\|
147	\| Run and forget \| Run and read output \|
148	\| Assume success \| Verify success from output \|
149	\| Chain commands blindly \| Verify each

People who liked this also viewed

6 picks

Type