Research product and feature facts for developer documentation by mapping source-of-truth owners, validating behavior hands-on, interviewing SMEs, and turning uncertainty into doc-ready notes.
SkillScore77Maintained
Automatic
◆Doc Ops pack
Last verified 8/15/2026
What it changes
Passed 17 of 22 test cases with the skill, and 6 of 22 without it.
Without skill27%
With skill77%
Checks it passed that the model alone missed
The research brief explicitly identifies the target developer audience.
The research brief explicitly states the documentation decision needed.
The research brief highlights the instability risk for developer consumers.
and 17 more in the full report
11 fixed6 passed either way5 still failing0 broke
Pass-rate lift
+50 pp
Tokens
+13%
Agent turns
0%
Response time
-11%
Model gemini-3.6-flashMeasured 8/15/2026v117 of 22 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 11 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 11
Prompt
I am preparing developer documentation for our upcoming API gateway rate-limiting feature. Can you run a technical research pass on this? I need an initial research brief framing the question and scope, a list of verified technical facts with their source artifacts, an analysis of user consequences and potential developer pitfalls, a source map identifying domain owners, a breakdown of unresolved contradictions or testing gaps, and a recommended documentation action plan.
What was checked, without and with the skill
Checked
Without skill
With skill
The research brief section explicitly specifies the documentation question, target audience, and required decision.
Missed
Passed
The verified facts section includes specific source artifacts or verification methods for each stated fact.
Passed
Passed
The output includes a section outlining unresolved contradictions or missing test coverage.
Passed
Passed
case-01 · gemini-3.6-flash · 8/15/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md42 linessingle file
Developer Docs Technical Research
Use this skill to investigate product behavior before planning or writing developer documentation. It turns specs, code, prototypes, tickets, SMEs, and hands-on tests into traceable research notes.
This skill is derived from paraphrased guidance in Christopher Gales and the Splunk Documentation Team's The Product Is Docs: Writing Technical Documentation in a Product Development Group, especially Chapter 13, "Research for Technical Writers," Chapter 16, "Technical Verification," Chapter 19, "Working with Engineers," and Chapter 22, "Working with Product Management." Do not copy book prose into user outputs. Source: https://link.springer.com/book/10.1007/978-1-4842-7217-6
Quick Start
Load guidelines.md to choose the smallest useful reference set.
State the documentation question, audience, feature, release context, and risk.
Build a source map from code, product surfaces, specs, tickets, SMEs, QA, support, and existing docs.
Use workflows/research-feature-docs.md when feature behavior or user consequences are unclear.
Use workflows/interview-doc-sources.md when the main work is extracting facts from SMEs.
Return verified facts, assumptions, contradictions, source owners, and open questions.
Default Output
When completing a documentation research pass, return:
Research brief - doc question, audience, scope, and decision needed.
Verified facts - behavior, limits, defaults, prerequisites, permissions, errors, and examples with source.
User consequences - what readers can do, decide, risk, or misunderstand.
Source map - authoritative owner or artifact for each important fact.
Contradictions and gaps - unresolved disagreements, missing access, or untested behavior.