Technical Writing Style
Write like an engineer communicating with other engineers.
Principles
- Put the point first.
- Use short sentences.
- Be precise about files, commands, behavior, and impact.
- State uncertainty directly.
- Remove filler, hedging, corporate language, and AI-sounding phrasing.
- Do not add praise, apologies, or sign-offs unless the user asks.
- Preserve the intended audience, source language, necessary caveats, formatting, code blocks, commands, file paths, and literal values unless asked to change them.
Clarifying Questions
- Ask only when ambiguity changes the rewrite: audience, tone, language, formatting, length, or whether nuance must be preserved.
- Do not proceed on assumptions that could change meaning, compliance caveats, technical accuracy, or source language.
- Ask numbered questions with lettered options; option A must be recommended. Continue once the rewrite target is clear.
Do Not Trigger
- Public marketing pages, blogs, user docs, or README prose unless the user asks for direct engineering style.
- Rewrites that would remove necessary caveats, uncertainty, or compliance language.
Common Shapes
Code review comment:
[Problem.]
[Impact.]
[Specific fix or question.]
PR description:
## What
- [Concrete changes]
## Why
- [Problem solved]
## Verification
- [Commands/results]
## Risk
- [Known risk or "Low: ..."]
Output
If the user asks to rewrite text, return only the rewritten text unless they request explanation.
1---2name: technical-writing-style3description: Apply concise, direct engineering communication for engineering artifacts: PR comments, issue comments, code review feedback, commit messages, implementation summaries, status updates, and technical decisions. Use when the user asks to rewrite, shorten, make direct, or remove AI-sounding language from technical engineering text.4---56# Technical Writing Style78Write like an engineer communicating with other engineers.910## Principles1112- Put the point first.13- Use short sentences.14- Be precise about files, commands, behavior, and impact.15- State uncertainty directly.16- Remove filler, hedging, corporate language, and AI-sounding phrasing.17- Do not add praise, apologies, or sign-offs unless the user asks.18- Preserve the intended audience, source language, necessary caveats, formatting, code blocks, commands, file paths, and literal values unless asked to change them.1920## Clarifying Questions2122- Ask only when ambiguity changes the rewrite: audience, tone, language, formatting, length, or whether nuance must be preserved.23- Do not proceed on assumptions that could change meaning, compliance caveats, technical accuracy, or source language.24- Ask numbered questions with lettered options; option A must be recommended. Continue once the rewrite target is clear.2526## Do Not Trigger2728- Public marketing pages, blogs, user docs, or README prose unless the user asks for direct engineering style.29- Rewrites that would remove necessary caveats, uncertainty, or compliance language.3031## Common Shapes3233Code review comment:3435```markdown36[Problem.]3738[Impact.]3940[Specific fix or question.]41```4243PR description:4445```markdown46## What47- [Concrete changes]4849## Why50- [Problem solved]5152## Verification53- [Commands/results]5455## Risk56- [Known risk or "Low: ..."]57```5859## Output6061If the user asks to rewrite text, return only the rewritten text unless they request explanation.
gslava