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.
- package/dist/dotfiles/AGENTS.md +197 -0
- package/dist/dotfiles/APPEND_SYSTEM.md +78 -0
- package/dist/dotfiles/agent-modes.json +12 -0
- package/dist/dotfiles/agent-skills/exa-search/.env.example +4 -0
- package/dist/dotfiles/agent-skills/exa-search/SKILL.md +234 -0
- package/dist/dotfiles/agent-skills/exa-search/scripts/exa-api.cjs +197 -0
- package/dist/dotfiles/auth.json.template +5 -0
- package/dist/dotfiles/damage-control-rules.yaml +318 -0
- package/dist/dotfiles/extensions/btw.ts +1031 -0
- package/dist/dotfiles/extensions/commit-approval.ts +590 -0
- package/dist/dotfiles/extensions/context.ts +578 -0
- package/dist/dotfiles/extensions/control.ts +1748 -0
- package/dist/dotfiles/extensions/damage-control/index.ts +543 -0
- package/dist/dotfiles/extensions/damage-control/node_modules/.package-lock.json +22 -0
- package/dist/dotfiles/extensions/damage-control/package-lock.json +28 -0
- package/dist/dotfiles/extensions/damage-control/package.json +7 -0
- package/dist/dotfiles/extensions/dirty-repo-guard.ts +56 -0
- package/dist/dotfiles/extensions/exa-enforce.ts +51 -0
- package/dist/dotfiles/extensions/exa-search-tool.ts +384 -0
- package/dist/dotfiles/extensions/execute-command/index.ts +82 -0
- package/dist/dotfiles/extensions/files.ts +1112 -0
- package/dist/dotfiles/extensions/loop.ts +446 -0
- package/dist/dotfiles/extensions/pr-approval.ts +730 -0
- package/dist/dotfiles/extensions/qna-interactive.ts +532 -0
- package/dist/dotfiles/extensions/question-mode.ts +242 -0
- package/dist/dotfiles/extensions/require-session-name-on-exit.ts +141 -0
- package/dist/dotfiles/extensions/review.ts +2091 -0
- package/dist/dotfiles/extensions/session-breakdown.ts +1629 -0
- package/dist/dotfiles/extensions/term-notify.ts +150 -0
- package/dist/dotfiles/extensions/tilldone.ts +527 -0
- package/dist/dotfiles/extensions/todos.ts +2082 -0
- package/dist/dotfiles/extensions/tools.ts +146 -0
- package/dist/dotfiles/extensions/uv.ts +123 -0
- package/dist/dotfiles/global-skills/brainstorm/SKILL.md +10 -0
- package/dist/dotfiles/global-skills/cli-detector/SKILL.md +192 -0
- package/dist/dotfiles/global-skills/gh-issue-creator/SKILL.md +173 -0
- package/dist/dotfiles/global-skills/google-chat-cards-v2/SKILL.md +237 -0
- package/dist/dotfiles/global-skills/google-chat-cards-v2/references/bridge_tap_implementation.md +466 -0
- package/dist/dotfiles/global-skills/technical-docs/SKILL.md +204 -0
- package/dist/dotfiles/global-skills/technical-docs/references/diagrams.md +168 -0
- package/dist/dotfiles/global-skills/technical-docs/references/examples.md +449 -0
- package/dist/dotfiles/global-skills/technical-docs/scripts/validate_docs.py +352 -0
- package/dist/dotfiles/global-skills/whats-new/SKILL.md +159 -0
- package/dist/dotfiles/intercepted-commands/pip +7 -0
- package/dist/dotfiles/intercepted-commands/pip3 +7 -0
- package/dist/dotfiles/intercepted-commands/poetry +10 -0
- package/dist/dotfiles/intercepted-commands/python +104 -0
- package/dist/dotfiles/intercepted-commands/python3 +104 -0
- package/dist/dotfiles/mcp.json.template +32 -0
- package/dist/dotfiles/models.json +27 -0
- package/dist/dotfiles/settings.json +25 -0
- package/dist/index.js +1344 -0
- 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,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
|