research

Vendor reference repositories as git submodules and write structured research memos.

37|17|Updated May 4, 2025
One-click install
npx skills add https://github.com/milvus-io/milvus-workshop --skill research-milvus-io
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: research
Source: https://github.com/milvus-io/milvus-workshop/tree/main/agent/.agents/skills/research
Command: npx skills add https://github.com/milvus-io/milvus-workshop --skill research-milvus-io

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Engineering teams often design or implement features without deeply understanding prior art, leading to spec drift, rework, and unverified assumptions. This Skill captures upstream knowledge rigorously by vendoring reference repositories and producing load-bearing research memos that specs and implementations can cite. ## Core Features & Use Cases - Repository Vendoring: Adds upstream repos as git submodules under ./vendors, pinned to specific commits for reproducible citation. - Three Memo Types: Produces spike memos (single time-boxed questions validated with runnable code), study memos (deep architectural dives with file:line citations), and survey memos (web/docs research with dated sources). - Structured Templates & Diagrams: Enforces memo templates with architecture maps, hot-path walkthroughs, ASCII diagrams, and explicit adopt/avoid decisions. - Use Case: Before designing a logging subsystem, ask the agent to study how tokio-rs/tracing resolves dispatchers; it vendors the repo, reads the hot path, and writes docs/research/study-tracing-dispatcher.md with cited evidence. ## Quick Start Use the research skill to vendor the tokio-rs/tracing repository and write a study memo on how it resolves the dispatcher per call site.

Frequently Asked Questions about research

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I research how an open source library works before using it?

Vendor the repository as a git submodule under ./vendors, pin it to a specific commit, then read it in three passes: module map, hot path, and edge cases. Write a study memo citing exact file paths and line numbers so others can verify claims.

What is the difference between a spike, study, and survey memo?

A spike answers one time-boxed question with a runnable artefact, a study is a deep architectural dive into vendored code with line citations, and a survey covers web or docs research where vendoring is not warranted. Pick the narrowest kind that fits the question.

How do I vendor a GitHub repository as a git submodule?

Run git submodule add <url> vendors/<name> followed by git submodule update --init --recursive. Pin the exact commit with git -C vendors/<name> rev-parse HEAD and record it in the memo header for reproducibility.

When should I vendor a repo instead of just reading its documentation?

Vendor whenever you need grep, read, or git-blame access to upstream internals to verify behavior claims. For pure API browsing without reading internals, generated documentation like cargo doc is sufficient.

What makes a research memo complete and reliable?

A memo is done when a reader who never opened the vendored repo can answer the memo's question and cite the upstream lines justifying it. Every behavior claim needs a file path and line number, and every performance claim needs a number with units and the bench harness used.