Structured co-authoring workflow for PRDs, design docs, RFCs, decision docs, proposals, and any substantial written document.
SkillScore70Maintained
Automatic
◆Doc Ops pack
Last verified 8/4/2026
What it changes
Passed 16 of 23 test cases with the skill, and 13 of 23 without it.
Without skill57%
With skill70%
Checks it passed that the model alone missed
Asks for the primary audience of the document.
Refuses to generate the full document at once.
Focuses drafting on a single section at a time.
and 9 more in the full report
6 fixed10 passed either way4 still failing3 broke
Pass-rate lift
+13 pp
Tokens
+122%
Agent turns
0%
Response time
-43%
Model gemini-3.6-flashMeasured 8/4/2026v116 of 23 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've gone through 3 iteration rounds on the Technical Approach section of our architecture spec and no major structural changes were made. What step should we take now?
What was checked, without and with the skill
Checked
Without skill
With skill
Asks whether any text or sentences can be removed without losing meaning.
Missed
Passed
case-15 · gemini-3.6-flash · 8/4/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md329 linessingle file
Document Co-Authoring
Writing a document alone produces a document that makes sense to the author. Co-authoring produces a document that makes sense to the reader. This skill is the difference between the two.
You are an active guide, not a passive typist. You ask questions before writing. You brainstorm before drafting. You test the document against a reader before declaring it done. Every section goes through: clarify → brainstorm → curate → draft → refine.
Co-Authoring Principles
Context first, writing second. A document written without sufficient context will be rewritten. Spend time gathering context — it is never wasted.
Brainstorm before drafting. Generating options before committing produces better decisions. Never jump straight from question to final prose.
One section at a time. Trying to write the whole document at once produces mediocre everything. Perfect one section, then move to the next.
The reader is not in the room. Everything the author knows implicitly, the reader does not. Surfaces those assumptions, names them, and either explains them or removes them.
Reader testing is not optional. Authors cannot find their own blind spots. A fresh reader (or a fresh AI instance with no context) will find what the author cannot.
Documents must earn every sentence. If a sentence can be removed without losing meaning, remove it. Dense, precise prose is harder to write and easier to read.
When to Use This Skill
Trigger conditions:
"Write a PRD for..."
"Help me draft a design doc"
"I need to write an RFC"
"Can you write up a one-pager on..."
"I need a decision doc for..."
"Help me write a technical spec"
Any substantial document where quality matters (not quick memos — use internal-comms for those)