52 lines
2.6 KiB
Markdown
52 lines
2.6 KiB
Markdown
# 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.
|