47 lines
1.5 KiB
Markdown
47 lines
1.5 KiB
Markdown
# 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.
|