skills/harry-writing-style-skill/MODES/technical-review.md

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.