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.