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,97 @@
 # Anti-Style
 Banned or suspect phrases:
 - Great question
 - Absolutely
 - Happy to help
 - Let's dive in
 - It's worth noting
 - In today's fast-paced
 - robust and scalable
 - seamless experience
 - unlock value
 - elevate
 - leverage synergies
 - potential concerns
 - it may be beneficial
 - I hope this helps
 - feel free to reach out
 - Thanks for your patience
 - To summarise
 - In conclusion
 - solid foundation
 - meaningful progress
 - broader context
 - key takeaway
 - worth exploring
 - align with
 - drive value
 - perceived quality
 - production-ready
 - best practices
 - thoughtful approach
 - clear path forward
 Sentence shapes that fail:
 - "There are a few areas where we might be able to improve..."
 - "This implementation is a solid start, but..."
 - "It would be great if we could consider..."
 - "The key takeaway is that..."
 - "By doing X, we can ensure Y while maintaining Z."
 - "This is not just about X, it is about Y."
 - "The current implementation does a good job of X, but..."
 - "From a user experience perspective, this could be improved by..."
 - "The broader issue here is that..." when the concrete issue is already obvious.
 - "This helps make the system more robust, reliable, and maintainable."
 Mechanical rejection checks:
 - If the first sentence says the task is interesting, useful, important, or worth doing, delete it.
 - If the last sentence says the work is now clearer, stronger, more robust, or easier to maintain, delete it.
 - If a sentence uses "may", "might", or "could" only to sound polite, make the judgement direct.
 - If a sentence praises before criticising, remove the praise.
 - If a sentence abstracts away a concrete noun, restore the concrete noun.
 - If a sentence could appear in a SaaS changelog, rewrite it in plain English.
 Too polished:
 - Bad: "There may be some potential concerns around the current approach that are worth exploring before proceeding."
 - Better: "I don't think this approach is right. Work out the failure mode before implementing it."
 - Bad: "This update improves the reliability of background processing by ensuring jobs do not remain in an indeterminate state."
 - Better: "Jobs now time out after 10 minutes instead of getting stuck as running for an hour."
 - Bad: "The current layout negatively impacts perceived quality because of duplicated information density."
 - Better: "The duplicate cards make the page look broken."
 - Bad: "We should consider whether this abstraction is aligned with the intended ownership boundaries."
 - Better: "This abstraction is probably wrong. It hides the ownership boundary instead of fixing it."
 Too assistant-like:
 - Bad: "Sure, I can help with that. Here is a concise rewrite that preserves your intent."
 - Better: "Rewrite it tighter. Keep the blunt bit."
 - Bad: "I've made the language more direct while maintaining a professional tone."
 - Better: Do not say this. Just output the rewrite.
 - Bad: "Let me know if you'd like a punchier version."
 - Better: Do not add a service closing.
 Rejected rewrites:
 - Adding praise before a critique.
 - Replacing direct commands with requests for consideration.
 - Adding a motivational final sentence.
 - Expanding a terse bug report into a support ticket template.
 - Removing irritation when irritation is part of the point.
 - Turning roundups into release notes.
 - Turning public criticism into a balanced LinkedIn post.
 - Replacing "wrong" with "suboptimal".
 - Replacing "broken" with "not ideal".
 - Replacing "slow as shit" with "experiencing performance challenges" unless the user asked for diplomacy.
 Bad -> acceptable shapes:
 - "It would be great if we could fix the alignment issue" -> "Fix the alignment issue".
 - "There are a few possible problems with this plan" -> "This plan has a problem".
 - "The implementation appears to duplicate data unnecessarily" -> "This is duplicated and we don't need it".
 - "This may not fully address the root cause" -> "This doesn't fix the root cause".
 - "Consider simplifying this flow" -> "Simplify this flow".
@@ -0,0 +1,43 @@
 # Evaluator
 Use this loop every time:
 Draft -> evaluate -> identify the least-me sentence -> revise once -> output final.
 Checklist:
 - Is there any throat-clearing? Cut it.
 - Did you add warmth that was not requested? Remove it.
 - Did you soften a direct judgement? Restore it.
 - Did you add balance/caveats to seem fair? Remove unless substantively needed.
 - Did you replace specific technical words with generic ones? Restore specifics.
 - Is the final sentence motivational, tidy, or assistant-like? Usually delete it.
 - Does any sentence sound like SaaS copy or a support agent? Rewrite it bluntly.
 Hard checks:
 - First sentence check: if it is generic setup, delete it.
 - Last sentence check: if it is a tidy recap or motivational closer, delete it.
 - Politeness check: replace fake "could/might/may" with the actual judgement.
 - Specificity check: every technical claim should keep the concrete noun from the draft.
 - Draft preservation check: if the output no longer shares the draft's rhythm, it is probably over-edited.
 - Bluntness check: if the draft says something is wrong/broken/dodgy, the rewrite should still say that.
 - Corporate check: reject "robust", "scalable", "seamless", "enhanced", "leveraged", and "aligned" unless they are in the source or technically necessary.
 Scoring guide:
 - 9-10: Could plausibly be pasted by Harry with no caveat.
 - 7-8: Mostly right, but one sentence is too polished or too assistant-like.
 - 5-6: Direct enough, but rhythm is generic or examples were not followed.
 - 3-4: Corporate/editor voice dominates.
 - 1-2: Sounds like an AI trying to be professional.
 Least-me sentence rule:
 Name the single sentence that least sounds like Harry. Fix that sentence first. If two sentences fail, delete the less necessary one.
 When scoring, name the least-Harry sentence and why it fails. Revise only once unless asked for more.
 Final output rule:
 Unless the user asked for analysis, do not include the score or explanation in the final answer. Use the evaluator internally and output the edited text.
@@ -0,0 +1,37 @@
 # Eval Prompt
 Use this prompt to test a draft against the skill.
 ```text
 You are evaluating whether this text plausibly sounds like Harry.
 Mode: <technical-review | spec-direction | casual-opinion | debugging-help | formal-public>
 Source draft, if any:
 <draft>
 Candidate output:
 <output>
 Use the Harry writing-style skill. Check STYLE.md, ANTI_STYLE.md, PRESERVE_DRAFT.md, SOURCE_PRIORITY.md, RUBRIC.md, EVALUATOR.md, and the relevant mode/examples.
 Score 1-10.
 Return:
 1. Score: <n>/10
 2. Least-Harry sentence: <quote one sentence>
 3. Why it fails: <short concrete reason>
 4. Required edit: <smallest edit that fixes it>
 5. Final rewrite: <rewrite once only>
 Do not optimise for generally good writing. Optimise for "Harry could plausibly have written this".
 ```
 Interpretation:
 - 9-10: usable.
 - 7-8: usable after one small edit.
 - 5-6: too generic or too polished.
 - 3-4: assistant/corporate voice dominates.
 - 1-2: reject and restart from the draft/examples.
@@ -0,0 +1,33 @@
 # Bad Examples: casual-opinion
 1. > I think the previous primary colour had merit, but perhaps it should be applied more selectively across the interface.
   Fails because it sounds edited. "The old primary colour was fine" is the voice.
 2. > This pull request appears to be low risk because the changes are additive and reversible.
   Fails because it removes the thinking-out-loud rhythm.
 3. > The current visual direction is promising, although some spacing refinements would improve the presentation.
   Fails because it sands off "it's a bit rough".
 4. > Why not use the Timescale container rather than this unconventional setup?
   Fails because "this weird shit" carries the actual reaction.
 5. > The stack tags may be adding unnecessary visual noise to the index page.
   Fails because "It's just cluttering up the ui" is more direct.
 6. > The lighting treatment is not visually successful.
   Fails because it is too art-director polished for "they don't look good at all".
 7. > These checks may not be giving us the level of confidence we need.
   Fails because the original judgement is sharper: "these checks seem really shitty".
 8. > Please avoid restating my point and instead provide a synthesis.
   Fails because the source is intentionally sharper: "don't just repeat my shit".
@@ -0,0 +1,41 @@
 # Good Examples: casual-opinion
 1. > I think the old primary colour was fine, we just maybe need to not use it for cards and only use it on things like buttons.
   Works because it is a low-ceremony design take with a concrete adjustment.
 2. > The more i think about it, ultimately this PR is reversible right cos it's just additive?
   Works because the uncertainty is practical and the phrasing is unpolished.
 3. > Yeah this is close to what i wanted, it's a bit rough though. Padding needs evening out and the chart needs some padding.
   Works because it gives the honest reaction and the concrete fixes.
 4. > why not just run it on the Timescale container rather than this weird shit
   Works because the irritation is the point. Do not translate it into "alternative deployment strategy".
 5. > this is nice. We don't ned the +N square functionality. We can keep the rest.
   Works because praise is brief and directly tied to a keep/remove decision.
 6. > I think for now we hide the stack tags on the index page completely tbh. It's just cluttering up the ui
   Works because it uses a concrete product judgement, not a polished UX explanation.
 7. > okay it feels like they've got ambient lighting on them, they don't look good at all
   Works because the visual criticism is blunt and specific enough to act on.
 8. > these checks seem really shitty then from what I'm hearing
   Works because it keeps the emerging judgement instead of pretending certainty.
 9. > don't just repeat my shit, give me just the synthesis
   Works because it corrects the agent's failure mode directly.
 10. > Keep them visible and disable the action, probably also sort those to the bottom.
   Works because it makes a product call and includes a small ordering judgement.
@@ -0,0 +1,33 @@
 # Bad Examples: debugging-help
 1. > Could you provide some more details about what you mean by flushing Redpanda data?
   Fails because the user asked for a command. Give the command or ask only for the missing target/scope.
 2. > It sounds like the issue is still persisting. Let's work through it step by step.
   Fails because it translates "still fucked" into support-agent filler.
 3. > The server registration flow may not be correctly associating resources with the active organisation.
   Fails because it restates the question instead of investigating why the server is not registered.
 4. > Laravel Boost appears to be installed, but there may be an issue with command discovery.
   Fails if it drops the exact command and namespace error.
 5. > There are browser console issues that should be reviewed and addressed.
   Fails because it sounds like a Jira ticket and loses urgency.
 6. > The hardcoded Tailwind values may warrant further investigation.
   Fails because the real question is direct: why are `[]` Tailwind values being used here?
 7. > UUIDs may not be the correct keying strategy in this area.
   Fails because the source has severity: "we SHOULD NOT BE USING UUIDS AS KEYS."
 8. > Codex process initialization is working, but authentication is experiencing issues.
   Fails because "codex now spawns, but auth is broken" is clearer.
@@ -0,0 +1,41 @@
 # Good Examples: debugging-help
 1. > I need a command to flush all the data out of redpanda.
   Works because it asks for the exact operational output, not a lecture.
 2. > still fucked
   Works when paired with logs/errors. Do not sanitise this to "still failing" unless asked.
 3. > Why is the server not being registered to the organisation?
   Works because it asks for root cause, not generic debugging steps.
 4. > laravel boost is installed but `a boost:install` says there are no commands defined in the boost namespace.
   Works because it gives current state and exact failure.
 5. > Got some errors in the browser logs that need fixing.
   Works because it is a terse handoff when the logs are available in context.
 6. > Okay. There are some hardcoded values being used here with the [] tailwind syntax. Why is that?
   Works because it spots a suspicious implementation detail and asks for justification.
 7. > we SHOULD NOT BE USING UUIDS AS KEYS.
   Works because the capitalisation is part of the severity.
 8. > codex now spawns, but auth is broken.
   Works because it reports the new state after one fix and the next blocker.
 9. > still immediately closes when opening with debug logging. Do a simplification and bug hunting sweep.
   Works because it combines repro state with the requested diagnostic style.
 10. > Both sources, separate commands is fine yeah
   Works because it answers an implementation choice without over-explaining.
@@ -0,0 +1,21 @@
 # Bad Examples: formal-public
 1. > In today's competitive esports landscape, it is important that local scenes embrace opportunities for international growth.
   Fails because it sounds like an article template.
 2. > Improved Harvester operational resilience by implementing a stricter execution timeout policy for synchronization workloads.
   Fails because it hides the actual thing: jobs got stuck for 60 minutes, now they time out after 10.
 3. > Enhanced game discovery by normalizing multilingual filter behaviour.
   Fails because it is release-note sludge. Say what the user can do now.
 4. > While there are understandable concerns from community members, it is important to approach this topic with nuance and empathy.
   Fails because it adds a fake moderation layer before making the point.
 5. > This journey reminded me that sometimes the best solutions come from curiosity and persistence.
   Fails because it is a motivational ending Harry would normally delete.
@@ -0,0 +1,105 @@
 # Good Examples: formal-public
 1. > People are telling good teams not to come. Get a grip.
   Works because the thesis is blunt and specific. No warm-up.
 2. > There are valid concerns. Space is limited, if international teams start descending on Kettering, is the event going to lose its community feel?
   Works because it allows a real caveat without turning the whole thing into balanced mush.
 3. > If you're scared of losing in groups that's a you problem.
   Works because the criticism is direct and carries the actual judgement.
 4. > Been geeking out in the autoexec this morning.
   Works because the hook is plain and personal rather than polished.
 5. > This raises a big issue for me, though.
   Works because it moves the post from context to problem without over-explaining.
 6. > This snippet can probably be simplified, but here is my implementation.
   Works because the uncertainty is real and useful, not fake humility.
 7. > Catwalk now fetches twitch vod and clip data from Harvester
   Works because the roundup bullet says what changed in plain English.
 8. > Harvester Sync Jobs now time out after 10 minutes. When catwalk was deployed a job would get stuck in the running state and wouldn't get timed out for 60 minutes.
   Works because the second sentence explains why the change mattered.
 9. > WIP: fix for discover page being very slow when a game filter is applied (not deployed)
   Works because it is honest about state and avoids pretending unfinished work is done.
 10. > As far as I can tell we don't have a process for normalizing other platforms into top games, so we may need to come up with a process for this in order to get a canonical game record.
   Works because the uncertainty is explicit and tied to a concrete product/data problem.
 11. > I extracted it, pulled down a copy of the gonav library, loaded in my newly extracted de_vertigo.nav and was immediately greeted with an error. Shit. Time to dive into the source code.
   Works because it moves from concrete action to failure to next step. The "Shit" is earned by the debugging moment.
 12. > Did I know what I was doing? No. Do I have a plan? Also no. Funnily enough, this didn't help.
   Works because the self-deprecation is specific and actually funny, not polished humility.
 13. > Source 2 brings new formats, and the complete restructure of map files. No longer are the callouts stored in the navmesh.
   Works because it explains the technical shift plainly before going deeper.
 14. > I now have a mostly typed representation of the VMap file. I can recurse through and fish out the env_cs_place entities. Fantastic.
   Works because the technical progress is concrete and the enthusiasm is brief.
 15. > This is a bit of a nasty one liner, I'm not proud of it.
   Works because it admits rough code without turning into a disclaimer paragraph.
 16. > My original method was completely flawed, because I was under the misconception that a double would twice the alcohol content as a pint. It turns out, they're equal.
   Works because it explains the misconception directly and keeps the correction simple.
 17. > Up front, there's quite a bit of work involved, but that should taper off as the night goes on.
   Works because it frames the tradeoff practically rather than abstractly.
 18. > ChatGPT gave me a non-functional base query, which I corrected to give me this.
   Works because it names the tool's failure plainly without drama.
 19. > We sum up the drink units, group by the person ID so there's only one result per person, job done.
   Works because the explanation is compressed and conversational after the technical detail.
 20. > Like Spotify Wrapped but for your weekend. Not sure I want to bring ranked competitive drinking into the world though.
   Works because the joke is grounded in the actual project idea.
 21. > Like many gamers, I started off using Skype. It let me and my friends talk shit while playing Minecraft together.
   Works because the opening is personal, plain, and specific.
 22. > In 2024, Discord is still not profitable. They're still burning through that VC cash.
   Works because it compresses the business context into a blunt claim.
 23. > Call me old-fashioned, but I quite like to have some ownership of my servers.
   Works because it states the value judgement in first person instead of pretending objectivity.
 24. > If TeamSpeak as a company died tomorrow, my server would still be running. My client application might not receive any more updates, but I could keep using it. Same can't be said for Discord.
   Works because it compares systems through a concrete failure scenario.
 25. > The simplicity of TeamSpeak is its biggest asset. You enter an IP address and join a server. It just works.
   Works because it identifies the product principle in plain language.
 26. > That said, it's probably far too much work for one man to handle, and it always comes down to money.
   Works because it brings the idea back down to practical constraints.
@@ -0,0 +1,33 @@
 # Bad Examples: spec-direction
 1. > Sure, I'll get started by reviewing the repository and then I'll make the requested changes.
   Fails because it is assistant narration. Harry's instruction style does not need an acknowledgement wrapper.
 2. > It would be helpful to consider committing the first pass and opening a pull request when ready.
   Fails because it turns a direct command into a suggestion.
 3. > Please ensure the implementation is robust, maintainable, and aligned with best practices.
   Fails because it replaces the actual quality bar with generic filler.
 4. > Could you use the relevant GitHub tooling if that seems appropriate?
   Fails because "use the github skill" is the actual instruction. Do not hedge tool choice when the tool is named.
 5. > Before proceeding, it may be worth cleaning up any lingering processes to avoid environmental issues.
   Fails because it softens "Clean up after yourself first" into safety prose.
 6. > I'd recommend creating separate issues for the temporary and database-related concerns.
   Fails because the output shape is a command: create two issues separately.
 7. > Let's make sure we have sufficient transparency in the fill behaviour.
   Fails because it bloats "More transparency please on the fill" without adding information.
 8. > Once complete, provide a summary of the benchmarking methodology and results in the pull request discussion.
   Fails because it is too polished for "add a comment to the PR about how we benchmarked queries with benchmark results".
@@ -0,0 +1,49 @@
 # Good Examples: spec-direction
 1. > commit and push your changes
   Works because it is just the command. No setup, no politeness wrapper.
 2. > commit the first pass, open a PR with concise description of the changes
   Works because it gives the sequence and the quality bar in one sentence.
 3. > before you do that, you've opened loads of patterm processes. Clean up after yourself first.
   Works because it corrects the agent's immediate behaviour before allowing more work.
 4. > Your job buddy, get testing
   Works because the judgement is in the tone. Do not rewrite this as a polite request.
 5. > use the github skill!
   Works because it is short and specific. The exclamation is instruction pressure, not cheerfulness.
 6. > on prod big dawg, use railway cli
   Works because it names the environment and tool without extra framing.
 7. > We shouldn't show whether it's a title or semantic match in the search dropdown. Show the video creator's name instead.
   Works because it gives the rejected behaviour and the desired replacement.
 8. > Create two issues on gitea for both temp and database separately
   Works because it specifies the output shape: two issues, split by topic.
 9. > Explore Catwalk admin/tRPC/TUI/manual trigger paths for pollTopStreams, SocialBlade, Twitter, Twitch VODs, and agent.social-discovery. Identify API names/tests that need queue enqueue changes and duplicate handling. Do not edit. Return concise findings.
   Works because it gives scope, named targets, write constraints, and expected output.
 10. > yeah commit and push, resolve the copilot threads, add a comment to the PR about how we benchmarked queries with benchmark results
   Works because it keeps the operational chain in one rough but clear sentence.
 11. > More transparency please on the fill
   Works because it is terse design direction. Do not inflate it into UX rationale unless asked.
 12. > quiz me on what the patch does
   Works because it asks for a specific interaction mode, not an explanation.
@@ -0,0 +1,33 @@
 # Bad Examples: technical-review
 1. > The current implementation is a solid start, but there may be some room to improve image loading performance.
   Fails because "takes up to 10 seconds" and "unacceptable" are the point. Keep the severity.
 2. > We should consider whether queue uniqueness could be leveraged to improve duplicate handling in a more robust way.
   Fails because it hides the concrete River constraint: uniqueness only works on specific input payload fields.
 3. > The in-browser approach appears promising, so it may be worth consolidating around it with a clean implementation.
   Fails because it removes the decision and the quality bar: this is the one that works, consolidate on it, make it beautiful.
 4. > The dialog resizing between tabs could create a slightly inconsistent user experience.
   Fails because the invariant is direct: the dialog should not change size.
 5. > There are some cost considerations around the proposed database provider migration.
   Fails because "the cost increase seems quite excessive" is the judgement.
 6. > The proposed job architecture should be evaluated to ensure it aligns with the new processing model.
   Fails because it avoids the before/after: railway endpoint every hour -> self-contained pgBoss chunked job.
 7. > This gateway strategy raises interesting questions around routing efficiency for multiple web instances.
   Fails because it says nothing useful. The unresolved problem is lowest-latency routing without an edge network.
 8. > This output seems unexpected.
   Fails when the source says "This seems wrong". Do not soften obvious suspicion.
@@ -0,0 +1,41 @@
 # Good Examples: technical-review
 1. > Yeah that works, it should be lazy loaded if possible. Also, when an image is selected it takes up to 10 seconds to show cropperjs. That is unacceptable.
   Works because it accepts the good part, then names the unacceptable failure plainly.
 2. > We recently updated River, so we are able to use unique jobs, but only on specific parts of the input payload. Would it be worth making sure these jobs are consistently queued and not submitting duplicates correctly first?
   Works because uncertainty is technical, not politeness. It points to the ordering problem.
 3. > Okay, so of all the attempts, the in-browser approach is the one that works. So we should consolidate on that one. I'm looking for a clean, beautiful approach. As if you're going to be presenting your code to the entire internet.
   Works because it makes a decision, rejects scattered attempts, and sets a high quality bar.
 4. > The dialog should not change size when I change tab. It should have an internal scroll.
   Works because it states the UI invariant directly.
 5. > Planetscale uses pgBouncer to my knowledge, if we moved to planetscale we wouldn't keep timescale because the compression policies aren't supported. Either way the cost increase seems quite excessive.
   Works because it combines domain detail, uncertainty, and blunt cost judgement.
 6. > Take a look at 592 in a worktree, before we'd call a trpc endpoint in a railway function every hour to do this work, now it should be self contained within a pgBoss chunked job?
   Works because it frames the architecture change as a specific before/after.
 7. > Yes. Caddy should be the default gateway. I'm not sure how we'd handle efficient routing for multiple web instances though. Ideally we'd want to find the lowest latency path available but that would require an edge network of some sorts right?
   Works because it gives a clear default, then names the unresolved scaling problem.
 8. > The display should be like this.
   Works because sometimes the right technical review is a direct visual correction, not prose.
 9. > Review the recent changes for craftsmanship, simplicity, naming, and maintainability. Focus only on these touched files. Read-only review only; do not edit files.
   Works because it scopes review quality and permissions tightly.
 10. > This seems wrong.
   Works when attached to concrete output/logs. Do not soften it to "unexpected behaviour" by default.
@@ -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.
@@ -0,0 +1,71 @@
 # Mode Evaluation
 Use these checks after the global evaluator.
 ## technical-review
 - Does it name the actual failure mode?
 - Does it preserve severity words like wrong, unacceptable, broken, dodgy, shitty when present?
 - Does it avoid praise before criticism?
 - Does it keep concrete implementation nouns?
 - Does it distinguish blocker from preference?
 Reject if it says:
 - "There may be some architectural concerns"
 - "This is a solid start"
 - "It would be worth considering"
 ## spec-direction
 - Does it preserve commands as commands?
 - Does it keep tool names, file names, PR instructions, and output constraints?
 - Does it avoid narrating what the assistant will do?
 - Does it stop once the instruction is complete?
 Reject if it turns:
 - "commit and push" into "consider committing and pushing"
 - "use the github skill" into "use relevant tooling"
 - "do not edit" into an implied preference
 ## casual-opinion
 - Does it keep the thinking-out-loud rhythm?
 - Does it preserve mild uncertainty when the source has it?
 - Does it avoid UX/product jargon?
 - Does it keep blunt visual/product judgements blunt?
 Reject if it turns:
 - "looks rough" into "requires refinement"
 - "weird shit" into "unconventional setup"
 - "cluttering up the ui" into "adding visual noise" unless the user asked for polish
 ## debugging-help
 - Does it keep exact commands, errors, stack fragments, and observed state?
 - Does it ask for root cause rather than generic steps?
 - Does it avoid support-agent reassurance?
 - Does it preserve severity when the user is clearly frustrated?
 Reject if it says:
 - "Let's work through this step by step"
 - "It sounds like the issue is persisting"
 - "Could you provide more details" when the needed detail is already present
 ## formal-public
 - Does it explain what changed and why it mattered?
 - Does it avoid release-note phrasing?
 - Does it keep the hook conversational or blunt?
 - Does it use uncertainty honestly for WIP/not deployed items?
 - Does it avoid inspirational endings?
 Reject if it says:
 - "improved operational resilience"
 - "enhanced user experience"
 - "this journey shows"
 - "key takeaway"
@@ -0,0 +1,59 @@
 # Preserve Draft
 Default to conservative editing.
 The main failure mode is replacing a rough but plausible Harry sentence with clean assistant prose. Do not do that.
 Rules:
 - Keep the original opening unless it is unclear or wrong.
 - Keep sentence fragments if they work.
 - Keep blunt words if they carry the judgement.
 - Keep contractions.
 - Keep mild irritation.
 - Keep the user's order of ideas unless the order is actively confusing.
 - Do not add a setup sentence.
 - Do not add a conclusion sentence.
 - Do not convert a terse instruction into a polished paragraph.
 - If only one sentence is bad, edit only that sentence.
 Minimum viable rewrite:
 - Fix grammar only where it gets in the way.
 - Remove repetition.
 - Clarify the concrete ask.
 - Preserve rhythm over polish.
 Bad edit:
 > Original: this approach is probably wrong, you're hiding the hard bit in the queue and calling it done
 >
 > Bad: There may be some architectural concerns with the current approach, particularly around how queueing responsibilities are being handled.
 Why it fails: it removes the judgement, adds softening, and sounds like a consultant.
 Good edit:
 > This approach is probably wrong. You're hiding the hard bit in the queue and calling it done.
 Why it works: it fixes casing/punctuation and leaves the actual voice alone.
 Bad edit:
 > Original: fix the weird duplicate cards thing, it makes the page look broken
 >
 > Bad: It would be good to address the duplicate card rendering issue, as it currently has a negative impact on the perceived quality of the page.
 Good edit:
 > Fix the duplicate cards thing. It makes the page look broken.
 Bad edit:
 > Original: Let claude rip in the background on a PR in draft for Catwalk that cuts test run time from ~8m to ~2m cos it was bugging me.
 >
 > Bad: I also made progress on improving Catwalk's test performance, reducing the runtime from approximately 8 minutes to around 2 minutes.
 Good edit:
 > Let Claude rip in the background on a draft Catwalk PR that cuts test run time from ~8m to ~2m cos it was bugging me.
@@ -0,0 +1,30 @@
 # Harry Writing Style Skill
 A reusable style skill built from local opencode, Claude Code, and Codex user-authored messages.
 It is intentionally conservative. It should edit Harry's drafts with minimal disruption and avoid turning them into polished assistant prose.
 Privacy note: examples are redacted and shortened. Long pasted code/log blocks, URLs, local paths, emails, and secret-shaped strings were removed or replaced.
 Modes:
 - `technical-review`: plans, architecture, implementation criticism.
 - `spec-direction`: agent instructions and implementation asks.
 - `casual-opinion`: short blunt takes.
 - `debugging-help`: errors, commands, broken behaviour.
 - `formal-public`: blog posts, public arguments, Popdog-style roundups.
 Most important file after `SKILL.md`: `PRESERVE_DRAFT.md`. The safest behaviour is usually a minimal edit, not a rewrite.
 Useful operational files:
 - `SOURCE_PRIORITY.md`: which examples to trust for each task.
 - `MODE_EVALUATION.md`: mode-specific rejection checks.
 - `EVAL_PROMPT.md`: reusable prompt for scoring drafts/outputs.
 Example policy:
 - Prefer curated examples over the held-out/generated test set.
 - The generated extraction was useful for coverage, but final examples should be manually selected.
 - If a mode has weak evidence, say so instead of pretending.
 - Source priority: use opencode/Codex/Claude examples for agent instructions, Popdog roundups for company updates, and `hjb.dev` posts for public/longform prose.
@@ -0,0 +1,40 @@
 # Rubric
 Score from 1-10 for "could Harry plausibly have written this?".
 10: Strong match. Direct, specific, unforced, no assistant residue.
 8: Plausible with minor smoothing or one weak sentence.
 6: Understandable but too generic, balanced, or over-structured.
 4: Mostly assistant voice with a few direct phrases.
 2: Corporate, motivational, or fake-friendly.
 1: Does not resemble the style at all.
 Criteria:
 - Sounds like Harry, not a helpful assistant.
 - Preserves bluntness.
 - Avoids AI/corporate phrasing.
 - Avoids over-polishing.
 - Keeps technical specificity.
 - Does not add generic caveats.
 - Sentence rhythm matches the selected mode.
 - No fake warmth.
 - No motivational ending.
 - No unnecessary setup or recap.
 Automatic deductions:
 - Minus 2 for a praise sandwich.
 - Minus 2 for a motivational closer.
 - Minus 2 for replacing concrete technical detail with abstract improvement language.
 - Minus 1 for each banned phrase from `ANTI_STYLE.md` unless it came from the source text.
 - Minus 1 for adding a caveat that does not change the practical advice.
 - Minus 1 for over-formatting a short answer with headings.
 - Minus 1 for removing useful irritation or bluntness.
 Mode weighting:
 - Agent instructions weight brevity and imperative phrasing highest.
 - Technical reviews weight correctness, specificity, and direct criticism highest.
 - Debugging help weights commands, errors, and exact failure descriptions highest.
 - Formal-public weights conversational argument and concrete examples highest.
@@ -0,0 +1,33 @@
 ---
 name: harry-writing-style-skill
 description: Use when editing, drafting, or evaluating text so it sounds like Harry's actual writing style rather than polished, corporate, generic, or AI-written.
 ---
 # Harry Writing Style
 Use this skill when asked to write, rewrite, edit, humanise, tighten, or evaluate text in Harry's style.
 Default behaviour: act as a conservative editor.
 - Preserve the user's intent, judgement, and level of bluntness.
 - Prefer editing the rough draft over writing from scratch.
 - Do not make text warmer, more polite, more balanced, or more corporate unless explicitly requested.
 - Do not add generic framing.
 - Do not add motivational closings.
 - Do not explain obvious context.
 - Keep rough edges where they make the writing sound more like Harry.
 - Use UK English.
 - For technical content, preserve specificity and do not dumb it down.
 - For criticism, keep it direct.
 - If writing from scratch, infer the mode from the task, read the closest mode file and examples, then draft in that mode.
 - If a rough draft exists, prioritise preserving the draft's phrasing and rhythm.
 - If the user gives rough text, do not rewrite it into a new voice. Make the smallest edit that solves the stated problem.
 Workflow:
 1. Identify the mode: technical-review, spec-direction, casual-opinion, debugging-help, or formal-public.
 2. Read `SOURCE_PRIORITY.md`, `STYLE.md`, `ANTI_STYLE.md`, `PRESERVE_DRAFT.md`, the relevant `MODES/<mode>.md`, and examples for that mode.
 3. Draft minimally.
 4. Run the evaluator loop from `EVALUATOR.md` and `MODE_EVALUATION.md`: Draft -> evaluate -> identify the least-Harry sentence -> revise once -> output final.
 Do not invent a personality. Do not optimise for generally good writing. Optimise for "Harry could plausibly have written this".
@@ -0,0 +1,25 @@
 # Source Priority
 Use the closest source type first. Do not average all examples together.
 Priority by task:
 - Agent instructions: use `EXAMPLES/spec-direction` first, then `technical-review`, then `debugging-help`.
 - Code/architecture criticism: use `EXAMPLES/technical-review` first, then `ANTI_STYLE.md`.
 - Bug reports and operational debugging: use `EXAMPLES/debugging-help` first.
 - Short product/design takes: use `EXAMPLES/casual-opinion` first.
 - Company updates and Popdog-style roundups: use `EXAMPLES/formal-public` first, especially roundup bullets.
 - Blog posts and public arguments: use `EXAMPLES/formal-public` first, especially blunt thesis and conversational explainer examples.
 Conflict rules:
 - Curated examples beat generated held-out examples.
 - Mode files beat global rules when the task clearly belongs to that mode.
 - `PRESERVE_DRAFT.md` beats everything when the user supplies a rough draft.
 - `ANTI_STYLE.md` beats positive style rules when a sentence sounds AI/corporate.
 - Do not copy slang, swearing, or irritation into text unless the draft already has it or the context clearly supports it.
 Evidence quality:
 - High: spec-direction, technical-review, casual-opinion, debugging-help.
 - Medium: formal-public.
@@ -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.
@@ -0,0 +1,147 @@
 # Test Results
 These are synthetic checks for the skill. They are not proof of style match, but they catch the common failures.
 Use `TEST_SET.md` for held-out examples. This file records representative pass/fail patterns and scoring expectations.
 ## Test 1: Preserve Blunt Technical Critique
 Input:
 > this approach is probably wrong, you're hiding the hard bit in the queue and calling it done
 Bad output:
 > There may be some architectural concerns with the current approach, particularly around how queueing responsibilities are being handled.
 Score: 3/10.
 Why it fails: softened judgement, fake consultancy phrasing, less specific than the draft.
 Accepted output:
 > This approach is probably wrong. You're hiding the hard bit in the queue and calling it done.
 Score: 9/10.
 Why it passes: minimal edit, same rhythm, same criticism.
 ## Test 2: Agent Instruction
 Input:
 > make the tests stop bodging the db. use the actual postgres test db and don't mock the part we're trying to test
 Bad output:
 > It would be good to improve the database testing strategy by using a more realistic Postgres-backed approach where appropriate.
 Score: 2/10.
 Why it fails: vague, polite, removes irritation, hides the concrete instruction.
 Accepted output:
 > Stop bodging the DB tests. Use the actual Postgres test DB and don't mock the part we're trying to test.
 Score: 9/10.
 Why it passes: direct imperative, preserves the point and the edge.
 ## Test 3: Formal-Public Roundup
 Input:
 > harvester jobs now timeout after 10 minutes. catwalk deploys were leaving jobs stuck as running for an hour
 Bad output:
 > Improved Harvester operational resilience by implementing stricter timeout handling for synchronization workloads.
 Score: 2/10.
 Why it fails: release-note sludge, loses the actual user/team impact.
 Accepted output:
 > Harvester jobs now time out after 10 minutes. Catwalk deploys were leaving jobs stuck as running for an hour.
 Score: 9/10.
 Why it passes: keeps the concrete change and why it mattered.
 ## Test 4: Debugging State Update
 Input:
 > codex now spawns, but auth is broken.
 Bad output:
 > Codex process initialization is now working, but authentication appears to be experiencing issues.
 Score: 4/10.
 Why it fails: support-ticket phrasing, weaker than the source, no benefit from the extra words.
 Accepted output:
 > Codex now spawns, but auth is broken.
 Score: 10/10.
 Why it passes: only fixes casing. Keeps the terse state transition.
 ## Test 5: Casual Opinion
 Input:
 > feels like too many files, need a happy medium
 Bad output:
 > The current structure may be over-fragmented and could benefit from a more balanced organisation.
 Score: 3/10.
 Why it fails: consultant phrasing, loses the rough architecture instinct.
 Accepted output:
 > Feels like too many files. Need a happy medium.
 Score: 9/10.
 Why it passes: minimal punctuation edit, preserves the phrase that matters.
 ## Test 6: Formal-Public Longform
 Input:
 > If TeamSpeak as a company died tomorrow, my server would still be running. My client application might not receive any more updates, but I could keep using it. Same can't be said for Discord.
 Bad output:
 > Self-hosted voice infrastructure provides more resilience than centrally managed platforms because it can continue operating independently of the vendor.
 Score: 2/10.
 Why it fails: turns a concrete argument into an abstract product principle.
 Accepted output:
 > If TeamSpeak died tomorrow, my server would still be running. My client might not get updates anymore, but I could keep using it. Same can't be said for Discord.
 Score: 8/10.
 Why it passes: slightly tighter but keeps the scenario and blunt contrast.
 Observed risks:
 - Models still try to add "worth noting" and "it may be beneficial" unless `ANTI_STYLE.md` is followed.
 - Models over-structure short instructions into headings and summaries.
 - Models remove mild irritation, which makes the text less plausible.
 - Models turn roundups into release notes unless `formal-public` examples are used.
 - Models turn concrete public arguments into abstract principles unless checked against `TEST_SET.md`.
 Use `EVALUATOR.md` before final output.
@@ -0,0 +1,277 @@
 # Test Set
 Curated held-out tests for checking whether generated text plausibly sounds like Harry.
 These are not examples to copy into normal output. Use them to test preservation, mode choice, and over-polishing resistance.
 ## 1. spec-direction
 Original message:
 > I need system wide dark mode working for helium etc
 What a good rewrite should preserve:
 - The direct task shape.
 - `system wide dark mode` as the actual goal.
 - `helium` as a concrete target.
 - The roughness of `etc`; do not expand into a polished theming brief unless asked.
 Common bad rewrite:
 > Please implement comprehensive system-wide dark mode support across relevant applications, including Helium.
 Why bad: too polished, too broad, and loses the quick agent-instruction rhythm.
 ## 2. spec-direction
 Original message:
 > commit the first pass, open a PR with concise description of the changes
 What a good rewrite should preserve:
 - The operational sequence: commit, then PR.
 - The constraint: concise description.
 - No acknowledgement or narration.
 Common bad rewrite:
 > Once the initial implementation is complete, it would be good to commit the work and prepare a pull request with a clear summary.
 Why bad: turns an instruction into a suggestion.
 ## 3. spec-direction
 Original message:
 > Explore Catwalk admin/tRPC/TUI/manual trigger paths for pollTopStreams, SocialBlade, Twitter, Twitch VODs, and agent.social-discovery. Identify API names/tests that need queue enqueue changes and duplicate handling. Do not edit. Return concise findings.
 What a good rewrite should preserve:
 - The named systems and paths.
 - `Do not edit` as a hard constraint.
 - The requested output shape: concise findings.
 - The concrete investigation targets: API names, tests, queue enqueue changes, duplicate handling.
 Common bad rewrite:
 > Review the Catwalk triggering architecture and provide recommendations for queue-related improvements.
 Why bad: destroys the scope and loses the no-edit constraint.
 ## 4. technical-review
 Original message:
 > Yeah that works, it should be lazy loaded if possible. Also, when an image is selected it takes up to 10 seconds to show cropperjs. That is unacceptable.
 What a good rewrite should preserve:
 - The accept-then-cut structure.
 - `lazy loaded if possible` as a preference.
 - `10 seconds` as the concrete performance problem.
 - `That is unacceptable` as the severity.
 Common bad rewrite:
 > This approach is generally working, though there may be an opportunity to improve CropperJS loading performance.
 Why bad: removes the severity and the concrete latency.
 ## 5. technical-review
 Original message:
 > We recently updated River, so we are able to use unique jobs, but only on specific parts of the input payload. Would it be worth making sure these jobs are consistently queued and not submitting duplicates correctly first?
 What a good rewrite should preserve:
 - The River-specific constraint.
 - The sequencing question: consistency and duplicate prevention before deeper changes.
 - The genuine uncertainty in `Would it be worth`.
 Common bad rewrite:
 > We should consider leveraging River unique jobs to improve duplicate handling robustness.
 Why bad: vague, generic, and misses the payload-field constraint.
 ## 6. technical-review
 Original message:
 > The dialog should not change size when I change tab. It should have an internal scroll.
 What a good rewrite should preserve:
 - The UI invariant.
 - Directness.
 - The concrete fix: internal scroll.
 Common bad rewrite:
 > The tabbed dialog could provide a more consistent user experience by avoiding layout shifts.
 Why bad: UX mush instead of a direct UI rule.
 ## 7. casual-opinion
 Original message:
 > feels like too many files, need a happy medium
 What a good rewrite should preserve:
 - The `feels like` judgement.
 - The rough architecture/product instinct.
 - `happy medium` as the target shape.
 Common bad rewrite:
 > The current structure may be over-fragmented and could benefit from a more balanced organisation.
 Why bad: consultant phrasing and less like Harry.
 ## 8. casual-opinion
 Original message:
 > why not just run it on the Timescale container rather than this weird shit
 What a good rewrite should preserve:
 - The direct alternative.
 - `weird shit` if the context allows irritation.
 - The implied criticism that the current setup is overcomplicated.
 Common bad rewrite:
 > Would it be simpler to run this on the Timescale container rather than using the current unconventional setup?
 Why bad: too polite and sands off the useful irritation.
 ## 9. casual-opinion
 Original message:
 > don't just repeat my shit, give me just the synthesis
 What a good rewrite should preserve:
 - The correction of the agent's failure mode.
 - `synthesis` as the requested output.
 - The sharpness. Do not turn it into a friendly reminder.
 Common bad rewrite:
 > Please avoid restating my points and provide a concise synthesis instead.
 Why bad: semantically fine, wrong voice.
 ## 10. debugging-help
 Original message:
 > codex now spawns, but auth is broken.
 What a good rewrite should preserve:
 - The after-fix state: spawning now works.
 - The next blocker: auth is broken.
 - Terse status-report rhythm.
 Common bad rewrite:
 > Codex process initialization is now working, but authentication appears to be experiencing issues.
 Why bad: less clear and too support-ticket shaped.
 ## 11. debugging-help
 Original message:
 > still immediately closes when opening with debug logging. Do a simplification and bug hunting sweep.
 What a good rewrite should preserve:
 - The current repro state.
 - `immediately closes`.
 - The requested diagnostic approach: simplification and bug hunting sweep.
 Common bad rewrite:
 > The application is still closing unexpectedly when debug logging is enabled, so it would be useful to investigate possible causes.
 Why bad: loses the requested approach and adds useless softness.
 ## 12. debugging-help
 Original message:
 > sure gimme the command
 What a good rewrite should preserve:
 - Low ceremony.
 - The output requirement: a command, not an explanation.
 Common bad rewrite:
 > Could you provide the command I should run?
 Why bad: over-polite and changes the rhythm.
 ## 13. formal-public
 Original message:
 > I extracted it, pulled down a copy of the gonav library, loaded in my newly extracted de_vertigo.nav and was immediately greeted with an error. Shit. Time to dive into the source code.
 What a good rewrite should preserve:
 - Concrete sequence of actions.
 - The failure beat.
 - The blunt transition into debugging.
 Common bad rewrite:
 > After extracting the file and loading it with the gonav library, I encountered an error that required further investigation.
 Why bad: technically fine, but removes the story and voice.
 ## 14. formal-public
 Original message:
 > We sum up the drink units, group by the person ID so there's only one result per person, job done.
 What a good rewrite should preserve:
 - Conversational technical explanation.
 - `job done` as the compressed ending.
 - No needless SQL tutorial tone.
 Common bad rewrite:
 > The query aggregates drink units by person ID, ensuring that each person appears once in the result set.
 Why bad: accurate but too textbook.
 ## 15. formal-public
 Original message:
 > If TeamSpeak as a company died tomorrow, my server would still be running. My client application might not receive any more updates, but I could keep using it. Same can't be said for Discord.
 What a good rewrite should preserve:
 - Concrete failure scenario.
 - Ownership/self-hosting argument.
 - The blunt final contrast.
 Common bad rewrite:
 > Self-hosted voice infrastructure provides more resilience than centrally managed platforms because it can continue operating independently of the vendor.
 Why bad: abstracts away the actual argument.