@buaa_smat/hometrans 0.1.7 → 0.1.9

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (28) hide show
  1. package/README.md +15 -2
  2. package/dist/cli/config-store.js +148 -0
  3. package/dist/cli/config.js +40 -0
  4. package/dist/cli/index.js +43 -0
  5. package/dist/cli/init.js +378 -0
  6. package/dist/cli/mcp-setup.js +262 -0
  7. package/dist/cli/mcp.js +94 -0
  8. package/dist/cli/uninstall.js +310 -0
  9. package/dist/context/index.js +792 -0
  10. package/package.json +7 -2
  11. package/resource/choose_editor.png +0 -0
  12. package/resource/finish_init.png +0 -0
  13. package/skills/hmos-convert-pipeline/SKILL.md +5 -21
  14. package/skills/hmos-integration-test/SKILL.md +4 -4
  15. package/tools/test-tools/autotest/README.md +4 -4
  16. package/tools/test-tools/autotest/pyproject.toml +16 -6
  17. package/tools/test-tools/autotest/self_test_runner.py +4 -4
  18. package/tools/test-tools/autotest/uv.lock +3156 -3156
  19. package/skills/hmos-incremental-ui-align/references/MVVM/345/274/200/345/217/221/346/226/207/346/241/243/MVVM/346/250/241/345/274/217/357/274/210V1/357/274/211.md +0 -911
  20. package/skills/skill-quality-evaluator/SKILL.md +0 -138
  21. package/skills/skill-quality-evaluator/assets/SKILL_TEMPLATE.md +0 -77
  22. package/skills/skill-quality-evaluator/references/Best-practices-for-skill-creators.md +0 -277
  23. package/skills/skill-quality-evaluator/references/Evaluating-skill-output-quality.md +0 -300
  24. package/skills/skill-quality-evaluator/references/Optimizing-skill-descriptions.md +0 -196
  25. package/skills/skill-quality-evaluator/references/Specification.md +0 -272
  26. package/skills/skill-quality-evaluator/references/Using-scripts-in-skills.md +0 -308
  27. package/skills/skill-quality-evaluator/references/report-template.md +0 -163
  28. package/skills/skill-quality-evaluator/references/scoring-rubric.md +0 -269
@@ -1,272 +0,0 @@
1
- > ## Documentation Index
2
- > Fetch the complete documentation index at: https://agentskills.io/llms.txt
3
- > Use this file to discover all available pages before exploring further.
4
-
5
- # Specification
6
-
7
- > The complete format specification for Agent Skills.
8
-
9
- ## Directory structure
10
-
11
- A skill is a directory containing, at minimum, a `SKILL.md` file:
12
-
13
- ```
14
- skill-name/
15
- ├── SKILL.md # Required: metadata + instructions
16
- ├── scripts/ # Optional: executable code
17
- ├── references/ # Optional: documentation
18
- ├── assets/ # Optional: templates, resources
19
- └── ... # Any additional files or directories
20
- ```
21
-
22
- ## `SKILL.md` format
23
-
24
- The `SKILL.md` file must contain YAML frontmatter followed by Markdown content.
25
-
26
- ### Frontmatter
27
-
28
- | Field | Required | Constraints |
29
- | --------------- | -------- | ----------------------------------------------------------------------------------------------------------------- |
30
- | `name` | Yes | Max 64 characters. Lowercase letters, numbers, and hyphens only. Must not start or end with a hyphen. |
31
- | `description` | Yes | Max 1024 characters. Non-empty. Describes what the skill does and when to use it. |
32
- | `license` | No | License name or reference to a bundled license file. |
33
- | `compatibility` | No | Max 500 characters. Indicates environment requirements (intended product, system packages, network access, etc.). |
34
- | `metadata` | No | Arbitrary key-value mapping for additional metadata. |
35
- | `allowed-tools` | No | Space-separated string of pre-approved tools the skill may use. (Experimental) |
36
-
37
- <Card>
38
- **Minimal example:**
39
-
40
- ```markdown SKILL.md theme={null}
41
- ---
42
- name: skill-name
43
- description: A description of what this skill does and when to use it.
44
- ---
45
- ```
46
-
47
- **Example with optional fields:**
48
-
49
- ```markdown SKILL.md theme={null}
50
- ---
51
- name: pdf-processing
52
- description: Extract PDF text, fill forms, merge files. Use when handling PDFs.
53
- license: Apache-2.0
54
- metadata:
55
- author: example-org
56
- version: "1.0"
57
- ---
58
- ```
59
- </Card>
60
-
61
- #### `name` field
62
-
63
- The required `name` field:
64
-
65
- * Must be 1-64 characters
66
- * May only contain unicode lowercase alphanumeric characters (`a-z`, `0-9`) and hyphens (`-`)
67
- * Must not start or end with a hyphen (`-`)
68
- * Must not contain consecutive hyphens (`--`)
69
- * Must match the parent directory name
70
-
71
- <Card>
72
- **Valid examples:**
73
-
74
- ```yaml theme={null}
75
- name: pdf-processing
76
- ```
77
-
78
- ```yaml theme={null}
79
- name: data-analysis
80
- ```
81
-
82
- ```yaml theme={null}
83
- name: code-review
84
- ```
85
-
86
- **Invalid examples:**
87
-
88
- ```yaml theme={null}
89
- name: PDF-Processing # uppercase not allowed
90
- ```
91
-
92
- ```yaml theme={null}
93
- name: -pdf # cannot start with hyphen
94
- ```
95
-
96
- ```yaml theme={null}
97
- name: pdf--processing # consecutive hyphens not allowed
98
- ```
99
- </Card>
100
-
101
- #### `description` field
102
-
103
- The required `description` field:
104
-
105
- * Must be 1-1024 characters
106
- * Should describe both what the skill does and when to use it
107
- * Should include specific keywords that help agents identify relevant tasks
108
-
109
- <Card>
110
- **Good example:**
111
-
112
- ```yaml theme={null}
113
- description: Extracts text and tables from PDF files, fills PDF forms, and merges multiple PDFs. Use when working with PDF documents or when the user mentions PDFs, forms, or document extraction.
114
- ```
115
-
116
- **Poor example:**
117
-
118
- ```yaml theme={null}
119
- description: Helps with PDFs.
120
- ```
121
- </Card>
122
-
123
- #### `license` field
124
-
125
- The optional `license` field:
126
-
127
- * Specifies the license applied to the skill
128
- * We recommend keeping it short (either the name of a license or the name of a bundled license file)
129
-
130
- <Card>
131
- **Example:**
132
-
133
- ```yaml theme={null}
134
- license: Proprietary. LICENSE.txt has complete terms
135
- ```
136
- </Card>
137
-
138
- #### `compatibility` field
139
-
140
- The optional `compatibility` field:
141
-
142
- * Must be 1-500 characters if provided
143
- * Should only be included if your skill has specific environment requirements
144
- * Can indicate intended product, required system packages, network access needs, etc.
145
-
146
- <Card>
147
- **Examples:**
148
-
149
- ```yaml theme={null}
150
- compatibility: Designed for Claude Code (or similar products)
151
- ```
152
-
153
- ```yaml theme={null}
154
- compatibility: Requires git, docker, jq, and access to the internet
155
- ```
156
-
157
- ```yaml theme={null}
158
- compatibility: Requires Python 3.14+ and uv
159
- ```
160
- </Card>
161
-
162
- <Note>
163
- Most skills do not need the `compatibility` field.
164
- </Note>
165
-
166
- #### `metadata` field
167
-
168
- The optional `metadata` field:
169
-
170
- * A map from string keys to string values
171
- * Clients can use this to store additional properties not defined by the Agent Skills spec
172
- * We recommend making your key names reasonably unique to avoid accidental conflicts
173
-
174
- <Card>
175
- **Example:**
176
-
177
- ```yaml theme={null}
178
- metadata:
179
- author: example-org
180
- version: "1.0"
181
- ```
182
- </Card>
183
-
184
- #### `allowed-tools` field
185
-
186
- The optional `allowed-tools` field:
187
-
188
- * A space-separated string of tools that are pre-approved to run
189
- * Experimental. Support for this field may vary between agent implementations
190
-
191
- <Card>
192
- **Example:**
193
-
194
- ```yaml theme={null}
195
- allowed-tools: Bash(git:*) Bash(jq:*) Read
196
- ```
197
- </Card>
198
-
199
- ### Body content
200
-
201
- The Markdown body after the frontmatter contains the skill instructions. There are no format restrictions. Write whatever helps agents perform the task effectively.
202
-
203
- Recommended sections:
204
-
205
- * Step-by-step instructions
206
- * Examples of inputs and outputs
207
- * Common edge cases
208
-
209
- Note that the agent will load this entire file once it's decided to activate a skill. Consider splitting longer `SKILL.md` content into referenced files.
210
-
211
- ## Optional directories
212
-
213
- ### `scripts/`
214
-
215
- Contains executable code that agents can run. Scripts should:
216
-
217
- * Be self-contained or clearly document dependencies
218
- * Include helpful error messages
219
- * Handle edge cases gracefully
220
-
221
- Supported languages depend on the agent implementation. Common options include Python, Bash, and JavaScript.
222
-
223
- ### `references/`
224
-
225
- Contains additional documentation that agents can read when needed:
226
-
227
- * `REFERENCE.md` - Detailed technical reference
228
- * `FORMS.md` - Form templates or structured data formats
229
- * Domain-specific files (`finance.md`, `legal.md`, etc.)
230
-
231
- Keep individual [reference files](#file-references) focused. Agents load these on demand, so smaller files mean less use of context.
232
-
233
- ### `assets/`
234
-
235
- Contains static resources:
236
-
237
- * Templates (document templates, configuration templates)
238
- * Images (diagrams, examples)
239
- * Data files (lookup tables, schemas)
240
-
241
- ## Progressive disclosure
242
-
243
- Agents load skills *progressively*, pulling in more detail only as a task calls for it. Skills should be structured to take advantage of this:
244
-
245
- 1. **Metadata** (\~100 tokens): The `name` and `description` fields are loaded at startup for all skills
246
- 2. **Instructions** (\< 5000 tokens recommended): The full `SKILL.md` body is loaded when the skill is activated
247
- 3. **Resources** (as needed): Files (e.g. those in `scripts/`, `references/`, or `assets/`) are loaded only when required
248
-
249
- Keep your main `SKILL.md` under 500 lines. Move detailed reference material to separate files.
250
-
251
- ## File references
252
-
253
- When referencing other files in your skill, use relative paths from the skill root:
254
-
255
- ```markdown SKILL.md theme={null}
256
- See [the reference guide](references/REFERENCE.md) for details.
257
-
258
- Run the extraction script:
259
- scripts/extract.py
260
- ```
261
-
262
- Keep file references one level deep from `SKILL.md`. Avoid deeply nested reference chains.
263
-
264
- ## Validation
265
-
266
- Use the [skills-ref](https://github.com/agentskills/agentskills/tree/main/skills-ref) reference library to validate your skills:
267
-
268
- ```bash theme={null}
269
- skills-ref validate ./my-skill
270
- ```
271
-
272
- This checks that your `SKILL.md` frontmatter is valid and follows all naming conventions.
@@ -1,308 +0,0 @@
1
- > ## Documentation Index
2
- > Fetch the complete documentation index at: https://agentskills.io/llms.txt
3
- > Use this file to discover all available pages before exploring further.
4
-
5
- # Using scripts in skills
6
-
7
- > How to run commands and bundle executable scripts in your skills.
8
-
9
- Skills can instruct agents to run shell commands and bundle reusable scripts in a `scripts/` directory. This guide covers one-off commands, self-contained scripts with their own dependencies, and how to design script interfaces for agentic use.
10
-
11
- ## One-off commands
12
-
13
- When an existing package already does what you need, you can reference it directly in your `SKILL.md` instructions without a `scripts/` directory. Many ecosystems provide tools that auto-resolve dependencies at runtime.
14
-
15
- <Tabs sync={false}>
16
- <Tab title="uvx">
17
- [uvx](https://docs.astral.sh/uv/guides/tools/) runs Python packages in isolated environments with aggressive caching. It ships with [uv](https://docs.astral.sh/uv/).
18
-
19
- ```bash theme={null}
20
- uvx ruff@0.8.0 check .
21
- uvx black@24.10.0 .
22
- ```
23
-
24
- * Not bundled with Python — requires a separate install.
25
- * Fast. Caches aggressively so repeat runs are near-instant.
26
- </Tab>
27
-
28
- <Tab title="pipx">
29
- [pipx](https://pipx.pypa.io/) runs Python packages in isolated environments. Available via OS package managers (`apt install pipx`, `brew install pipx`).
30
-
31
- ```bash theme={null}
32
- pipx run 'black==24.10.0' .
33
- pipx run 'ruff==0.8.0' check .
34
- ```
35
-
36
- * Not bundled with Python — requires a separate install.
37
- * A mature alternative to `uvx`. While `uvx` has become the standard recommendation, `pipx` remains a reliable option with broader OS package manager availability.
38
- </Tab>
39
-
40
- <Tab title="npx">
41
- [npx](https://docs.npmjs.com/cli/commands/npx) runs npm packages, downloading them on demand. It ships with npm (which ships with Node.js).
42
-
43
- ```bash theme={null}
44
- npx eslint@9 --fix .
45
- npx create-vite@6 my-app
46
- ```
47
-
48
- * Bundled with Node.js — no extra install needed.
49
- * Downloads the package, runs it, and caches it for future use.
50
- * Pin versions with `npx package@version` for reproducibility.
51
- </Tab>
52
-
53
- <Tab title="bunx">
54
- [bunx](https://bun.sh/docs/cli/bunx) is Bun's equivalent of `npx`. It ships with [Bun](https://bun.sh/).
55
-
56
- ```bash theme={null}
57
- bunx eslint@9 --fix .
58
- bunx create-vite@6 my-app
59
- ```
60
-
61
- * Drop-in replacement for `npx` in Bun-based environments.
62
- * Only appropriate when the user's environment has Bun rather than Node.js.
63
- </Tab>
64
-
65
- <Tab title="deno run">
66
- [deno run](https://docs.deno.com/runtime/reference/cli/run/) runs scripts directly from URLs or specifiers. It ships with [Deno](https://deno.com/).
67
-
68
- ```bash theme={null}
69
- deno run npm:create-vite@6 my-app
70
- deno run --allow-read npm:eslint@9 -- --fix .
71
- ```
72
-
73
- * Permission flags (`--allow-read`, etc.) are required for filesystem/network access.
74
- * Use `--` to separate Deno flags from the tool's own flags.
75
- </Tab>
76
-
77
- <Tab title="go run">
78
- [go run](https://pkg.go.dev/cmd/go#hdr-Compile_and_run_Go_program) compiles and runs Go packages directly. It is built into the `go` command.
79
-
80
- ```bash theme={null}
81
- go run golang.org/x/tools/cmd/goimports@v0.28.0 .
82
- go run github.com/golangci/golangci-lint/cmd/golangci-lint@v1.62.0 run
83
- ```
84
-
85
- * Built into Go — no extra tooling needed.
86
- * Pin versions or use `@latest` to make the command explicit.
87
- </Tab>
88
- </Tabs>
89
-
90
- **Tips for one-off commands in skills:**
91
-
92
- * **Pin versions** (e.g., `npx eslint@9.0.0`) so the command behaves the same over time.
93
- * **State prerequisites** in your `SKILL.md` (e.g., "Requires Node.js 18+") rather than assuming the agent's environment has them. For runtime-level requirements, use the [`compatibility` frontmatter field](/specification#compatibility-field).
94
- * **Move complex commands into scripts.** A one-off command works well when you're invoking a tool with a few flags. When a command grows complex enough that it's hard to get right on the first try, a tested script in `scripts/` is more reliable.
95
-
96
- ## Referencing scripts from `SKILL.md`
97
-
98
- Use **relative paths from the skill directory root** to reference bundled files. The agent resolves these paths automatically — no absolute paths needed.
99
-
100
- List available scripts in your `SKILL.md` so the agent knows they exist:
101
-
102
- ```markdown SKILL.md theme={null}
103
- ## Available scripts
104
-
105
- - **`scripts/validate.sh`** — Validates configuration files
106
- - **`scripts/process.py`** — Processes input data
107
- ```
108
-
109
- Then instruct the agent to run them:
110
-
111
- ````markdown SKILL.md theme={null}
112
- ## Workflow
113
-
114
- 1. Run the validation script:
115
- ```bash
116
- bash scripts/validate.sh "$INPUT_FILE"
117
- ```
118
-
119
- 2. Process the results:
120
- ```bash
121
- python3 scripts/process.py --input results.json
122
- ```
123
- ````
124
-
125
- <Note>
126
- The same relative-path convention works in support files like `references/*.md` — script execution paths (in code blocks) are relative to the **skill directory root**, because the agent runs commands from there.
127
- </Note>
128
-
129
- ## Self-contained scripts
130
-
131
- When you need reusable logic, bundle a script in `scripts/` that declares its own dependencies inline. The agent can run the script with a single command — no separate manifest file or install step required.
132
-
133
- Several languages support inline dependency declarations:
134
-
135
- <Tabs sync={false}>
136
- <Tab title="Python">
137
- [PEP 723](https://peps.python.org/pep-0723/) defines a standard format for inline script metadata. Declare dependencies in a TOML block inside `# ///` markers:
138
-
139
- ```python scripts/extract.py theme={null}
140
- # /// script
141
- # dependencies = [
142
- # "beautifulsoup4",
143
- # ]
144
- # ///
145
-
146
- from bs4 import BeautifulSoup
147
-
148
- html = '<html><body><h1>Welcome</h1><p class="info">This is a test.</p></body></html>'
149
- print(BeautifulSoup(html, "html.parser").select_one("p.info").get_text())
150
- ```
151
-
152
- Run with [uv](https://docs.astral.sh/uv/) (recommended):
153
-
154
- ```bash theme={null}
155
- uv run scripts/extract.py
156
- ```
157
-
158
- `uv run` creates an isolated environment, installs the declared dependencies, and runs the script. [pipx](https://pipx.pypa.io/) (`pipx run scripts/extract.py`) also supports PEP 723.
159
-
160
- * Pin versions with [PEP 508](https://peps.python.org/pep-0508/) specifiers: `"beautifulsoup4>=4.12,<5"`.
161
- * Use `requires-python` to constrain the Python version.
162
- * Use `uv lock --script` to create a lockfile for full reproducibility.
163
- </Tab>
164
-
165
- <Tab title="Deno">
166
- Deno's `npm:` and `jsr:` import specifiers make every script self-contained by default:
167
-
168
- ```typescript scripts/extract.ts theme={null}
169
- #!/usr/bin/env -S deno run
170
-
171
- import * as cheerio from "npm:cheerio@1.0.0";
172
-
173
- const html = `<html><body><h1>Welcome</h1><p class="info">This is a test.</p></body></html>`;
174
- const $ = cheerio.load(html);
175
- console.log($("p.info").text());
176
- ```
177
-
178
- ```bash theme={null}
179
- deno run scripts/extract.ts
180
- ```
181
-
182
- * Use `npm:` for npm packages, `jsr:` for Deno-native packages.
183
- * Version specifiers follow semver: `@1.0.0` (exact), `@^1.0.0` (compatible).
184
- * Dependencies are cached globally. Use `--reload` to force re-fetch.
185
- * Packages with native addons (node-gyp) may not work — packages that ship pre-built binaries work best.
186
- </Tab>
187
-
188
- <Tab title="Bun">
189
- Bun auto-installs missing packages at runtime when no `node_modules` directory is found. Pin versions directly in the import path:
190
-
191
- ```typescript scripts/extract.ts theme={null}
192
- #!/usr/bin/env bun
193
-
194
- import * as cheerio from "cheerio@1.0.0";
195
-
196
- const html = `<html><body><h1>Welcome</h1><p class="info">This is a test.</p></body></html>`;
197
- const $ = cheerio.load(html);
198
- console.log($("p.info").text());
199
- ```
200
-
201
- ```bash theme={null}
202
- bun run scripts/extract.ts
203
- ```
204
-
205
- * No `package.json` or `node_modules` needed. TypeScript works natively.
206
- * Packages are cached globally. First run downloads; subsequent runs are near-instant.
207
- * If a `node_modules` directory exists anywhere up the directory tree, auto-install is disabled and Bun falls back to standard Node.js resolution.
208
- </Tab>
209
-
210
- <Tab title="Ruby">
211
- Bundler ships with Ruby since 2.6. Use `bundler/inline` to declare gems directly in the script:
212
-
213
- ```ruby scripts/extract.rb theme={null}
214
- require 'bundler/inline'
215
-
216
- gemfile do
217
- source 'https://rubygems.org'
218
- gem 'nokogiri'
219
- end
220
-
221
- html = '<html><body><h1>Welcome</h1><p class="info">This is a test.</p></body></html>'
222
- doc = Nokogiri::HTML(html)
223
- puts doc.at_css('p.info').text
224
- ```
225
-
226
- ```bash theme={null}
227
- ruby scripts/extract.rb
228
- ```
229
-
230
- * Pin versions explicitly (`gem 'nokogiri', '~> 1.16'`) — there is no lockfile.
231
- * An existing `Gemfile` or `BUNDLE_GEMFILE` env var in the working directory can interfere.
232
- </Tab>
233
- </Tabs>
234
-
235
- ## Designing scripts for agentic use
236
-
237
- When an agent runs your script, it reads stdout and stderr to decide what to do next. A few design choices make scripts dramatically easier for agents to use.
238
-
239
- ### Avoid interactive prompts
240
-
241
- This is a hard requirement of the agent execution environment. Agents operate in non-interactive shells — they cannot respond to TTY prompts, password dialogs, or confirmation menus. A script that blocks on interactive input will hang indefinitely.
242
-
243
- Accept all input via command-line flags, environment variables, or stdin:
244
-
245
- ```
246
- # Bad: hangs waiting for input
247
- $ python scripts/deploy.py
248
- Target environment: _
249
-
250
- # Good: clear error with guidance
251
- $ python scripts/deploy.py
252
- Error: --env is required. Options: development, staging, production.
253
- Usage: python scripts/deploy.py --env staging --tag v1.2.3
254
- ```
255
-
256
- ### Document usage with `--help`
257
-
258
- `--help` output is the primary way an agent learns your script's interface. Include a brief description, available flags, and usage examples:
259
-
260
- ```
261
- Usage: scripts/process.py [OPTIONS] INPUT_FILE
262
-
263
- Process input data and produce a summary report.
264
-
265
- Options:
266
- --format FORMAT Output format: json, csv, table (default: json)
267
- --output FILE Write output to FILE instead of stdout
268
- --verbose Print progress to stderr
269
-
270
- Examples:
271
- scripts/process.py data.csv
272
- scripts/process.py --format csv --output report.csv data.csv
273
- ```
274
-
275
- Keep it concise — the output enters the agent's context window alongside everything else it's working with.
276
-
277
- ### Write helpful error messages
278
-
279
- When an agent gets an error, the message directly shapes its next attempt. An opaque "Error: invalid input" wastes a turn. Instead, say what went wrong, what was expected, and what to try:
280
-
281
- ```
282
- Error: --format must be one of: json, csv, table.
283
- Received: "xml"
284
- ```
285
-
286
- ### Use structured output
287
-
288
- Prefer structured formats — JSON, CSV, TSV — over free-form text. Structured formats can be consumed by both the agent and standard tools (`jq`, `cut`, `awk`), making your script composable in pipelines.
289
-
290
- ```
291
- # Whitespace-aligned — hard to parse programmatically
292
- NAME STATUS CREATED
293
- my-service running 2025-01-15
294
-
295
- # Delimited — unambiguous field boundaries
296
- {"name": "my-service", "status": "running", "created": "2025-01-15"}
297
- ```
298
-
299
- **Separate data from diagnostics:** send structured data to stdout and progress messages, warnings, and other diagnostics to stderr. This lets the agent capture clean, parseable output while still having access to diagnostic information when needed.
300
-
301
- ### Further considerations
302
-
303
- * **Idempotency.** Agents may retry commands. "Create if not exists" is safer than "create and fail on duplicate."
304
- * **Input constraints.** Reject ambiguous input with a clear error rather than guessing. Use enums and closed sets where possible.
305
- * **Dry-run support.** For destructive or stateful operations, a `--dry-run` flag lets the agent preview what will happen.
306
- * **Meaningful exit codes.** Use distinct exit codes for different failure types (not found, invalid arguments, auth failure) and document them in your `--help` output so the agent knows what each code means.
307
- * **Safe defaults.** Consider whether destructive operations should require explicit confirmation flags (`--confirm`, `--force`) or other safeguards appropriate to the risk level.
308
- * **Predictable output size.** Many agent harnesses automatically truncate tool output beyond a threshold (e.g., 10-30K characters), potentially losing critical information. If your script might produce large output, default to a summary or a reasonable limit, and support flags like `--offset` so the agent can request more information when needed. Alternatively, if output is large and not amenable to pagination, require agents to pass an `--output` flag that specifies either an output file or `-` to explicitly opt in to stdout.