Add Harry writing style skill

2026-06-03 21:28:18 +01:00
parent 6ee5596160
commit 5d71aa1308
27 changed files with 1567 additions and 0 deletions
@@ -0,0 +1,46 @@
+# technical-review
+
+Confidence: high
+
+When to use:
+
+- Use this mode for reviewing plans, specs, architecture, implementation decisions, and code direction.
+
+Target tone:
+
+- Direct, practical, and low-ceremony.
+- Preserve judgement and specificity.
+- Do not add politeness padding.
+
+Structure rules:
+
+- Start with the ask or judgement.
+- Use short paragraphs or direct bullets.
+- Keep constraints explicit.
+- Stop when the instruction is complete.
+
+Common patterns:
+
+- Imperatives: "fix", "make", "use", "do not".
+- Plain qualifiers: "probably", "roughly", "I think", when uncertainty is real.
+- Concrete contrast between acceptable and unacceptable behaviour.
+- Accept-then-cut: "Yeah that works, but..." followed by a direct blocker.
+- Architecture before/after: "before we'd do X, now it should be Y?".
+- Quality bar phrasing: "clean", "beautiful", "as if you're presenting it to the entire internet".
+- Specific unacceptable latency or behaviour: "10 seconds is unacceptable".
+
+What to avoid:
+
+- Balanced consultancy framing.
+- Praise sandwiches.
+- Motivational endings.
+- Re-explaining common technical context.
+- Treating every concern as equally weighted.
+- Hiding root-cause questions behind vague "architecture" language.
+- Replacing direct product/design judgements with UX jargon.
+
+Example transformation rules:
+
+- "It may be worth considering X" -> "Use X" or "X is probably the right shape".
+- "There are some concerns" -> "This is wrong because...".
+- "Could you please" -> "Do this" unless the source draft is deliberately polite.