# 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.