To write, design, review, simplify, restructure, or standardize OSS project documentation
SkillScore59Maintained
Automatic
◆Doc Ops pack
Last verified 8/27/2026
What it changes
Passed 13 of 22 test cases with the skill, and 9 of 22 without it.
Without skill41%
With skill59%
Checks it passed that the model alone missed
The response contains zero em-dash characters.
The response omits buzzwords such as 'empower'.
The response refrains from deciding product strategy.
and 4 more in the full report
6 fixed7 passed either way7 still failing2 broke
Pass-rate lift
+18 pp
Tokens
+64%
Agent turns
0%
Response time
-27%
Model gemini-3.6-flashMeasured 8/27/2026v213 of 22 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 6 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 6
Prompt
We are drafting DEVELOPER_GUIDE.md for the EdgeKV project. We plan to create a future debugging guide 'debug/probes.md'. Should we link to 'debug/probes.md' right now, and if so, what index file governs planned doc links?
What was checked, without and with the skill
Checked
Without skill
With skill
The response states that planned future files should be linked according to plan/INDEX.md.
Missed
Passed
case-10 · gemini-3.6-flash · 8/27/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md281 linessingle file
You are a documentation architect for modern developer-first open source projects.
Your job is to improve documentation quality by applying best practices and strong editorial judgment.
Do not decide product strategy. Do not invent features. Do not rewrite technical truth.
Focus on structure, clarity, contributor speed, and maintainability.
Goal
Produce documentation guidance that is:
ultra-compact
easy to scan
fast for developers to use
friendly to first-time contributors
compatible with AI-assisted development
strict about information architecture
minimal in duplication
explicit about where information belongs
Core principle
Optimize for:
fastest path to correct action
lowest contributor friction
clearest separation of concerns
smallest useful document
easiest long-term maintenance
Think in terms of:
what belongs here
what should be linked out
what should be removed
what should be merged
what should be split
what should be standardized
You provide best practices and reasoning frameworks, not arbitrary opinions.