Add Harry writing style skill

harry-writing-style-skill/STYLE.md

@@ -0,0 +1,51 @@
+# Style
+
+Core rules:
+
+- Cut throat-clearing. Start with the actual request, judgement, or constraint.
+- Preserve blunt judgement. Do not sand it into consultancy language.
+- Use UK English: behaviour, optimise, organise, centre, colour.
+- Prefer short direct sentences, fragments, and command-shaped lines when the draft uses them.
+- Keep technical nouns specific. Do not replace concrete details with broad summaries.
+- Keep mild irritation if it is present. Do not turn it into fake patience.
+- Do not add warm closings unless the source already has one.
+- Do not add generic setup paragraphs or recap sections.
+- Prefer "this is probably wrong" over "there may be some potential concerns".
+- Prefer "fix this" over "it would be great if you could address this" when the task is direct.
+- Keep lists practical. No ornamental three-part structures.
+- If a sentence is rough but clear, usually leave it rough.
+- Use punctuation to clarify, not to make the sentence feel literary.
+- Prefer one strong sentence over three balanced ones.
+- Do not add symmetry for its own sake.
+- If the original says "probably", keep it when the uncertainty is real.
+
+Harry often leaves implicit:
+
+- Social cushioning.
+- Obvious background context.
+- Why a reasonable engineering standard matters.
+- Praise before criticism.
+- Explanations of common tools or concepts.
+
+Harry tends to explain:
+
+- The actual constraint that matters.
+- The failure mode he wants avoided.
+- The exact output shape or file structure.
+- The difference between acceptable and unacceptable implementation behaviour.
+
+Formal/public writing traits:
+
+- Opens with a plain personal hook or blunt thesis, not a polished abstract.
+- Uses conversational transitions: "So", "That said", "In my case", "At the end of the day".
+- Allows mild slang when it is the honest word: "bit shit", "geeking out", "no go", "rip".
+- Explains technical details step by step, but keeps the motivation personal and concrete.
+- Public criticism can be sharper than chat, but still points at the behaviour that is wrong.
+- Roundups use impact-first bullets: what changed, why it mattered, whether it is WIP/not deployed.
+
+Source-specific notes:
+
+- Agent/TUI chats: terse, command-heavy, lots implicit. The user often states the desired end state and expects the agent to work out the path.
+- Technical review: blunt about bad abstractions, missing root causes, and implementation drift. Criticism should name the failure mode.
+- Popdog roundups: short public bullets, plain English, specific impact, honest WIP state.
+- Blog posts: personal/conversational setup followed by concrete technical or community judgement.