research-topic-summarize
Skill11 starsChanged 6 days agoMITView on GitHub
Use when asked to research a technology, library, or concept via web search, compare options (X vs Y), or gather background for a decision - synthesizes findings into a cited summary with comparison tables, screenshots of key visuals, and a recommendation
In this repository31 other files it gives its agents.
- architecture-diagrammingSkill
- at-risk-detectionSkill
- build-faq-from-issuesSkill
- context-aware-questionsSkill
- daily-planning-ritualSkill
- dependency-mappingSkill
- estimating-change-footprintSkill
- estimating-work-itemsSkill
- idea-to-designSkill
- issue-decompositionSkill
- markdown-formattingSkill
- mermaid-diagramsSkill
- prepare-meeting-agendaSkill
- project-analysisSkill
- project-planningSkill
- repairing-project-setupSkill
- requirement-elicitationSkill
- setting-up-a-projectSkill
- sgai-goalSkill
- stakeholder-trackingSkill
- stakeholder-updatesSkill
- summarize-conversation-threadSkill
- supervising-conductor-workspacesSkill
- supervising-paradev-workspacesSkill
- timeline-planningSkill
- triage-new-issuesSkill
- working-on-an-epicSkill
- working-on-an-issueSkill
- writing-product-specsSkill
- writing-user-storiesSkill
- writing-verification-plansSkill
The file
We split this skill into the rules it gives an agent
3 rules. About 0 are common, 2 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 86
Prefer official documentation over blog posts
- Very specific: line 104
Use descriptive filenames: redis-vs-memcached-comparison.png
- Distinctive: line 105
Always include alt text descriptions
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Research Topic and Summarize Skill
Conduct thorough web research on a topic, synthesize findings into a detailed summary, and capture screenshots of key visuals.
Prerequisites
- Web search/fetch access is required for the core research loop.
- Screenshots require a browser automation tool (e.g. Playwright MCP). If none is available, do not fake images — link to the visual's source URL and describe it in text instead of embedding an image.
When to Use
Activate when:
- Evaluating a technology, library, or tool
- Learning about a new concept or pattern
- Comparing options (X vs Y)
- Gathering background for a decision
When NOT to use: For deep, multi-source fact-checked reports, prefer a dedicated deep-research capability if one is available. Skip entirely for questions answerable from local docs or code — read those directly.
Output Structure
## Research: [Topic]
### Summary
[Paragraph overview - what it is, why it matters, current state]
### Background
[Context, history, or foundational concepts needed to understand the topic]
### Key Findings
#### [Finding 1 Title]
[Detailed explanation with specifics, numbers, examples]
#### [Finding 2 Title]
[Detailed explanation with evidence from sources]
### Comparisons
| Aspect | Option A | Option B |
|--------|----------|----------|
| [Criteria] | [Detail] | [Detail] |
### Visual References
-  — [what this shows]
-  — [what this shows]
### Sources
1. [Title](url) — [what this source contributed]
2. [Title](url) — [what this source contributed]
### Analysis
- **Strengths**: [detailed pros]
- **Weaknesses**: [detailed cons]
- **Gaps**: [what the research didn't answer]
### Recommendation
[Actionable conclusion with reasoning]Research Guidelines
Depth of Coverage
- Provide enough detail to make decisions without re-reading sources
- Include specific numbers, versions, dates when relevant
- Explain concepts, don't just name them
- Note conflicting information across sources
Source Quality
- Prefer official documentation over blog posts
- Note publication dates (flag outdated info)
- Cite sources for all claims
- Include 3-5 quality sources minimum
Screenshots
Capture screenshots when sources include:
- Architecture or flow diagrams
- Comparison tables
- Pricing or feature matrices
- UI examples (if evaluating tools)
- Code examples that benefit from visual context
Screenshot Best Practices
- Save screenshots to a
research-assets/directory alongside the summary file - Reference images in the summary with relative paths into that directory, e.g.
 - Use descriptive filenames:
redis-vs-memcached-comparison.png - Always include alt text descriptions
- Capture only relevant portions, not full pages
- Note the source URL in the description
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

