Passed 19 of 22 test cases with the skill, and 18 of 22 without it.
Without skill82%
With skill86%
Checks it passed that the model alone missed
The checklist must include explicit reviewer approval before release.
1 fixed18 passed either way3 still failing0 broke
Pass-rate lift
+5 pp
Tokens
+12%
Agent turns
0%
Response time
-24%
Model gemini-3.6-flashMeasured 8/16/2026v119 of 22 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
A test case the skill fixed. Same model, same prompt, with and without the skill.
Prompt
Our open-source SDK project has a shared community docs folder, but PRs sit unreviewed for weeks because nobody is explicitly assigned to maintain them. When setting up our docs publishing checklist for the upcoming v3.0 launch, how should ownership and review roles be defined?
What was checked, without and with the skill
Checked
Without skill
With skill
Every maintained document must have a designated owner or explicit source of truth.
Passed
Passed
The checklist must include explicit reviewer approval before release.
Missed
Passed
case-03 · gemini-3.6-flash · 8/16/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md44 linessingle file
Docs Release Maintenance
Use this skill to keep developer documentation aligned with software release and maintenance lifecycles. It covers publishing readiness, ownership, automation, freshness, and responsible deprecation or deletion.
This skill is derived from Docs for Developers: An Engineer's Field Guide to Technical Writing, especially Chapter 7, "Publishing documentation," and Chapter 11, "Maintaining and deprecating documentation." It is expanded with paraphrased guidance from Christopher Gales and the Splunk Documentation Team's The Product Is Docs: Writing Technical Documentation in a Product Development Group, especially Chapter 10, "Maintaining Existing Content," Chapter 25, "Writing SaaS Documentation," and Chapter 2, "Agile." 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.
Identify the release, affected users, docs owners, source of truth, and publication path.
Use workflows/plan-doc-release-maintenance.md for release or maintenance planning.
Use workflows/refresh-existing-docs.md when stale content, patch buildup, or dependency updates require a focused refresh.
Align doc publication, review, testing, announcement, and deprecation with code changes.
Prefer automation that removes known toil; do not automate an unclear process.
Default Output
When planning release or maintenance work, return:
Release or maintenance scope - code/product change and affected docs.
User impact - who is affected and what action they need.