skills/harry-writing-style-skill/STYLE.md

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.