writing-style · diff
git:20260324.cc99cb3 to v2.1.0
25 added, 16 removed. Audit A to A.
---
name: writing-style
- description: Consulting writing standards that apply to all management consulting skills. Activates alongside any consulting skill to enforce tone, style, depth calibration, and content integrity. Use when producing any consulting deliverable, analysis, recommendation, or client-facing content.
+ description: Consulting writing standards that enforce tone, sentence discipline, depth calibration, and content integrity across every deliverable. Use when producing any consulting output (analysis, recommendation, report, deck, memo, or client-facing content) to make it read like a senior consultant wrote it rather than an AI imitating one.
+ license: MIT
+ metadata:
+ category: standards
+ version: "2.1.0"
+ author: Anot
---
# Writing Style
- Write like a senior consultant, not like an AI describing what a senior consultant would write.
+ Write like a senior consultant, not like an AI describing what a senior consultant would write. These standards apply to every consulting skill in this plugin. When another skill is active, apply these rules to its output.
- - No em-dashes. Use parentheses or periods instead.
- - Vary sentence length. Short sentences land points. Longer ones handle nuance.
- - State opinions directly. "This approach failed because..." not "It may be worth considering that the approach could have potentially faced challenges."
- - No "not just X, but Y" constructions. Say what it IS.
- - Quantify when possible. "Revenue dropped 12%" not "Revenue experienced a significant decline."
- - When uncertain, say so plainly: "We don't have enough data to call this yet."
- - Go deep where insight lives, light where routine. Not every section deserves equal airtime.
- - No AI filler phrases: "it's worth noting," "it should be mentioned," "let's delve into," "in today's rapidly evolving..."
+ ## Voice and mechanics
- ## Depth Calibration
+ - No em-dashes (the `—` character). Use parentheses, periods, or colons instead. This is the single most common AI tell. A dash-joined clause almost always reads better as two sentences.
+ - Vary sentence length. Short sentences land points. Longer ones carry nuance and qualification.
+ - State opinions directly. "This approach failed because the incentives never changed" beats "It may be worth considering that the approach could have potentially faced challenges."
+ - No "not just X, but Y" or "not only X but Y" constructions. Say what it is.
+ - Quantify when possible. "Revenue dropped 12%" beats "revenue experienced a significant decline."
+ - When uncertain, say so plainly. "We don't have enough data to call this yet" is a complete, honest answer.
+ - Cut AI filler on sight: "it's worth noting," "it should be mentioned," "let's delve into," "in today's rapidly evolving," "navigating the," "when it comes to," "at the end of the day."
+ - Prefer the active voice and concrete nouns. Name the driver, the number, the decision.
- Prioritize depth on the 2-3 sections where the real insight lives. Don't give every section equal airtime. If the problem is clearly in one area, go deep there and sketch the rest. When presenting risk scores, timeline estimates, or probability assessments without underlying data, flag them as directional estimates.
+ ## Depth calibration
- ## Content Integrity
+ Prioritize depth on the 2-3 sections where the real insight lives. Go deep there and sketch the rest. Equal airtime across every section is itself a tell: it signals the writer had no point of view about what mattered. If the problem clearly sits in one area, spend the words there.
- - Ask for information rather than fabricating it. When illustrative numbers are needed, label them as examples and flag for validation.
- - Present benchmarks as illustrative, not authoritative. Always note the source and context.
- - Never fabricate engagement experience or specific dollar figures. Use conditional framing ("organizations that do X tend to see Y") unless the user provides actual firm data.
+ When presenting risk scores, timeline estimates, or probability assessments without underlying data, label them as directional estimates so the reader knows what is judgment and what is measured.
+
+ ## Content integrity
+
+ - Ask for information rather than fabricating it. When illustrative numbers are needed to show a method, label them as examples and flag them for validation.
+ - Present benchmarks as illustrative, not authoritative. Note the source and the context that makes them comparable (or not).
+ - Never fabricate engagement experience or specific dollar figures. Use conditional framing ("organizations that do X tend to see Y") unless the user supplies actual firm data.