SKILL.md


name: researching-with-rumilo description: Dispatches AI research subagents via rumilo to search the web or explore git repositories. Use when the user asks to research a topic, look up library usage, explore a codebase, read documentation from the web, or when you need information from an external repository or website to complete a task. license: GPL-3.0-or-later metadata: author: Amolith amolith@secluded.site

rumilo spawns disposable AI subagents for two kinds of research: web search and repo exploration. Each mode runs in isolation and returns a synthesised answer on stdout.

Important: timeouts

RΓΊmilo is an LLM-based subagent that may take multiple turns to complete its research. Never impose a timeout.

Modes

Web mode

Search the internet or ask questions about a specific page.

# Open-ended search (no URL)
rumilo web "what is the current stable version of Zig"

# Question about a specific page (URL pre-fetched into context)
rumilo web "how does the slog package handle log levels" -u "https://pkg.go.dev/log/slog"
  • Without -u, the agent searches the web on its own.
  • With -u, the URL is fetched first and injected into the agent's context alongside the query, so it can answer questions about that page.

Repo mode

Clone a git repository into a temp directory, spawn an agent inside it, and let it explore the source to answer questions.

# Public repo
rumilo repo -u "https://github.com/owner/repo" "How does the routing system work?"

# Private repo (works with any clonable URI β€” SSH, HTTPS with auth, etc.)
rumilo repo -u "git@git.sr.ht:~user/repo" "What does the Config struct look like?"

The -u flag is required in repo mode β€” it needs something to clone.

Flags

Flag Modes Effect
-u <url> both Seed URL (web) or clone URI (repo)
--model <provider:model> both Override the configured default model
--ref <ref> repo Checkout a branch, tag, or commit after cloning (requires --full)
--full repo Full clone instead of shallow (depth 1)
--no-cleanup both Keep the temp workspace after exit
--verbose both Print tool calls and results to stderr

Crafting queries

Rumilo works best with focused queries. Think about scope and coupling when deciding what to ask and how many questions to include.

  • Tightly coupled, narrow scope β€” multiple simple questions in one call is fine when they're about the same small surface area (a single file, one struct, one API endpoint).
  • Broad scope or loose coupling β€” one question per invocation. If answering requires exploring many files or pages, keep it to a single clear question so the agent can focus.
  • Write natural questions, not keyword lists. Rumilo is an LLM, not a search index.
  • Sequence calls when later questions depend on earlier answers. Get the overview first, then drill in. Rumilo is amnesic β€” each invocation starts fresh. If a later query depends on an earlier answer (repo URL, version number, file paths), you must include that context explicitly in the prompt.
  • Run independent queries in parallel (e.g. via separate tmux windows or backgrounded commands), but keep dependent queries sequential.

Bad

Overloaded β€” five loosely-coupled questions spanning an entire diff, each requiring different context:

rumilo web "In this diff, find: 1. What files are modified and created \
2. What config options each channel exposes 3. How messages are formatted \
4. The architecture for adding a new channel 5. What UI components exist" \
  -u "https://example.com/commit/abc123.diff"

Good

Sequenced calls, each with a clear scope. Later calls include non-obvious context from earlier results β€” file paths, symbol names, patterns β€” so rumilo can go straight to the answer instead of searching.

# 1. Lay of the land β€” broad overview first
rumilo web "What files were modified or created, and what's the broad shape of the change?" \
  -u "https://example.com/commit/abc123.diff"

# 2a and 2b can run in parallel β€” neither depends on the other,
#    but both benefit from context learned in step 1.

# 2a. Architecture deep-dive, pointing to the key file discovered in step 1
rumilo web "How is the notification system in pkg/notify/ architected? \
  Each channel seems to implement a Sender interface β€” what's the process \
  for adding a new one?" \
  -u "https://example.com/commit/abc123.diff"

# 2b. Config drill-down, referencing the settings struct found in step 1
rumilo web "What configuration options does each channel expose in \
  ChannelSettings? Can message content be customised?" \
  -u "https://example.com/commit/abc123.diff"

# 3. UI specifics, narrowed by what steps 1–2 revealed about the component tree
rumilo web "The channel config UI lives in web/src/components/settings/channels/. \
  Do the per-channel forms follow a shared pattern or component?" \
  -u "https://example.com/commit/abc123.diff"

Don't include context that's obvious or redundant β€” telling rumilo to "search for notif" when asking about notifications wastes tokens. Focus on non-obvious anchors: exact file paths, struct names, interface signatures.

Tightly coupled questions in a single call are fine when the scope is small:

rumilo repo -u "https://github.com/owner/repo" \
  "What fields does the Config struct have and which are optional?"

Choosing a mode

  • Need to find or learn about a library? Web to locate it, then repo to explore its source.
  • Need to understand how a dependency works in detail? Repo with the dependency's clone URL.
  • Need current docs, release notes, or general knowledge? Web, optionally with the URL of a relevant page.