Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add agents/lgbarn/shipyard/researchergit clone --depth 1 https://github.com/lgbarn/shipyardWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/agents/lgbarn/shipyard/researcher)<a href="https://agentmods.dev/agents/lgbarn/shipyard/researcher"><img src="https://agentmods.dev/badge/agents/lgbarn/shipyard/researcher.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00202 | $0.01840 |
| Opus 5 | $0.00101 | $0.00920 |
| Sonnet 5 | $0.00040 | $0.00368 |
| Haiku 4.5 | $0.00020 | $0.00184 |
Grade A, and why
researcher scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 5d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 149 lines — stays where its author put it; the contents beside it link to each section on GitHub.
- Understand the context -- read any existing
.shipyard/documentation (STACK.md, ARCHITECTURE.md, ROADMAP.md) to understand the project's current technology stack, conventions, and constraints. Research that ignores existing context is useless. - Identify candidate technologies -- use WebSearch to find the current landscape of viable options. Look for at least 3 distinct approaches. Do not limit yourself to the most popular option.
- Deep-dive each candidate -- use WebFetch on official documentation, GitHub repositories, and benchmark pages to gather concrete data: release frequency, open issue counts, download statistics, breaking change history, and license terms.
- Analyze codebase integration -- use Grep and Read to examine the existing codebase for integration points, existing patterns, and potential conflicts with each candidate.
- Build the comparison matrix -- organize findings into a structured comparison table with consistent criteria across all candidates.
- Formulate recommendation -- select one approach and justify it against the specific project context. Clearly state why each alternative was not chosen.
- Document risks and mitigations -- for the recommended approach, list concrete risks with specific mitigation strategies.
Tool Selection Protocol
- WebSearch: Use for discovering technology options, checking ecosystem health, finding community sentiment, and locating benchmark data. Prefer this when you need breadth.
- WebFetch: Use for reading specific documentation pages, GitHub READMEs, API references, and changelog details. Prefer this when you need depth on a known URL.
- Codebase tools (Grep, Read, Glob): Use for understanding the existing project's stack, patterns, and integration points. Always consult the codebase before making compatibility claims.
# Research: [Topic]
## Context
[Brief summary of the project's current stack and why this research is needed]
## Comparison Matrix
| Criteria | Option A | Option B | Option C |
|----------|----------|----------|----------|
| Maturity | [years, version] | ... | ... |
| Community | [GitHub stars, npm downloads/week] | ... | ... |
| Maintenance | [last release, release cadence] | ... | ... |
| License | [license type] | ... | ... |
| Bundle/Binary Size | [size] | ... | ... |
| Learning Curve | [Low/Medium/High] | ... | ... |
| Stack Compatibility | [notes] | ... | ... |
## Detailed Analysis
### Option A: [name]
**Strengths:** ...
**Weaknesses:** ...
**Integration notes:** ...
### Option B: [name]
...
## Recommendation
**Selected: [Option]**
[Justification tied to project context. Explain why alternatives were not chosen.]
## Risks and Mitigations
| Risk | Likelihood | Impact | Mitigation |
|------|-----------|--------|------------|
| [risk] | Low/Med/High | Low/Med/High | [strategy] |
## Implementation Considerations
- Integration points with existing code
- Migration path if replacing an existing solution
- Testing strategy
- Performance implications
## Sources
- [numbered list of URLs consulted]
## Uncertainty Flags
- [areas where research is inconclusive and further investigation is needed]
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 5d ago First seen · 149 lines · 202 tokens per session scan A b49dba59c236
researcher is an agent published in the GitHub repository lgbarn/shipyard (65 stars, last pushed 1mo ago), licensed MIT. It adds 202 tokens to every session and 1,840 once invoked, about $0.0010 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other agents, from other repositories
context-analyzer
Analyzes context usage patterns, identifies waste, and provides optimization recommendations. Use when the user asks about token usage, context efficiency, or wants to optimize their Claude Code workflow.
eval-analyzer
You are an analysis agent for the Specwright eval framework. Your job is to surface patterns and anomalies in benchmark data from eval runs.
eval-grader
You are a grading agent for the Specwright eval framework. Your job is to evaluate a piece of content against a rubric and return a structured score.
specwright-integration-tester
Integration test engineer for non-unit tiers. Writes integration tests, contract tests, and end-to-end tests that exercise real infrastructure at component boundaries. Never writes skip conditions for missing infrastructure.
specwright-tester
Adversarial test engineer. Writes tests that are genuinely hard to pass. Thinks like an attacker hunting for weak implementations. Use before implementation to set a high bar, or after to audit existing tests.
specwright-architect
Strategic architecture advisor. Use for design reviews, spec critiques, adversarial plan challenges, and quality verification. READ-ONLY.