Use for technical communication - GitHub/GitLab tickets, PR/MR descriptions, issue comments, code review comments, commit messages. Direct, brief style with no AI-speak. NOT for README.md, public docs, or blog posts.
SkillScore95Maintained
Automatic
◆Writing & Editing pack
Last verified 8/20/2026
What it changes
Passed 21 of 22 test cases with the skill, and 15 of 22 without it.
Without skill68%
With skill95%
Checks it passed that the model alone missed
Uses a form of the verb 'decide'.
Does not use the word 'streamline'.
Begins the answer directly with 'Yes'.
and 3 more in the full report
6 fixed15 passed either way1 still failing0 broke
Pass-rate lift
+27 pp
Tokens
+54%
Agent turns
0%
Response time
-44%
Model gemini-3.6-flashMeasured 8/20/2026v121 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
Write an internal PR comment asking the author whether they chose to deprecate the v1 endpoint or keep it active in `handlers/v1.go`.
What was checked, without and with the skill
Checked
Without skill
With skill
Does not use the phrase 'make a decision'.
Passed
Passed
Uses a form of the verb 'decide'.
Missed
Passed
case-11 · gemini-3.6-flash · 8/20/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md163 linessingle file
Technical Communication Style Guide
User Override Check
Before applying this guide, check if the user already has their own writing-style rules:
Check CLAUDE.md files (project-level and user-level) for writing style sections (look for "writing style", "communication style", "tone", "comment style" headings or similar)
Check if the user has a custom writing-style skill defined in their own skills directory
If user-defined writing rules exist: defer to those rules entirely. Do not apply this guide. Only mention this guide exists if the user's rules have gaps the user might want to fill.
If no user-defined rules exist: apply this guide as the default.
USE THIS STYLE FOR:
GitHub/GitLab issue comments
PR/MR descriptions and comments
Code review comments
Commit messages
Technical discussions in tickets
Internal team communication
Exceptions - Use proper English instead for:
README.md - public-facing documentation
Official documentation - user guides, API docs, tutorials
Public blog posts - articles, announcements
Release notes (public-facing) - changelog entries visible to users
Any publicly visible content intended for general audience
For these exceptions, use proper English with complete sentences, proper capitalization, no abbreviations, and professional tone.
Core Principles
Brevity and Directness
Get straight to the point
Skip filler phrases and unnecessary context
Short responses are fine when they convey the full message
Skip "I hope this helps" or "let me know if you have questions"