Each template below is a complete, self-contained contract for one research role. If you were dispatched here by tech-research, read only the section matching your role — you DO NOT need to read SKILL.md. The orchestrator already analyzed the question and chose your parameters.
Every subagent MUST return two sections in their report:
Each row: metric name, raw value, baseline/reference point, interpretation.
Baselines contextualize raw numbers — "500 stars" means nothing alone; "500 stars — top 5% for Rust ORMs" is actionable. Derive baselines from:
- Category norms discovered during research (e.g., "popular Rust web frameworks have 2k-15k stars")
- Peer comparison (versus other candidates in the same search)
- Temporal trends (e.g., "200 issues/month, up from 50/month 6 months ago")
- Industry thresholds (e.g., ">90% issue close rate is excellent, <50% is concerning")
Narrative analysis of intangible factors. Every claim MUST cite specific evidence: URL, username, date, quote, or data point. NO ungrounded assertions.
Use the format:
- Claim → evidence (URL or specific data) → implication for the research question
- Each qualitative finding must state confidence level: High (multiple corroborating sources), Medium (1-2 credible sources), Low (inference from indirect signals)
Subagents operate under context and tool-call constraints. Stay within these bounds:
| Role | Max tool calls | Notes |
|---|---|---|
| Developer Sentiment | 8-10 | 3-4 web_search, 3 read for deep-reading, 1-2 github searches |
| DeepWiki | 5-7 | Max 5 ask_question calls; use multi-repo queries when comparing |
| Web Intelligence | 6-8 | 3-4 web_search, 2-3 read for deep-reading |
| Repo Quality | 8 per repo | Combine searches where possible; max 3 repos in depth |
If comparing >3 candidates, focus depth on the top 3 based on initial signals (stars, recent activity, download counts). Mention remaining candidates briefly.
Role contract — self-contained. DO NOT read SKILL.md.
Parameters you will receive from the orchestrator:
RESEARCH_QUESTION— the topic to investigateSENTIMENT_QUERIES— pre-crafted search queries
Tools: web_search, github search_issues, github search_prs, read
Scope boundary: When researching a specific repo, focus on cross-repo mentions — discussions in other repos, Reddit, HN, forums, and blogs that reference the target. Do NOT query the target repo's own issues/PRs (that's a separate subagent's job).
Execute web searches scoped to developer discussion platforms. Elaborate, re-interpret, and re-contextualize RESEARCH_QUESTION with several distinct perspectives to enhance search coverage.
- Reddit:
web_searchfor"[topic] site:reddit.com","[topic] site:reddit.com inurl:r/programming", etc. — developer experience posts, comparison threads - Hacker News:
web_searchfor"[topic] site:news.ycombinator.com"— technical discussions, developer experience, praise, and gripes, etc. - Forums/Blogs:
web_searchfor"[topic] developer experience","[topic] migration","[topic] discussions","[topic] inurl:forum","[topic] inurl:thread", etc. - GitHub Discussions:
web_searchfor"[topic] site:github.com/discussions", etc. - GitHub Issues:
github search_issueswithrepo:[relevant-repo] [topic keywords]— real bug reports, feature requests, developer frustrations - GitHub PRs:
github search_prsfor adoption patterns — PRs migrating from one tool to another
Use read to fetch full content from the most promising URLs (Reddit threads, HN discussions, detailed blog posts). Extract specific quotes, usernames, dates, and context.
Return findings following the Universal Output Contract:
A. Quantitative Signals Table:
| Metric | Value | Baseline | Interpretation |
|---|---|---|---|
| Mention count (Reddit) | N posts | vs peer topics | |
| Mention count (HN) | N posts | vs peer topics | |
| Sentiment ratio | +N / -N / ~N | positive/negative/neutral | |
| Most recent discussion | date | recency of community interest | |
| GitHub issues mentioning topic | N | developer engagement level |
B. Qualitative Assessment:
- Developer pain points — with source URL and date
- Migration stories — who moved from/to what, and why (with citations)
- Community enthusiasm or fatigue signals
- Notable endorsements or warnings from recognized developers
- Each finding with confidence level (High/Medium/Low)
Role contract — self-contained. DO NOT read SKILL.md.
Parameters you will receive from the orchestrator:
RESEARCH_QUESTION— the topic to investigateREPO_LIST— one or moreowner/repostringsCUSTOM_QUESTIONS— optional topic-specific questions
Tools: mcp__deepwiki_ask_question, read
IMPORTANT: Do NOT use mcp__deepwiki_read_wiki_structure or mcp__deepwiki_read_wiki_contents. Always use mcp__deepwiki_ask_question directly — it provides faster, more focused answers without needing to browse the wiki structure first.
Call mcp__deepwiki_ask_question with focused questions:
- "What is the overall architecture of this repository?"
- "What are the core APIs and how do they work?"
- "What design patterns does this codebase use?"
- "How does [specific feature] work internally?"
CUSTOM_QUESTIONS— specific to the research topic
If comparing repos, ask parallel questions to enable direct comparison.
If mcp__deepwiki_ask_question returns empty, unhelpful, or generic results for a repo:
- Use
readonhttps://github.com/{owner}/{repo}to browse the repo landing page and README - Use
readon key source directories (e.g.,https://github.com/{owner}/{repo}/tree/main/src) to understand structure - Synthesize findings from direct source inspection instead
Return findings following the Universal Output Contract:
A. Quantitative Signals Table:
| Metric | Value | Baseline | Interpretation |
|---|---|---|---|
| Codebase modules/packages | N | vs similar projects | complexity indicator |
| Dependency count | N | vs peer projects | supply chain surface |
| API surface area | N exports/endpoints | breadth of interface | |
| Architecture layers | N | structural complexity |
B. Qualitative Assessment:
- Architectural patterns used — and whether they follow conventional modern best practices (with DeepWiki evidence)
- Code organization quality — module boundaries, separation of concerns
- Abstraction quality — leaky abstractions, over-engineering, or well-designed interfaces
- Idiomatic usage — does it follow language/ecosystem conventions?
- Each finding grounded in specific DeepWiki references with cited evidence
- Confidence level per finding (high/medium/low)
| Aspect | Repo A | Repo B |
|---|---|---|
| Architecture | [finding] | [finding] |
| API Design | [finding] | [finding] |
| Code Quality | [finding] | [finding] |
Role contract — self-contained. DO NOT read SKILL.md.
Parameters you will receive from the orchestrator:
RESEARCH_QUESTION— the topic to investigateTOPIC— keyword form for search queriesCURRENT_YEAR— for recency-scoped searches
Tools: web_search, read
Execute web_search queries:
"[TOPIC] comparison [CURRENT_YEAR]""[TOPIC] benchmark performance""[TOPIC] vs [ALTERNATIVE] pros cons""[TOPIC] official documentation""[TOPIC] tutorial getting started [CURRENT_YEAR]"
Use read to fetch full content from the most authoritative results — official docs, detailed benchmarks, well-researched comparison articles. Extract concrete data points.
Return findings following the Universal Output Contract:
A. Quantitative Signals Table:
| Metric | Value | Baseline | Interpretation |
|---|---|---|---|
| pypi downloads / npm weekly downloads / crates.io downloads | N | vs peer packages | adoption level |
| Bundle size | N KB | vs alternatives | |
| Benchmark result | N ops/sec | vs alternatives, with methodology | |
| Version release frequency | N/year | maintenance cadence | |
| Documentation coverage | qualitative |
B. Qualitative Assessment:
- Expert recommendations — with author credentials and URL
- Comparative analysis conclusions from authoritative sources — cited
- Known limitations or gotchas documented in official or third-party sources — cited
- Each finding with confidence level (High/Medium/Low)
Role contract — self-contained. DO NOT read SKILL.md.
Parameters you will receive from the orchestrator:
RESEARCH_QUESTION— the topic to investigateREPO_LIST— one or moreowner/repostrings to evaluate
Tools: github repo_view, github search_issues, github search_prs, read
Scope boundary: You own all queries scoped to the target repo itself — its issues, PRs, metadata, and source. Cross-repo mentions and community sentiment are handled by the Developer Sentiment subagent.
Systematically mine GitHub data to assess repository health, code quality, maintenance status, and community standards. Follow the 5-step protocol below for each repo in REPO_LIST.
For each repo, use github repo_view to collect:
- Stars, forks, watchers
- Description, topics/tags
- License type
- Last push date
Use github search_issues and search_prs:
- Recent issue activity:
repo:{owner}/{repo} is:issue created:>YYYY-MM-DD(last 90 days) - Issue responsiveness:
repo:{owner}/{repo} is:issue is:closedratio vsrepo:{owner}/{repo} is:issue is:open - Stale issues:
repo:{owner}/{repo} is:issue is:open updated:<YYYY-MM-DD(no activity 6+ months) - PR merge rate:
repo:{owner}/{repo} is:pr is:mergedvsrepo:{owner}/{repo} is:pr is:closed - Recent PR activity:
repo:{owner}/{repo} is:pr created:>YYYY-MM-DD(last 90 days) - Release cadence: search for release-related PRs or tags
Use read to inspect repo contents via GitHub URLs:
- CI config: check
.github/workflows/— has CI? - Linting/formatting config:
.eslintrc,biome.json,.prettierrc,rustfmt.toml, etc. - Type safety:
tsconfig.jsonstrict mode - Test presence:
test/,__tests__/,spec/directories - Dependency health:
package.json/Cargo.toml
Use github search_issues, search_prs, and read:
- Contributing guidelines:
CONTRIBUTING.md,CODE_OF_CONDUCT.md - Issue templates:
.github/ISSUE_TEMPLATE/ - PR review culture:
repo:{owner}/{repo} is:pr is:merged review:approved - Documentation quality: README completeness, API docs, examples
- Security practices:
repo:{owner}/{repo} is:issue label:security, Dependabot/Renovate PRs
Return findings following the Universal Output Contract:
A. Quantitative Signals Table (for each repo):
| Metric | Value | Baseline | Rating |
|---|---|---|---|
| Stars | N | "Top X% for [category]" or vs peers | |
| Last commit | date | "<30d=Active, 30-180d=Maintained, >180d=Stale, >365d=Abandoned" | |
| Issue close rate | N% | ">80% excellent, 50-80% adequate, <50% concerning" | |
| Median issue response time | Nd | "<7d=responsive, 7-30d=moderate, >30d=slow" | |
| PR merge rate | N% | vs peer repos | |
| Open issues (stale >6mo) | N | "<10% of total=healthy, >30%=warning" | |
| Has CI | Y/N | expected for production-grade | |
| Has linting/formatting | Y/N | expected for modern projects | |
| Has type checking (strict) | Y/N | expected for TS projects | |
| Test directory present | Y/N | expected for any serious project | |
| License | type | permissive preferred for most use cases | |
| CONTRIBUTING.md | Y/N | expected for community projects | |
| Release cadence | N/year | vs peer repos |
B. Qualitative Assessment:
- Maintainer engagement patterns — with evidence (specific issue/PR links)
- PR review culture — with evidence
- Documentation completeness — with evidence
- Security posture — with evidence
- Each finding with confidence level (High/Medium/Low)
Flag explicitly:
- No license
- Abandoned (no commits in 12+ months)
- No tests
- Known security issues
Green flags to highlight:
- Regular release cadence
- Responsive maintainers
- Strict typing / verification
- Comprehensive CI
When comparing multiple candidates, output a ranked comparison table with per-dimension ratings.