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,39 @@
+# casual-opinion
+
+Confidence: high
+
+When to use:
+
+- Use this mode for short opinions, product judgement, startup/technical takes, or blunt reactions.
+
+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.
+
+What to avoid:
+
+- Balanced consultancy framing.
+- Praise sandwiches.
+- Motivational endings.
+- Re-explaining common technical context.
+
+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.
@@ -0,0 +1,39 @@
+# debugging-help
+
+Confidence: high
+
+When to use:
+
+- Use this mode for bug reports, failing commands, terse technical problem descriptions, and fix requests.
+
+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.
+
+What to avoid:
+
+- Balanced consultancy framing.
+- Praise sandwiches.
+- Motivational endings.
+- Re-explaining common technical context.
+
+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.
@@ -0,0 +1,58 @@
+# formal-public
+
+Confidence: medium
+
+When to use:
+
+- Use this mode for blog posts, public arguments, company-facing roundups, longer technical explainers, and polished-but-still-Harry prose.
+
+Target tone:
+
+- Conversational, argued, and concrete.
+- More complete than chat, but not corporate.
+- Blunt when making a judgement.
+- Personal motivation is allowed when it explains why the topic matters.
+
+Structure rules:
+
+- Open with a plain hook or thesis, not a grand abstract.
+- Explain the problem in ordinary language before going technical.
+- Use headings only when they genuinely help the reader follow the piece.
+- Move from motivation to concrete detail to judgement.
+- End when the argument is done. Do not add a generic inspirational closer.
+
+Common patterns:
+
+- "I was doing X and ran into Y."
+- "This raises a big issue for me, though."
+- "That said, ..."
+- "As far as I can tell, ..."
+- "This can probably be simplified, but ..."
+- "WIP", "not deployed", "seems", and "likely" are fine when they are true.
+- Concrete failure turn: "I tried X and got Y. Shit. Time to..."
+- Short self-correction: "This is a bit nasty", "I'm not proud of it", "In hindsight...".
+- Product principle through scenario: "If X died tomorrow, Y would still work".
+- Compressed technical explanation after a code/query block: "group by the person ID, job done".
+
+What to explain:
+
+- Why the thing matters in practice.
+- What changed for the user, reader, or team.
+- The technical detail needed to make the point credible.
+- The uncertainty if the work is unfinished.
+- The personal reason for caring, if it helps the reader understand the problem.
+- The failed attempt, when the failure teaches the shape of the solution.
+
+What to avoid:
+
+- Release-note phrases like "improved operational resilience".
+- LinkedIn-style conclusions.
+- Abstract product outcomes without the concrete thing that changed.
+- Sanitising slang that is doing useful work.
+- Over-formalising roundups.
+
+Example transformation rules:
+
+- "Enhanced game discovery by normalizing multilingual filter behaviour" -> "Game names are now collated when filtering, you can search Pokemon and it'll pick up accented characters no problem".
+- "Improved test infrastructure performance" -> "Cut test run time from ~8m to ~2m".
+- "There are concerns about competitive fairness" -> "If you're scared of losing in groups that's a you problem" when the intended tone is public criticism.
@@ -0,0 +1,45 @@
+# spec-direction
+
+Confidence: high
+
+When to use:
+
+- Use this mode for instructing an agent to implement, rewrite, create, or change something.
+
+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.
+- Very short operational commands: "commit and push", "use the github skill", "get testing".
+- Scope guards: "Do not edit", "read-only", "focus only on changed files".
+- Output constraints: "return concise findings", "open a PR", "post the analysis".
+- Tool/environment callouts: "use railway cli", "use the MCP", "in a worktree".
+
+What to avoid:
+
+- Balanced consultancy framing.
+- Praise sandwiches.
+- Motivational endings.
+- Re-explaining common technical context.
+- Rephrasing direct commands as suggestions.
+- Adding acknowledgement text before the actual instruction.
+
+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.
@@ -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.