agentleFS
MicrockMicrock/kagi-cli/skills/kagi-monitoring/SKILL.md

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
  1. Very specific:

    Run kagi auth status before automating authenticated commands.

    line 22
  2. Distinctive:

    Use argument queries for short fixed sets and stdin for generated lists.

    line 31
  3. Very specific:

    Use kagi notify --help to select the configured delivery target, then connect it to a watch or batch result.

    line 46
  4. Very specific:

    Use kagi history to inspect local command records before duplicating work.

    line 52
  5. Very specific:

    Use --local-cache only for calls where stale data is acceptable.

    line 53
  6. Distinctive:

    Use the stdio server when another agent host needs Kagi tools:

    line 58
  7. Distinctive:

    Keep MCP stdout reserved for protocol messages.

    line 64
  8. Very specific:

    Prefer json, compact, or toon over pretty.

    line 69
  9. Distinctive:

    Keep credentials in Kagi auth storage or environment variables, never scripts.

    line 71
  10. Distinctive:

    Use a process supervisor or scheduler for long-running watches.

    line 74

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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

NeedCommand
Run independent queries togetherkagi batch
Detect changes in resultskagi watch
Deliver a result or alertkagi notify
Inspect prior local activitykagi history
Expose Kagi tools to an agentkagi 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 compact

Use 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 300

Define 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 mcp

Keep MCP stdout reserved for protocol messages. Treat a log written to stdout as a protocol-breaking bug.

Automation rules

  • Prefer json, compact, or toon over pretty.
  • 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.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.