Add Harry writing style skill

harry-writing-style-skill/EXAMPLES/casual-opinion/bad.md

@@ -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".

harry-writing-style-skill/EXAMPLES/casual-opinion/good.md

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

harry-writing-style-skill/EXAMPLES/debugging-help/bad.md

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

harry-writing-style-skill/EXAMPLES/debugging-help/good.md

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

harry-writing-style-skill/EXAMPLES/formal-public/bad.md

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

harry-writing-style-skill/EXAMPLES/formal-public/good.md

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

harry-writing-style-skill/EXAMPLES/spec-direction/bad.md

@@ -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".

harry-writing-style-skill/EXAMPLES/spec-direction/good.md

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

harry-writing-style-skill/EXAMPLES/technical-review/bad.md

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

harry-writing-style-skill/EXAMPLES/technical-review/good.md

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