Menu
Researches a topic using web search and documentation, producing structured reference notes
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
The SOLE WRITER to the V3.0 mem0 second brain. Invoked agentically by the executive at write moments — post-run, post-retro, post-spec-merge, manual /harvest. Decides which facts to classify into which memory type (principle/semantic/procedural/episodic/reflective), validates against the schema, and calls the deterministic plumbing in references/ via Bash. Blocks until writes are durable (poll event endpoint for SUCCEEDED). Never invoked from worker code.
Consult the V3.0 mem0 second brain agentically during executive planning, work selection, pre-spawn memory pack building, and failure diagnosis. Use this skill whenever the executive needs to remember prior runs, retros, or learned principles. Read-only — never writes. Drives the unified `mem0` CLI via Bash, orchestrating multiple iterative search queries (mem0 does not do multi-hop graph traversal natively, so iterative search IS the multi-hop).
Hook D — Failure-Diagnosis memory consultation. Runs at executive Phase 7 (after 3+ consecutive failures on a work item) BEFORE the failure-diagnosis skill itself runs. Consults the second brain for similar prior failures and successful retry strategies, then hands enriched context to the failure-diagnosis skill. Read-only. Invokes the memory-reader skill.
Hook E — Post-Retrospective Harvest. Runs after a retrospective markdown doc completes (per-run or weekly). Reads the retro fully and decides which durable lessons (reflective, semantic, procedural memories) to write to the second brain. Typically 3–8 writes per weekly retro, 0–3 per per-run retro. Invokes the memory-harvester skill for the actual writes.
Hook C — Post-Run Harvest. Runs after a worker completes (executive Phase 6 success path). Decides agentically which facts from the run to write to the second brain — typically 0–3 memory writes per run (one episodic, optionally a semantic or procedural). Invokes the memory-harvester skill to do the actual writes (with event-polling for durability).
Hook B — Pre-Spawn Memory Pack build. Runs before each worker spawn (executive Phase 4 prep). Reads the second brain for project-specific memories and produces a Memory Pack markdown block that worker-spawner injects into the worker's generated CLAUDE.md. Workers consume this as static markdown — they never call mem0 themselves. Read-only. Invokes the memory-reader skill.
| name | research |
| description | Researches a topic using web search and documentation, producing structured reference notes |
Conduct thorough research on a topic and produce structured reference notes.
{{TOPIC_ID}} — Unique identifier for this topic.{{TOPIC_TITLE}} — Human-readable title of the topic.{{TOPIC_DESCRIPTION}} — Description of what this topic covers and its scope.{{OUTPUT_PATH}} — File path where the research markdown will be written.Plan the research.
Search and gather.
Extract and organize.
Write structured output.
Write a markdown file to {{OUTPUT_PATH}} with this structure:
# {{TOPIC_TITLE}}
**Topic ID:** {{TOPIC_ID}}
**Researched:** [ISO 8601 timestamp]
## Overview
[2-3 paragraph summary of what this topic is, why it matters, and where it fits
in the broader domain. Use inline citations for key claims, e.g. "The maximum
context window is 200K tokens [1]." Suitable for someone encountering this
topic for the first time.]
## Key Concepts
[Bulleted list of the essential concepts. Each bullet should have a bold term
followed by a clear explanation with inline citations. Aim for 5-10 key concepts.
Example: "- **Tool Use** — Allows Claude to call external functions during a
conversation [2]. Supports up to 128 tools per request [1]."]
## Technical Details
[Deeper technical content: architecture, protocols, APIs, configuration
options, parameters. Include code blocks or command examples where relevant.
Cite the source for each code example or configuration snippet.]
## Common Patterns
[How this topic is typically applied in practice. Real-world scenarios,
standard configurations, best-practice architectures. Include concrete
examples with citations.]
## Gotchas
[Things that commonly trip people up. Misconceptions, subtle distinctions,
easy-to-confuse options, version-specific differences. Cite sources when
noting version-specific or source-specific differences.]
## Sources
[1] **Source Title**
URL: https://example.com/...
Accessed: [ISO 8601 date]
Relevance: primary | supplementary | background
Extracted: [Brief summary of what facts/concepts were taken from this source]
[2] **Source Title**
URL: https://example.com/...
Accessed: [ISO 8601 date]
Relevance: primary | supplementary | background
Extracted: [Brief summary of what facts/concepts were taken from this source]
[n] format where n is the source number from the Sources section.Claude supports tool use with up to 128 tools per request [1].The recommended approach combines streaming with tool use [1][3].The following pattern is from the official cookbook [2]: followed by the code block.[1], [2], etc.) and include structured metadata: title, URL, access date, relevance level, and a brief summary of what was extracted.