pi-agent-toolkit 0.1.0

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 (53) hide show
  1. package/dist/dotfiles/AGENTS.md +197 -0
  2. package/dist/dotfiles/APPEND_SYSTEM.md +78 -0
  3. package/dist/dotfiles/agent-modes.json +12 -0
  4. package/dist/dotfiles/agent-skills/exa-search/.env.example +4 -0
  5. package/dist/dotfiles/agent-skills/exa-search/SKILL.md +234 -0
  6. package/dist/dotfiles/agent-skills/exa-search/scripts/exa-api.cjs +197 -0
  7. package/dist/dotfiles/auth.json.template +5 -0
  8. package/dist/dotfiles/damage-control-rules.yaml +318 -0
  9. package/dist/dotfiles/extensions/btw.ts +1031 -0
  10. package/dist/dotfiles/extensions/commit-approval.ts +590 -0
  11. package/dist/dotfiles/extensions/context.ts +578 -0
  12. package/dist/dotfiles/extensions/control.ts +1748 -0
  13. package/dist/dotfiles/extensions/damage-control/index.ts +543 -0
  14. package/dist/dotfiles/extensions/damage-control/node_modules/.package-lock.json +22 -0
  15. package/dist/dotfiles/extensions/damage-control/package-lock.json +28 -0
  16. package/dist/dotfiles/extensions/damage-control/package.json +7 -0
  17. package/dist/dotfiles/extensions/dirty-repo-guard.ts +56 -0
  18. package/dist/dotfiles/extensions/exa-enforce.ts +51 -0
  19. package/dist/dotfiles/extensions/exa-search-tool.ts +384 -0
  20. package/dist/dotfiles/extensions/execute-command/index.ts +82 -0
  21. package/dist/dotfiles/extensions/files.ts +1112 -0
  22. package/dist/dotfiles/extensions/loop.ts +446 -0
  23. package/dist/dotfiles/extensions/pr-approval.ts +730 -0
  24. package/dist/dotfiles/extensions/qna-interactive.ts +532 -0
  25. package/dist/dotfiles/extensions/question-mode.ts +242 -0
  26. package/dist/dotfiles/extensions/require-session-name-on-exit.ts +141 -0
  27. package/dist/dotfiles/extensions/review.ts +2091 -0
  28. package/dist/dotfiles/extensions/session-breakdown.ts +1629 -0
  29. package/dist/dotfiles/extensions/term-notify.ts +150 -0
  30. package/dist/dotfiles/extensions/tilldone.ts +527 -0
  31. package/dist/dotfiles/extensions/todos.ts +2082 -0
  32. package/dist/dotfiles/extensions/tools.ts +146 -0
  33. package/dist/dotfiles/extensions/uv.ts +123 -0
  34. package/dist/dotfiles/global-skills/brainstorm/SKILL.md +10 -0
  35. package/dist/dotfiles/global-skills/cli-detector/SKILL.md +192 -0
  36. package/dist/dotfiles/global-skills/gh-issue-creator/SKILL.md +173 -0
  37. package/dist/dotfiles/global-skills/google-chat-cards-v2/SKILL.md +237 -0
  38. package/dist/dotfiles/global-skills/google-chat-cards-v2/references/bridge_tap_implementation.md +466 -0
  39. package/dist/dotfiles/global-skills/technical-docs/SKILL.md +204 -0
  40. package/dist/dotfiles/global-skills/technical-docs/references/diagrams.md +168 -0
  41. package/dist/dotfiles/global-skills/technical-docs/references/examples.md +449 -0
  42. package/dist/dotfiles/global-skills/technical-docs/scripts/validate_docs.py +352 -0
  43. package/dist/dotfiles/global-skills/whats-new/SKILL.md +159 -0
  44. package/dist/dotfiles/intercepted-commands/pip +7 -0
  45. package/dist/dotfiles/intercepted-commands/pip3 +7 -0
  46. package/dist/dotfiles/intercepted-commands/poetry +10 -0
  47. package/dist/dotfiles/intercepted-commands/python +104 -0
  48. package/dist/dotfiles/intercepted-commands/python3 +104 -0
  49. package/dist/dotfiles/mcp.json.template +32 -0
  50. package/dist/dotfiles/models.json +27 -0
  51. package/dist/dotfiles/settings.json +25 -0
  52. package/dist/index.js +1344 -0
  53. package/package.json +34 -0
@@ -0,0 +1,197 @@
1
+ # AGENTS.md
2
+
3
+ ## Global Agent Rules
4
+
5
+ These rules apply to all repositories unless a project-level AGENTS.md adds stricter rules.
6
+
7
+ ### Git safety
8
+
9
+ - Do **not** create commits unless the user explicitly asks to commit.
10
+ - Do **not** push branches unless the user explicitly asks to push.
11
+ - **Never** use `--no-verify` when committing. All pre-commit hooks must pass.
12
+ - After making code changes, stop at diff + validation results and ask for approval before any commit.
13
+ - If the user asks to "proceed" or "continue," do not infer commit permission.
14
+
15
+ ### Commit message style
16
+
17
+ When the user explicitly asks to commit, use Conventional Commits:
18
+
19
+ ```text
20
+ <type>(<scope>): <subject>
21
+
22
+ <body>
23
+
24
+ <footer>
25
+ ```
26
+
27
+ - Allowed types: `feat`, `fix`, `refactor`, `docs`, `test`, `chore`, `style`, `perf`, `ci`, `build`
28
+ - Use imperative mood (e.g., "add" not "added")
29
+ - Start subject lowercase, no trailing punctuation, max 50 chars
30
+ - Separate subject/body with a blank line; wrap body at 72 chars
31
+ - Focus on **why** (the diff already shows what changed)
32
+ - No AI attribution and no emojis
33
+ - **Always include a body** — single-line commits are not acceptable
34
+
35
+ Example:
36
+
37
+ ```text
38
+ feat(search): add debounced input to federated search
39
+
40
+ The raw keypress handler was firing a request per keystroke,
41
+ causing rate-limit hits on accounts with many companies.
42
+
43
+ Added a 300ms debounce using useRef + setTimeout so requests
44
+ only fire after the user stops typing.
45
+ ```
46
+
47
+ ### Pull request style
48
+
49
+ When the user explicitly asks to create a PR, always provide a title and body.
50
+
51
+ **Title**: Short, descriptive summary of the change (imperative mood, max 72 chars).
52
+
53
+ **Body** format:
54
+
55
+ ```text
56
+ ## What changed
57
+
58
+ Concise summary of the changes. List key files or areas affected.
59
+
60
+ ## Why
61
+
62
+ Motivation, context, or problem being solved. Link related issues if applicable.
63
+
64
+ ## How tested
65
+
66
+ What validation was done — tests added/updated, manual checks, commands run.
67
+
68
+ ## Notes (optional)
69
+
70
+ Breaking changes, follow-ups, deployment considerations, or anything reviewers should know.
71
+ ```
72
+
73
+ - Be reasonably detailed without being verbose — a reviewer should understand the change without reading every diff line
74
+ - No AI attribution and no emojis
75
+ - Always use `--title` and `--body` flags with `gh pr create`
76
+
77
+ Example:
78
+
79
+ ```text
80
+ Title: fix(cache): prevent stale Redis entries after credential rotation
81
+
82
+ Body:
83
+ ## What changed
84
+
85
+ Updated `src/lib/cache/query-cache.ts` to include a credential version
86
+ hash in cache keys. Added a cache-bust helper in `src/lib/credentials/`.
87
+
88
+ ## Why
89
+
90
+ After rotating a company's database credentials, cached query results
91
+ continued using the old connection pool key, returning stale or errored
92
+ responses until TTL expiry.
93
+
94
+ ## How tested
95
+
96
+ - Added unit tests for new cache key generation
97
+ - Verified manually by rotating credentials and confirming immediate
98
+ cache invalidation
99
+ - Ran full CI suite, all checks pass
100
+
101
+ ## Notes
102
+
103
+ Existing cache entries will expire naturally via TTL. No migration needed.
104
+ ```
105
+
106
+ ### Code style
107
+
108
+ - Do **not** use emojis in code (strings, comments, log messages, docstrings).
109
+ - To make text stand out, use colors (ANSI codes), bolding, or ASCII symbols instead of emojis.
110
+
111
+ ### Try before asking
112
+
113
+ When about to ask the user whether they have a tool, command, or dependency installed -- don't ask, just try it. If it works, proceed. If it fails, inform the user and suggest installation. Saves back-and-forth and gives a definitive answer immediately.
114
+
115
+ ### Verify before claiming done
116
+
117
+ Never claim success without proving it. Before saying "done", "fixed", or "tests pass":
118
+ 1. Run the actual verification command.
119
+ 2. Show the output.
120
+ 3. Confirm it matches the claim.
121
+
122
+ Evidence before assertions. If about to say "should work now" -- stop. That's a guess. Run the command first.
123
+
124
+ ### Investigate before fixing
125
+
126
+ When something breaks, don't guess -- investigate first. No fixes without understanding the root cause:
127
+ 1. **Observe** -- Read error messages carefully, check the full stack trace.
128
+ 2. **Hypothesize** -- Form a theory based on evidence.
129
+ 3. **Verify** -- Test the hypothesis before implementing a fix.
130
+ 4. **Fix** -- Target the root cause, not the symptom.
131
+
132
+ Avoid shotgun debugging. If making random changes hoping something works, the problem isn't understood yet.
133
+
134
+ ### Clean up after yourself
135
+
136
+ Never leave debugging or testing artifacts in the codebase:
137
+ - `console.log` / `print` statements added for debugging -- remove once understood.
138
+ - Commented-out code used for testing alternatives -- delete, don't commit.
139
+ - Temporary test files, scratch scripts, throwaway fixtures -- delete when done.
140
+ - Hardcoded test values (URLs, tokens, IDs) -- revert to proper configuration.
141
+ - Disabled tests or skipped assertions (`it.skip`, `xit`, `@Ignore`) -- re-enable or remove.
142
+
143
+ Before every commit, scan changes for artifacts. If `git diff` shows `console.log("DEBUG")`, a `TODO: remove this`, or a commented-out block -- clean it up first.
144
+
145
+ ### Path discipline
146
+
147
+ - Do **not** read, search, or inspect files inside `node_modules/` by default.
148
+ - Treat `node_modules/` as off-limits unless the user explicitly asks to inspect an installed dependency/package or the installed package is the only source of truth for the behavior in question.
149
+ - If inspection of `node_modules/` is genuinely necessary and the user did not explicitly ask for it, ask for permission first.
150
+ - When inspection is allowed, keep it tightly scoped to the smallest possible set of named files and never run broad recursive searches over `node_modules/`.
151
+ - **Exception — Pi packages:** Reading files under `@mariozechner/` is always allowed without permission. This namespace contains Pi and its related packages (docs, examples, extensions, themes, skills, SDK source).
152
+
153
+ ### Default workflow
154
+
155
+ 1. Make requested edits.
156
+ 2. Run relevant checks (lint/typecheck/tests as appropriate).
157
+ 3. Report changed files and results.
158
+ 4. Wait for explicit commit/push instruction.
159
+
160
+ ### cmux environment
161
+
162
+ This machine runs cmux (Ghostty-based terminal multiplexer).
163
+ When `CMUX_WORKSPACE_ID` is set, the following are available:
164
+
165
+ **Notifications** — use after long-running tasks complete or fail:
166
+ ```bash
167
+ cmux notify --title "Done" --body "All tests passed"
168
+ cmux notify --title "Failed" --body "3 lint errors"
169
+ ```
170
+
171
+ **Visual flash** — draw attention to a surface or workspace:
172
+ ```bash
173
+ cmux trigger-flash
174
+ ```
175
+
176
+ **Sidebar metadata** — surface progress and status at a glance:
177
+ ```bash
178
+ cmux set-status build "running" --color "#ff9500"
179
+ cmux set-progress 0.5 --label "Building..."
180
+ cmux log --level success "Deploy complete"
181
+ ```
182
+
183
+ **Subagent in split pane** — spawn work in a new split, then read results:
184
+ ```bash
185
+ cmux new-split right
186
+ cmux send --surface surface:N "command\n"
187
+ cmux read-screen --surface surface:N --lines 50
188
+ ```
189
+
190
+ Detailed usage is covered by the `cmux`, `cmux-and-worktrees`, and
191
+ `cmux-browser` skills — load those for full reference.
192
+
193
+
194
+
195
+
196
+
197
+
@@ -0,0 +1,78 @@
1
+ ## Rule priority
2
+
3
+ When instructions in this file conflict with project-level AGENTS.md rules, this file takes precedence. Within this file, more specific rules override general ones.
4
+
5
+ ## Reasoning and feedback quality
6
+
7
+ - Avoid sycophancy and uncritical agreement.
8
+ - Challenge user assumptions respectfully when needed.
9
+ - Ground responses in facts, best practices, and clear logic.
10
+ - Present pros and cons (trade-offs) to the user instead of always agreeing.
11
+ - If a user request conflicts with evidence or best practices, explain why and propose better alternatives.
12
+
13
+ ## jCodeMunch MCP usage policy
14
+
15
+ - On session start, **only if the current working directory is inside a git
16
+ repository** (i.e., `git rev-parse --is-inside-work-tree` succeeds), call
17
+ `jcodemunch_index_folder` with `path` set to the current working directory.
18
+ Skip indexing entirely for non-repo directories (e.g., `~`, `~/Downloads`,
19
+ `~/Documents`) to avoid needlessly indexing personal files. Incremental
20
+ indexing (the default) is cheap — it only re-processes changed files, so
21
+ this is safe to run unconditionally when inside a repo. If the call fails
22
+ on the first attempt (server still connecting), retry once before falling
23
+ back.
24
+ - All jCodeMunch tools are prefixed with `jcodemunch_`. The `index_folder`
25
+ tool requires the parameter name `path` (not `folder_path`).
26
+ - **Do not begin code exploration until `index_folder` has fully completed.**
27
+ Wait for the indexing result before calling any other jCodeMunch tools or
28
+ reading source files. Never index "in parallel" with analysis.
29
+ - Re-index (`index_folder`) after git pull, branch switches, or when retrieved
30
+ symbols appear stale or do not match file contents.
31
+ - For code exploration and understanding, prefer jCodeMunch tools over reading
32
+ full files:
33
+ - Use `get_repo_outline` or `get_file_tree` to understand project structure.
34
+ - Use `search_symbols` to locate functions, classes, and methods by name.
35
+ - Use `get_symbol` or `get_symbols` for precise source retrieval.
36
+ - Use `get_context_bundle` before making edits to understand a symbol's
37
+ imports, neighbors, and related code.
38
+ - Use `get_blast_radius` before modifying widely-used symbols.
39
+ - Use `get_file_outline` to inspect a file's symbols before pulling source.
40
+ - Reserve Read/Bash/grep for: exact-string lookups (error messages, config
41
+ values, log text), non-code files (config, JSON, YAML, markdown), and files
42
+ outside the indexed repository.
43
+
44
+ ## Documentation lookups
45
+
46
+ - When giving advice about library/framework APIs, state your confidence
47
+ level about version currency.
48
+ - If the user is working with a recent or rapidly-changing library, use
49
+ Exa to verify against current docs before answering.
50
+ - When uncertain about API details, search the library's official docs
51
+ site via Exa (e.g., includeDomains: ["react.dev"]) rather than
52
+ guessing from training data.
53
+ - Do not substitute browser automation or ad-hoc web fetching for normal
54
+ documentation lookup when Exa is available. If Exa cannot satisfy the
55
+ request, say so explicitly before considering another path.
56
+
57
+ ## Tool-first approach
58
+
59
+ - Before writing custom code to accomplish a task, scan all available tools (MCP servers, skills, CLI utilities) for existing capabilities that already handle the request.
60
+ - Purpose-built tools are often faster, more reliable, and better maintained than ad-hoc scripts.
61
+ - Only fall back to writing custom code when no available tool covers the requirement or when the tool's output needs non-trivial post-processing.
62
+
63
+ ## Writing style
64
+
65
+ - Never use em dashes (--) in responses, written content, or any text the user may copy and paste.
66
+ - Use alternatives instead: commas, parentheses, colons, semicolons, or separate sentences.
67
+
68
+ ## External data preference
69
+
70
+ - For factual claims, version-specific APIs, and time-sensitive information, prefer external verification over internal knowledge.
71
+ - If accuracy is uncertain or information may be outdated, search for external data before answering.
72
+ - Do not guess when data can be retrieved. When in doubt, retrieve.
73
+ - If information cannot be confidently verified, state the uncertainty explicitly rather than presenting it as fact.
74
+ - Ask a clarifying question if missing inputs would lead to an unreliable answer.
75
+ - For web search, semantic lookup, similar-page discovery, and general web research, use the `exa_search` tool.
76
+ - Do not use ad-hoc web search methods (`python requests`, `curl`, direct scraping) unless the user explicitly requests direct URL fetch.
77
+ - Do not use browser automation as a fallback for ordinary web lookup when Exa can handle the task. Reserve browser tools for interactive flows, authentication, screenshots, UI testing, or explicit user requests.
78
+ - Prefer responses with cited source links from search results.
@@ -0,0 +1,12 @@
1
+ {
2
+ "debug": {
3
+ "provider": "openai-codex",
4
+ "model": "gpt-5.4",
5
+ "thinkingLevel": "medium"
6
+ },
7
+ "review": {
8
+ "provider": "openai-codex",
9
+ "model": "gpt-5.4",
10
+ "thinkingLevel": "medium"
11
+ }
12
+ }
@@ -0,0 +1,4 @@
1
+ # Exa API Key Configuration
2
+ # Get your API key from: https://dashboard.exa.ai/api-keys
3
+
4
+ EXA_API_KEY=your_api_key_here
@@ -0,0 +1,234 @@
1
+ ---
2
+ name: exa-search
3
+ description: "Semantic web search and structured research using Exa. Use when you need web search, semantic search, similar-page discovery, content extraction from search results, direct answers with sources, or structured research over web sources. Triggers: exa, web search, semantic search, find similar, research, docs lookup, github search."
4
+ compatibility: "Requires Node.js plus an Exa API key via EXA_API_KEY or .env in this skill directory."
5
+ ---
6
+
7
+ # Exa Search
8
+
9
+ Use this skill as the default Pi pathway for web search and research.
10
+
11
+ This skill is intentionally Pi-native. It does **not** rely on Claude-specific task orchestration or legacy harness path conventions. When this skill is loaded, choose the right Exa endpoint, build a JSON payload, run the local helper script with `bash`, and summarize the results with source links.
12
+
13
+ ## When to use it
14
+
15
+ Use this skill when the user needs:
16
+ - semantic web search
17
+ - similar-page discovery from an existing URL
18
+ - content extraction from known Exa result IDs
19
+ - a direct answer sourced from web search
20
+ - structured research output over web sources
21
+ - current docs or recent web information that should not be guessed from memory
22
+
23
+ Do **not** use ad-hoc web fetching (`curl`, `wget`, custom requests scripts) when Exa can handle the request. This skill is the sanctioned web-search path for this Pi setup.
24
+
25
+ ## Explicit invocation
26
+
27
+ You can load it directly with:
28
+
29
+ ```text
30
+ /skill:exa-search <user request>
31
+ ```
32
+
33
+ When invoked this way, treat the appended text as the user’s actual search/research request.
34
+
35
+ ## Endpoint selection
36
+
37
+ Choose the endpoint that best matches intent:
38
+
39
+ - **search** — semantic web search, finding pages, docs, articles, repos, or papers
40
+ - **contents** — fetch full content for known Exa result IDs
41
+ - **findsimilar** — find pages similar to a given URL
42
+ - **answer** — produce a direct answer backed by Exa results
43
+ - **research** — produce structured research output following a requested schema
44
+
45
+ ## Standard workflow
46
+
47
+ 1. Understand the user’s question.
48
+ 2. Pick the correct Exa endpoint.
49
+ 3. Build a focused JSON payload.
50
+ 4. Run the helper script with `bash`.
51
+ 5. Read the JSON response.
52
+ 6. Return a concise answer with cited source links.
53
+
54
+ If the user asks for current framework or library guidance, prefer official docs by setting `includeDomains` when appropriate.
55
+
56
+ ## Helper script
57
+
58
+ Use the local helper script in this skill directory:
59
+
60
+ ```text
61
+ scripts/exa-api.cjs
62
+ ```
63
+
64
+ Run it with `node` and provide JSON through stdin, `--data`, or `--file`.
65
+
66
+ ### General form
67
+
68
+ ```bash
69
+ cat <<'JSON' | node scripts/exa-api.cjs <search|contents|findsimilar|answer|research>
70
+ { ...payload... }
71
+ JSON
72
+ ```
73
+
74
+ ## Payload examples
75
+
76
+ ### 1) Search
77
+
78
+ ```bash
79
+ cat <<'JSON' | node scripts/exa-api.cjs search
80
+ {
81
+ "query": "Latest research in LLMs",
82
+ "type": "auto",
83
+ "numResults": 10,
84
+ "category": "research paper",
85
+ "includeDomains": [],
86
+ "excludeDomains": [],
87
+ "startPublishedDate": "2025-01-01",
88
+ "endPublishedDate": "2025-12-31",
89
+ "includeText": [],
90
+ "excludeText": [],
91
+ "contents": {
92
+ "text": true,
93
+ "highlights": true,
94
+ "summary": true
95
+ }
96
+ }
97
+ JSON
98
+ ```
99
+
100
+ **Search types:**
101
+ - `neural` — semantic search using embeddings
102
+ - `fast` — faster keyword-oriented search
103
+ - `auto` — default unless you have a reason to force another mode
104
+ - `deep` — more exhaustive search
105
+
106
+ **Common categories:**
107
+ - `company`
108
+ - `people`
109
+ - `research paper`
110
+ - `news`
111
+ - `pdf`
112
+ - `github`
113
+ - `tweet`
114
+
115
+ ### 2) Contents
116
+
117
+ ```bash
118
+ cat <<'JSON' | node scripts/exa-api.cjs contents
119
+ {
120
+ "ids": ["result-id-1", "result-id-2"],
121
+ "text": true,
122
+ "highlights": true,
123
+ "summary": true
124
+ }
125
+ JSON
126
+ ```
127
+
128
+ ### 3) Find Similar
129
+
130
+ ```bash
131
+ cat <<'JSON' | node scripts/exa-api.cjs findsimilar
132
+ {
133
+ "url": "https://example.com/article",
134
+ "numResults": 10,
135
+ "category": "news",
136
+ "includeDomains": [],
137
+ "excludeDomains": [],
138
+ "startPublishedDate": "2025-01-01",
139
+ "contents": {
140
+ "text": true,
141
+ "summary": true
142
+ }
143
+ }
144
+ JSON
145
+ ```
146
+
147
+ ### 4) Answer
148
+
149
+ ```bash
150
+ cat <<'JSON' | node scripts/exa-api.cjs answer
151
+ {
152
+ "query": "What is the capital of France?",
153
+ "numResults": 5,
154
+ "includeDomains": [],
155
+ "excludeDomains": []
156
+ }
157
+ JSON
158
+ ```
159
+
160
+ ### 5) Research
161
+
162
+ ```bash
163
+ cat <<'JSON' | node scripts/exa-api.cjs research
164
+ {
165
+ "input": "What are the latest developments in AI?",
166
+ "model": "auto",
167
+ "stream": false,
168
+ "output_schema": {
169
+ "properties": {
170
+ "topic": {
171
+ "type": "string",
172
+ "description": "The main topic"
173
+ },
174
+ "key_findings": {
175
+ "type": "array",
176
+ "description": "List of key findings",
177
+ "items": {
178
+ "type": "string"
179
+ }
180
+ }
181
+ },
182
+ "required": ["topic"]
183
+ },
184
+ "citation_format": "numbered"
185
+ }
186
+ JSON
187
+ ```
188
+
189
+ ## API key configuration
190
+
191
+ The helper script checks for an API key in this order:
192
+
193
+ 1. `EXA_API_KEY` environment variable
194
+ 2. `.env` in this skill directory
195
+ 3. `.env` next to `scripts/exa-api.cjs`
196
+
197
+ Example `.env`:
198
+
199
+ ```dotenv
200
+ EXA_API_KEY=your_api_key_here
201
+ ```
202
+
203
+ ## Response handling
204
+
205
+ The helper returns JSON. Typical fields include:
206
+ - `requestId`
207
+ - `results`
208
+ - `searchType`
209
+ - `context`
210
+ - `costDollars`
211
+
212
+ After the helper runs:
213
+ - extract the most relevant findings
214
+ - cite source URLs clearly
215
+ - say when results are uncertain, sparse, or potentially stale
216
+ - prefer official documentation domains when the task is about APIs or framework behavior
217
+
218
+ ## Practical guidance
219
+
220
+ - Keep search queries specific and realistic.
221
+ - Use `includeDomains` for official docs when verifying APIs.
222
+ - Use `excludeDomains` to avoid noisy sources.
223
+ - Use `contents` when you already have Exa result IDs and need fuller text.
224
+ - Use `findsimilar` when the user gives a canonical page and wants adjacent resources.
225
+ - Use `research` only when the user truly needs structured synthesis.
226
+ - Do not dump raw JSON unless the user asks for it.
227
+
228
+ ## Output style
229
+
230
+ Return concise, decision-useful results:
231
+ - short summary first
232
+ - then key findings
233
+ - then source links
234
+ - mention limitations or uncertainty when relevant