Agent skill
research
Focused research investigations. Converts questions into structured findings with confidence levels and source citations. Does not make decisions — produces information that informs the next step.
Install this agent skill to your Project
npx add-skill https://github.com/SethGammon/Citadel/tree/main/skills/research
SKILL.md
/research — Focused Investigation
Identity
/research is for focused research investigations. It converts questions into structured findings with confidence levels. It does NOT make decisions or modify code — it produces information that informs the next step.
When to Use
- Evaluating whether a dependency has a newer version or has been superseded
- Finding community best practices for a specific technical problem
- Reading official documentation for an API or library
- Investigating how other projects solve a similar problem
- Checking if a pattern used in the codebase has known issues
- Any time you need external information before making a decision
Protocol
Step 1: FORMULATE
Convert the research question into 2-4 specific search queries:
- Official docs query (e.g., "express.js middleware error handling docs")
- Community/GitHub query (e.g., "express error middleware best practices site:github.com")
- Technical blog/comparison query (e.g., "express vs fastify error handling 2025")
- Release notes query if version-specific (e.g., "express 5.x changelog breaking changes")
State the question clearly in one sentence before searching.
Step 2: SEARCH
Execute searches and read actual content (not just snippets):
- Use WebSearch for discovery, WebFetch for reading actual pages
- Evaluate source credibility: official docs > GitHub repos with stars > recent blog posts > forum answers
- Stop at 3-6 credible sources (not exhaustive — focused)
- If a source contradicts another, note the disagreement
Step 3: EXTRACT
For each finding, record:
- What: The specific fact, recommendation, or pattern discovered
- Source: URL or reference
- Relevance: How this applies to the original question (one sentence)
- Confidence: high (official docs, verified), medium (community consensus), low (single source, opinion)
- Action: What the codebase should do with this information (or "informational only")
Step 4: WRITE
Write findings to .planning/research/{topic-slug}.md:
# Research: {Topic}
> Question: {The original question}
> Date: {ISO date}
> Confidence: {overall: high/medium/low}
## Findings
### 1. {Finding title}
**What:** {description}
**Source:** {URL}
**Confidence:** {high/medium/low}
**Action:** {recommendation or "informational"}
### 2. {Finding title}
...
## Summary
{2-3 sentences: what was learned, what the recommendation is}
## Open Questions
{Anything that couldn't be resolved — needs human judgment or deeper investigation}
Step 5: RETURN
Return the summary and recommendation to the caller (user, Marshal, or Archon). The research document persists for future reference.
What /research Does NOT Do
- Make architectural decisions (that's the caller's job)
- Install packages or modify code
- Search exhaustively (2-4 queries, 3-6 sources, done)
- Evaluate subjective opinions as facts
- Recommend without evidence
Fringe Cases
- No web access available: Fall back to local-only research. Search the codebase, read docs files, check
package.json, and produce findings from local sources. Note the limitation in the research document's confidence level. - Search returns nothing relevant: Broaden the query (remove version-specific terms, try synonyms), try one more angle. If still empty, report uncertainty explicitly: "No strong evidence found. Recommend human review."
.planning/research/does not exist: Create it before writing the findings document. Never error on a missing output directory.- Conflicting sources: Surface the conflict explicitly in the findings rather than silently picking one. Both sides belong in the document.
- Question is too broad for 3-6 sources: Narrow to the single most important sub-question, answer it well, and note what was scoped out. Suggest
/research-fleetfor multi-angle questions.
Quality Gates
- Every finding must have a source URL
- Confidence levels must be justified (not guessed)
- Summary must answer the original question or state why it can't be answered
- Research document must be written before returning findings
Exit Protocol
Output findings summary, then:
---HANDOFF---
- Research: {topic}
- Findings: {count} sources analyzed
- Recommendation: {one-line summary}
- Document: .planning/research/{slug}.md
---
Recommended Agent Skills
Expand your agent's capabilities with these related and highly-rated skills.
triage
GitHub issue and PR investigator. Pulls open issues/PRs, classifies them, searches the codebase for root cause or reviews contributed code, proposes fixes with file:line references, and optionally implements fixes. Handles both issues and pull requests.
infra-audit
Reads docker-compose, env files, ORM configs, and connection strings to map current infrastructure. Flags missing layers (cache, queue, analytics) based on observed access patterns. Outputs a structured infrastructure manifest.
fleet
Parallel campaign orchestrator. Runs multiple campaigns in coordinated waves within a single session. Spawns 2-3 agents per wave in isolated worktrees, collects discoveries, shares context between waves. Use when work decomposes into 3+ independent streams that can run simultaneously.
design
Generates and maintains a design manifest for visual consistency. In existing projects, reads current styles and documents the design language. In new projects, asks a few questions and generates a starter manifest. The post-edit hook reads the manifest and flags deviations.
test-gen
Generate and verify tests — happy path, edge cases, error paths — using the project's own framework and patterns
dashboard
Real-time harness observability dashboard. Reads campaigns, fleet sessions, telemetry, and pending queues to present a snapshot of harness state at a glance. Invoked by /dashboard, /do status, or phrases like "what's happening" and "show activity".
Didn't find tool you were looking for?