kagi-monitoring
Skill190 starsChanged 8 months agoMITView on GitHub
Automate repeated Kagi queries with batch search, watches, notifications, history, caching, and MCP. Use when the user needs bulk processing, scheduled discovery, change detection, or a stable integration surface.
We split this skill into the rules it gives an agent
10 rules. About 0 are common, 5 are distinctive, and 5 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈5
Distinctive · estimate
This author's own choices. Worth a look.
5
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 22
Run kagi auth status before automating authenticated commands.
- Distinctive: line 31
Use argument queries for short fixed sets and stdin for generated lists.
- Very specific: line 46
Use kagi notify --help to select the configured delivery target, then connect it to a watch or batch result.
- Very specific: line 52
Use kagi history to inspect local command records before duplicating work.
- Very specific: line 53
Use --local-cache only for calls where stale data is acceptable.
- Distinctive: line 58
Use the stdio server when another agent host needs Kagi tools:
- Distinctive: line 64
Keep MCP stdout reserved for protocol messages.
- Very specific: line 69
Prefer json, compact, or toon over pretty.
- Distinctive: line 71
Keep credentials in Kagi auth storage or environment variables, never scripts.
- Distinctive: line 74
Use a process supervisor or scheduler for long-running watches.
≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Kagi Monitoring and Automation
Build repeatable workflows from structured Kagi output. Keep stdout machine-readable and send progress or diagnostics to stderr.
Choose the workflow
| Need | Command |
| Run independent queries together | kagi batch |
| Detect changes in results | kagi watch |
| Deliver a result or alert | kagi notify |
| Inspect prior local activity | kagi history |
| Expose Kagi tools to an agent | kagi mcp |
Run kagi auth status before automating authenticated commands.
Batch search
kagi batch "rust" "zig" "go" --format toon --limit 3
printf 'rust\nzig\ngo\n' | kagi batch --format compactUse argument queries for short fixed sets and stdin for generated lists. Keep the query list as the recoverable input so a failed run can be repeated.
Watch search results
kagi watch "site:example.com release notes" --interval 300Define what counts as a meaningful change before starting a long-running watch. Use a descriptive query and an interval that matches how often the source updates.
Notifications
Use kagi notify --help to select the configured delivery target, then connect
it to a watch or batch result. Never put secrets in notification text or
command history.
History and caching
Use kagi history to inspect local command records before duplicating work.
Use --local-cache only for calls where stale data is acceptable. Never cache
research that must reflect a current price, release, outage, or policy.
MCP
Use the stdio server when another agent host needs Kagi tools:
kagi mcpKeep MCP stdout reserved for protocol messages. Treat a log written to stdout as a protocol-breaking bug.
Automation rules
- Prefer
json,compact, ortoonoverpretty. - Preserve nonzero exit codes instead of turning failure into empty output.
- Keep credentials in Kagi auth storage or environment variables, never scripts.
- Limit concurrency to what the endpoint and account can sustain.
- Record enough input to reproduce a failed item.
- Use a process supervisor or scheduler for long-running watches.
Completion criteria
Automation is complete when:
- inputs and outputs have stable machine-readable shapes;
- failures remain observable and retryable;
- credential values never appear in scripts or logs;
- cache and polling choices match the freshness requirement; and
- long-running processes have a clear owner and stop condition.
In this repository6 other files it gives its agents.
- docs/llms.txtllms.txt
- kagi-cliSkill
- kagi-account-configSkill
- kagi-aiSkill
- kagi-assistantSkill
- kagi-usageSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

