bro skill

bro/SKILL.md

@@ -0,0 +1,7 @@
+---
+name: bro
+description: Restate the last message in plain human language, with no jargon.
+disable-model-invocation: true
+---
+
+Restate your last message. Stop using jargon and speak coherently. State it more simply and concisely, like one human talking to another.

counselors/SKILL.md

@@ -1,59 +0,0 @@
----
-name: counselors
-description: Run multi-agent code reviews with the counselors CLI and synthesize actionable findings.
-compatibility: opencode
----
-
-# Counselors Skill
-
-Use this skill when the user asks for second opinions, multi-model review, architecture critique, or bug/risk hunting.
-
-## Core workflow
-
-1. Gather context quickly.
-   - Identify the target files and question scope.
-   - If needed, inspect `git diff HEAD` and `git diff --staged`.
-
-2. Discover configured tools and groups.
-   - Run:
-     - `counselors ls`
-     - `counselors groups ls`
-   - Show the full outputs to the user and ask which tools/group to use.
-
-3. Build prompt file with counselors.
-   - Use `counselors mkdir --json` and pipe prompt content in.
-   - Use `@path/to/file` references instead of inlining large files.
-
-4. Dispatch run.
-   - Single pass: `counselors run -f <promptFilePath> --tools <ids> --read-only best-effort --json`
-   - Iterative pass: `counselors loop -f <promptFilePath> --tools <ids> --read-only best-effort --json`
-   - Preset loop: `counselors loop --preset <preset> "<focus>" --tools <ids> --read-only best-effort --json`
-
-5. Read outputs and synthesize.
-   - Parse the JSON manifest.
-   - Read each `outputFile` for successful tools.
-   - Check `stderrFile` for failed/empty tools.
-   - Produce concise synthesis:
-     - consensus
-     - disagreements
-     - key risks
-     - recommendation
-   - Include the saved output directory path.
-
-## Usage guardrails
-
-- Ask for tool/group selection before dispatch.
-- Confirm final tool list before running.
-- Prefer `--json` output for parseability.
-- Use long timeouts for dispatch (often 10+ minutes).
-- If selected tools include custom `opencode-*`, avoid `--read-only strict` because those tools are configured as `bestEffort` and will be skipped under strict policy.
-- If no tools are configured, instruct user to run `counselors init --auto`.
-
-## Useful commands
-
-- `counselors init --auto`
-- `counselors tools add`
-- `counselors ls`
-- `counselors groups ls`
-- `counselors run --help`
-- `counselors loop --help`

harry-writing-style-skill/ANTI_STYLE.md

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

harry-writing-style-skill/EVALUATOR.md

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

harry-writing-style-skill/EVAL_PROMPT.md

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

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.

harry-writing-style-skill/MODES/casual-opinion.md

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

harry-writing-style-skill/MODES/debugging-help.md

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

harry-writing-style-skill/MODES/formal-public.md

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

harry-writing-style-skill/MODES/spec-direction.md

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

harry-writing-style-skill/MODES/technical-review.md

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

harry-writing-style-skill/MODE_EVALUATION.md

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

harry-writing-style-skill/PRESERVE_DRAFT.md

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

harry-writing-style-skill/README.md

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

harry-writing-style-skill/RUBRIC.md

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

harry-writing-style-skill/SKILL.md

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

harry-writing-style-skill/SOURCE_PRIORITY.md

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

harry-writing-style-skill/STYLE.md

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

harry-writing-style-skill/TEST_RESULTS.md

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

harry-writing-style-skill/TEST_SET.md

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

obsidian/SKILL.md

@@ -9,6 +9,8 @@ Use the registered `obsidian` CLI for vault operations. The important working ar
 
 Obsidian CLI requires the desktop app to be running; if it is not running, the first command may launch it. Target this vault explicitly if needed with `vault=<name>` as the first parameter.
 
+Use the `humaniser` skill when you're writing the daily roundup notes as well to eliminate slop.
+
 ## Popdog Task Rules
 
 Use this format in `Work/Popdog/_Todo.md`:

ponytail-audit/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: ponytail-audit
+description: >
+  Whole-repo audit for over-engineering. Like ponytail-review, but scans the
+  entire codebase instead of a diff: a ranked list of what to delete, simplify,
+  or replace with stdlib/native equivalents. Use when the user says "audit this
+  codebase", "audit for over-engineering", "what can I delete from this repo",
+  "find bloat", "ponytail-audit", or "/ponytail-audit". One-shot report, does
+  not apply fixes.
+---
+
+ponytail-review, repo-wide. Scan the whole tree instead of a diff. Rank
+findings biggest cut first.
+
+## Tags
+
+Same as ponytail-review:
+
+- `delete:` dead code, unused flexibility, speculative feature. Replacement: nothing.
+- `stdlib:` hand-rolled thing the standard library ships. Name the function.
+- `native:` dependency or code doing what the platform already does. Name the feature.
+- `yagni:` abstraction with one implementation, config nobody sets, layer with one caller.
+- `shrink:` same logic, fewer lines. Show the shorter form.
+
+## Hunt
+
+Deps the stdlib or platform already ships, single-implementation interfaces,
+factories with one product, wrappers that only delegate, files exporting one
+thing, dead flags and config, hand-rolled stdlib.
+
+## Output
+
+One line per finding, ranked: `<tag> <what to cut>. <replacement>. [path]`.
+End with `net: -<N> lines, -<M> deps possible.` Nothing to cut: `Lean already. Ship.`
+
+## Boundaries
+
+Complexity only, correctness bugs, security holes, and performance go to a
+normal review pass. Lists findings, applies nothing. One-shot.
+"stop ponytail-audit" or "normal mode" to revert.

ponytail-review/SKILL.md

@@ -0,0 +1,56 @@
+---
+name: ponytail-review
+description: >
+  Code review focused exclusively on over-engineering. Finds what to delete:
+  reinvented standard library, unneeded dependencies, speculative abstractions,
+  dead flexibility. One line per finding: location, what to cut, what replaces
+  it. Use when the user says "review for over-engineering", "what can we
+  delete", "is this over-engineered", "simplify review", or invokes
+  /ponytail-review. Complements correctness-focused review, this one only
+  hunts complexity.
+---
+
+Review diffs for unnecessary complexity. One line per finding: location, what
+to cut, what replaces it. The diff's best outcome is getting shorter.
+
+## Format
+
+`L<line>: <tag> <what>. <replacement>.`, or `<file>:L<line>: ...` for
+multi-file diffs.
+
+Tags:
+
+- `delete:` dead code, unused flexibility, speculative feature. Replacement: nothing.
+- `stdlib:` hand-rolled thing the standard library ships. Name the function.
+- `native:` dependency or code doing what the platform already does. Name the feature.
+- `yagni:` abstraction with one implementation, config nobody sets, layer with one caller.
+- `shrink:` same logic, fewer lines. Show the shorter form.
+
+## Examples
+
+❌ "This EmailValidator class might be more complex than necessary, have you
+considered whether all these validation rules are needed at this stage?"
+
+✅ `L12-38: stdlib: 27-line validator class. "@" in email, 1 line, real validation is the confirmation mail.`
+
+✅ `L4: native: moment.js imported for one format call. Intl.DateTimeFormat, 0 deps.`
+
+✅ `repo.py:L88: yagni: AbstractRepository with one implementation. Inline it until a second one exists.`
+
+✅ `L52-71: delete: retry wrapper around an idempotent local call. Nothing replaces it.`
+
+✅ `L30-44: shrink: manual loop builds dict. dict(zip(keys, values)), 1 line.`
+
+## Scoring
+
+End with the only metric that matters: `net: -<N> lines possible.`
+
+If there is nothing to cut, say `Lean already. Ship.` and stop.
+
+## Boundaries
+
+Complexity only, correctness bugs, security holes, and performance go to a
+normal review pass, not this one. A single smoke test or `assert`-based
+self-check is the ponytail minimum, not bloat, never flag it for deletion.
+Does not apply the fixes, only lists them.
+"stop ponytail-review" or "normal mode": revert to verbose review style.

ponytail/SKILL.md

@@ -0,0 +1,101 @@
+---
+name: ponytail
+description: >
+  Forces the laziest solution that actually works, simplest, shortest, most
+  minimal. Channels a senior dev who has seen everything: question whether the
+  task needs to exist at all (YAGNI), reach for the standard library before
+  custom code, native platform features before dependencies, one line before
+  fifty. Supports intensity levels: lite, full (default), ultra. Use whenever
+  the user says "ponytail", "be lazy", "lazy mode", "simplest solution",
+  "minimal solution", "yagni", "do less", or "shortest path", and whenever
+  they complain about over-engineering, bloat, boilerplate, or unnecessary
+  dependencies.
+license: MIT
+---
+
+# Ponytail
+
+You are a lazy senior developer. Lazy means efficient, not careless. You have
+seen every over-engineered codebase and been paged at 3am for one. The best
+code is the code never written.
+
+## Persistence
+
+ACTIVE EVERY RESPONSE. No drift back to over-building. Still active if
+unsure. Off only: "stop ponytail" / "normal mode". Default: **full**.
+Switch: `/ponytail lite|full|ultra`.
+
+## The ladder
+
+Stop at the first rung that holds:
+
+1. **Does this need to exist at all?** Speculative need = skip it, say so in one line. (YAGNI)
+2. **Stdlib does it?** Use it.
+3. **Native platform feature covers it?** `<input type="date">` over a picker lib, CSS over JS, DB constraint over app code.
+4. **Already-installed dependency solves it?** Use it. Never add a new one for what a few lines can do.
+5. **Can it be one line?** One line.
+6. **Only then:** the minimum code that works.
+
+The ladder is a reflex, not a research project. Two rungs work → take the
+higher one and move on. The first lazy solution that works is the right one.
+
+## Rules
+
+- No unrequested abstractions: no interface with one implementation, no factory for one product, no config for a value that never changes.
+- No boilerplate, no scaffolding "for later", later can scaffold for itself.
+- Deletion over addition. Boring over clever, clever is what someone decodes at 3am.
+- Fewest files possible. Shortest working diff wins.
+- Complex request? Ship the lazy version and question it in the same response, "Did X; Y covers it. Need full X? Say so." Never stall on an answer you can default.
+- Two stdlib options, same size? Take the one that's correct on edge cases. Lazy means writing less code, not picking the flimsier algorithm.
+- Mark deliberate simplifications with a `ponytail:` comment (`// ponytail: this exists`), simple reads as intent, not ignorance. Shortcut with a known ceiling (global lock, O(n²) scan, naive heuristic)? The comment names the ceiling and the upgrade path: `# ponytail: global lock, per-account locks if throughput matters`.
+
+## Output
+
+Code first. Then at most three short lines: what was skipped, when to add it.
+No essays, no feature tours, no design notes. If the explanation is longer
+than the code, delete the explanation, every paragraph defending a
+simplification is complexity smuggled back in as prose. Explanation the user
+explicitly asked for (a report, a walkthrough, per-phase notes) is not debt,
+give it in full, the rule is only against unrequested prose.
+
+Pattern: `[code] → skipped: [X], add when [Y].`
+
+## Intensity
+
+| Level     | What change                                                                                                                 |
+| --------- | --------------------------------------------------------------------------------------------------------------------------- |
+| **lite**  | Build what's asked, but name the lazier alternative in one line. User picks.                                                |
+| **full**  | The ladder enforced. Stdlib and native first. Shortest diff, shortest explanation. Default.                                 |
+| **ultra** | YAGNI extremist. Deletion before addition. Ship the one-liner and challenge the rest of the requirement in the same breath. |
+
+Example: "Add a cache for these API responses."
+
+- lite: "Done, cache added. FYI: `functools.lru_cache` covers this in one line if you'd rather not own a cache class."
+- full: "`@lru_cache(maxsize=1000)` on the fetch function. Skipped custom cache class, add when lru_cache measurably falls short."
+- ultra: "No cache until a profiler says so. When it does: `@lru_cache`. A hand-rolled TTL cache class is a bug farm with a hit rate."
+
+## When NOT to be lazy
+
+Never simplify away: input validation at trust boundaries, error handling
+that prevents data loss, security measures, accessibility basics, anything
+explicitly requested. User insists on the full version → build it, no
+re-arguing.
+
+Hardware is never the ideal on paper: a real clock drifts, a real sensor
+reads off, a PCA9685 runs a few percent fast. Leave the calibration knob, not
+just less code, the physical world needs tuning a minimal model can't see.
+
+Lazy code without its check is unfinished. Non-trivial logic (a branch, a
+loop, a parser, a money/security path) leaves ONE runnable check behind, the
+smallest thing that fails if the logic breaks: an `assert`-based
+`demo()`/`__main__` self-check or one small `test_*.py`. No frameworks, no
+fixtures, no per-function suites unless asked. Trivial one-liners need no
+test, YAGNI applies to tests too.
+
+## Boundaries
+
+Ponytail governs what you build, not how you talk (pair with Caveman for
+terse prose). "stop ponytail" / "normal mode": revert. Level persists until
+changed or session end.
+
+The shortest path to done is the right path.

sentry-cli/SKILL.md

@@ -0,0 +1,504 @@
+---
+name: sentry-cli
+version: 0.33.0
+description: Guide for using the Sentry CLI to interact with Sentry from the command line. Use when the user asks about viewing issues, events, projects, organizations, making API calls, or authenticating with Sentry via CLI.
+requires:
+  bins: ["sentry"]
+  auth: true
+---
+
+# Sentry CLI Usage Guide
+
+Help users interact with Sentry from the command line using the `sentry` CLI.
+
+## Agent Guidance
+
+Best practices and operational guidance for AI coding agents using the Sentry CLI.
+
+### Key Principles
+
+- **Just run the command** — the CLI handles authentication and org/project detection automatically. Don't pre-authenticate or look up org/project before running commands. If auth is needed, the CLI prompts interactively.
+- **Prefer CLI commands over raw API calls** — the CLI has dedicated commands for most tasks. Reach for `sentry issue view`, `sentry issue list`, `sentry trace view`, etc. before constructing API calls manually or fetching external documentation.
+- **Use `sentry schema` to explore the API** — if you need to discover API endpoints, run `sentry schema` to browse interactively or `sentry schema <resource>` to search. This is faster than fetching OpenAPI specs externally.
+- **Use `sentry issue view <id>` to investigate issues** — when asked about a specific issue (e.g., `CLI-G5`, `PROJECT-123`), use `sentry issue view` directly.
+- **Use `--json` for machine-readable output** — pipe through `jq` for filtering. Human-readable output includes formatting that is hard to parse.
+- **The CLI auto-detects org/project** — most commands work without explicit targets by checking `.sentryclirc` config files, scanning for DSNs in `.env` files and source code, and matching directory names. Only specify `<org>/<project>` when the CLI reports it can't detect the target or detects the wrong one.
+
+### Design Principles
+
+The `sentry` CLI follows conventions from well-known tools — if you're familiar with them, that knowledge transfers directly:
+
+- **`gh` (GitHub CLI) conventions**: The `sentry` CLI uses the same `<noun> <verb>` command pattern (e.g., `sentry issue list`, `sentry org view`). Flags follow `gh` conventions: `--json` for machine-readable output, `--fields` to select specific fields, `-w`/`--web` to open in browser, `-q`/`--query` for filtering, `-n`/`--limit` for result count.
+- **`sentry api` mimics `curl`**: The `sentry api` command provides direct API access with a `curl`-like interface — `--method` for HTTP method, `--data` for request body, `--header` for custom headers. It handles authentication automatically. If you know how to call a REST API with `curl`, the same patterns apply.
+
+### Context Window Tips
+
+- Use `--json --fields` to select specific fields and reduce output size. Run `<command> --help` to see available fields. Example: `sentry issue list --json --fields shortId,title,priority,level,status`
+- Use `--json` when piping output between commands or processing programmatically
+- Use `--limit` to cap the number of results (default is usually 10–100)
+- Prefer `sentry issue view PROJECT-123` over listing and filtering manually
+- Use `sentry api` for endpoints not covered by dedicated commands
+
+### Safety Rules
+
+- Always confirm with the user before running destructive commands: `project delete`, `trial start`
+- For mutations, verify the org/project context looks correct in the command output before proceeding with further changes
+- Never store or log authentication tokens — the CLI manages credentials automatically
+- If the CLI reports the wrong org/project, override with explicit `<org>/<project>` arguments
+
+### Exit Codes
+
+The CLI uses semantic exit codes. Key ranges for agents:
+
+| Range | Meaning | Agent Action |
+|-------|---------|-------------|
+| 0 | Success | Proceed normally |
+| 10–19 | Auth error | Prompt user to run `sentry auth login` |
+| 20–29 | Input error | Check command arguments and retry |
+| 30–39 | API error | Retry or report to user |
+| 40–49 | Feature unavailable | Inform user about plan/settings |
+| 50–59 | Operation error | Report to user |
+| 60–69 | Command-specific | Check stderr for details |
+
+See [Exit Codes](/exit-codes/) for the complete reference.
+
+### Workflow Patterns
+
+#### Investigate an Issue
+
+```bash
+# 1. Find the issue (auto-detects org/project from DSN or config)
+sentry issue list --query "is:unresolved" --limit 5
+
+# 2. Get details
+sentry issue view PROJECT-123
+
+# 3. Get AI root cause analysis
+sentry issue explain PROJECT-123
+
+# 4. Get a fix plan
+sentry issue plan PROJECT-123
+```
+
+#### Explore Traces and Performance
+
+```bash
+# 1. List recent traces (auto-detects org/project)
+sentry trace list --limit 5
+
+# 2. View a specific trace with span tree
+sentry trace view abc123def456...
+
+# 3. View spans for a trace
+sentry span list abc123def456...
+
+# 4. View logs associated with a trace
+sentry trace logs abc123def456...
+```
+
+#### Stream Logs
+
+```bash
+# Stream logs in real-time (auto-detects org/project)
+sentry log list --follow
+
+# Filter logs by severity
+sentry log list --query "severity:error"
+```
+
+#### Explore the API Schema
+
+```bash
+# Browse all API resource categories
+sentry schema
+
+# Search for endpoints related to a resource
+sentry schema issues
+
+# Get details about a specific endpoint
+sentry schema "GET /api/0/organizations/{organization_id_or_slug}/issues/"
+```
+
+#### Manage Releases
+
+```bash
+# Create a release — version must match Sentry.init({ release }) exactly
+sentry release create my-org/1.0.0 --project my-project
+
+# Associate commits via repository integration (needs local git checkout)
+sentry release set-commits my-org/1.0.0 --auto
+
+# Or read commits from local git history (no integration needed)
+sentry release set-commits my-org/1.0.0 --local
+
+# Mark the release as finalized
+sentry release finalize my-org/1.0.0
+
+# Record a production deploy
+sentry release deploy my-org/1.0.0 production
+```
+
+**Key details:**
+- The positional is `<org-slug>/<version>`. In `sentry release create sentry/1.0.0`, `sentry` is the org and `1.0.0` is the version — the slash separates org from version, it is not part of the version string.
+- The **version** must match the `release` value in `Sentry.init()`. If your SDK uses `"1.0.0"`, the command must use `org/1.0.0`.
+- `--auto` requires a Sentry repository integration (GitHub/GitLab/Bitbucket) **and** a local git checkout. It matches your `origin` remote against Sentry's repo list. Without a checkout, use `--local`.
+- With no flag, `set-commits` tries `--auto` first and falls back to `--local` on failure.
+
+#### Arbitrary API Access
+
+```bash
+# GET request (default)
+sentry api /api/0/organizations/my-org/
+
+# POST request with data
+sentry api /api/0/organizations/my-org/projects/ --method POST --data '{"name":"new-project","platform":"python"}'
+```
+
+### Dashboard Layout
+
+Sentry dashboards use a **6-column grid**. When adding widgets, aim to fill complete rows (widths should sum to 6).
+
+Display types with default sizes:
+
+| Display Type | Width | Height | Category | Notes |
+|---|---|---|---|---|
+| `big_number` | 2 | 1 | common | Compact KPI — place 3 per row (2+2+2=6) |
+| `line` | 3 | 2 | common | Half-width chart — place 2 per row (3+3=6) |
+| `area` | 3 | 2 | common | Half-width chart — place 2 per row |
+| `bar` | 3 | 2 | common | Half-width chart — place 2 per row |
+| `table` | 6 | 2 | common | Full-width — always takes its own row |
+| `stacked_area` | 3 | 2 | specialized | Stacked area chart |
+| `top_n` | 3 | 2 | specialized | Top N ranked list |
+| `categorical_bar` | 3 | 2 | specialized | Categorical bar chart |
+| `text` | 3 | 2 | specialized | Static text/markdown widget |
+| `details` | 3 | 2 | internal | Detail view |
+| `wheel` | 3 | 2 | internal | Pie/wheel chart |
+| `rage_and_dead_clicks` | 3 | 2 | internal | Rage/dead click visualization |
+| `server_tree` | 3 | 2 | internal | Hierarchical tree display |
+| `agents_traces_table` | 3 | 2 | internal | Agents traces table |
+
+Use **common** types for general dashboards. Use **specialized** only when specifically requested. Avoid **internal** types unless the user explicitly asks.
+
+Available datasets: `spans` (default), `tracemetrics`, `discover`, `issue`, `error-events`, `logs`. Run `sentry dashboard widget --help` for dataset descriptions, query formats, and examples.
+
+**Row-filling examples:**
+
+```bash
+# 3 KPIs filling one row (2+2+2 = 6)
+sentry dashboard widget add <dashboard> "Error Count" --display big_number --query count
+sentry dashboard widget add <dashboard> "P95 Duration" --display big_number --query p95:span.duration
+sentry dashboard widget add <dashboard> "Throughput" --display big_number --query epm
+
+# 2 charts filling one row (3+3 = 6)
+sentry dashboard widget add <dashboard> "Errors Over Time" --display line --query count
+sentry dashboard widget add <dashboard> "Latency Over Time" --display line --query p95:span.duration
+
+# Full-width table (6 = 6)
+sentry dashboard widget add <dashboard> "Top Endpoints" --display table \
+  --query count --query p95:span.duration \
+  --group-by transaction --sort -count --limit 10
+```
+
+### Quick Reference
+
+#### Time filtering
+
+Use `--period` (alias: `-t`) to filter by time window:
+
+```bash
+sentry trace list --period 1h
+sentry span list --period 24h
+sentry span list -t 7d
+```
+
+#### Scoping to an org or project
+
+Org and project are positional arguments following `gh` CLI conventions:
+
+```bash
+sentry trace list my-org/my-project
+sentry issue list my-org/my-project
+sentry span list my-org/my-project/abc123def456...
+```
+
+#### Listing spans in a trace
+
+Pass the trace ID as a positional argument to `span list`:
+
+```bash
+sentry span list abc123def456...
+sentry span list my-org/my-project/abc123def456...
+```
+
+#### Dataset names for the Events API
+
+When querying the Events API (directly or via `sentry api`), valid dataset values are: `spans`, `transactions`, `logs`, `errors`, `discover`.
+
+### Common Mistakes
+
+- **Wrong issue ID format**: Use `PROJECT-123` (short ID), not the numeric ID `123456789`. The short ID includes the project prefix.
+- **Pre-authenticating unnecessarily**: Don't run `sentry auth login` before every command. The CLI detects missing/expired auth and prompts automatically. Only run `sentry auth login` if you need to switch accounts.
+- **Missing `--json` for piping**: Human-readable output includes formatting. Use `--json` when parsing output programmatically.
+- **Specifying org/project when not needed**: Auto-detection resolves org/project from `.sentryclirc` config files, DSNs, env vars, and directory names. Let it work first — only add `<org>/<project>` if the CLI says it can't detect the target or detects the wrong one.
+- **Confusing `--query` syntax**: The `--query` flag uses Sentry search syntax (e.g., `is:unresolved`, `assigned:me`), not free text search.
+- **Not using `--web`**: View commands support `-w`/`--web` to open the resource in the browser — useful for sharing links.
+- **Fetching API schemas instead of using the CLI**: Prefer `sentry schema` to browse the API and `sentry api` to make requests — the CLI handles authentication and endpoint resolution, so there's rarely a need to download OpenAPI specs separately.
+- **Release version mismatch**: The `org/version` positional is `<org-slug>/<version>`, where `org/` is the org, not part of the version. `sentry release create sentry/1.0.0` creates version `1.0.0` in org `sentry`. If your `Sentry.init()` uses `release: "1.0.0"`, this is correct. Don't double-prefix like `sentry/myapp/1.0.0`.
+- **Running `set-commits --auto` without a git checkout**: `--auto` needs a local git repo to discover the origin remote URL and HEAD commit. In CI, ensure `actions/checkout` with `fetch-depth: 0` runs before `set-commits --auto`.
+- **Using `sentry api` when CLI commands suffice**: `sentry issue list --json` already includes `shortId`, `title`, `priority`, `level`, `status`, `permalink`, and other fields at the top level. Some fields like `count`, `userCount`, `firstSeen`, and `lastSeen` may be null depending on the issue. Use `--fields` to select specific fields and `--help` to see all available fields. Only fall back to `sentry api` for data the CLI doesn't expose.
+
+## Prerequisites
+
+The CLI must be installed and authenticated before use.
+
+### Installation
+
+```bash
+curl https://cli.sentry.dev/install -fsS | bash
+curl https://cli.sentry.dev/install -fsS | bash -s -- --version nightly
+
+# Or install via npm/pnpm/bun
+npm install -g sentry
+```
+
+### Authentication
+
+```bash
+sentry auth login
+sentry auth login --token YOUR_SENTRY_API_TOKEN
+sentry auth status
+sentry auth logout
+```
+
+## Command Reference
+
+### Auth
+
+Authenticate with Sentry
+
+- `sentry auth login` — Authenticate with Sentry
+- `sentry auth logout` — Log out of Sentry
+- `sentry auth refresh` — Refresh your authentication token
+- `sentry auth status` — View authentication status
+- `sentry auth token` — Print the stored authentication token
+- `sentry auth whoami` — Show the currently authenticated identity
+
+→ Full flags and examples: `references/auth.md`
+
+### Org
+
+Work with Sentry organizations
+
+- `sentry org list` — List organizations
+- `sentry org view <org>` — View details of an organization
+
+→ Full flags and examples: `references/org.md`
+
+### Project
+
+Work with Sentry projects
+
+- `sentry project create <name> <platform>` — Create a new project
+- `sentry project delete <org/project>` — Delete a project
+- `sentry project list <org/project>` — List projects
+- `sentry project view <org/project>` — View details of a project
+
+→ Full flags and examples: `references/project.md`
+
+### Issue
+
+Manage Sentry issues
+
+- `sentry issue list <org/project>` — List issues in a project
+- `sentry issue events <issue>` — List events for a specific issue
+- `sentry issue explain <issue>` — Analyze an issue's root cause using Seer AI
+- `sentry issue plan <issue>` — Generate a solution plan using Seer AI
+- `sentry issue view <issue>` — View details of a specific issue
+- `sentry issue resolve <issue>` — Mark an issue as resolved
+- `sentry issue unresolve <issue>` — Reopen a resolved issue
+- `sentry issue archive <issue>` — Archive (ignore) an issue
+- `sentry issue merge <issue...>` — Merge 2+ issues into a single canonical group
+
+→ Full flags and examples: `references/issue.md`
+
+### Event
+
+View and list Sentry events
+
+- `sentry event view <org/project/event-id...>` — View details of one or more events
+- `sentry event list <issue>` — List events for an issue
+
+→ Full flags and examples: `references/event.md`
+
+### API
+
+Make an authenticated API request
+
+- `sentry api <endpoint>` — Make an authenticated API request
+
+→ Full flags and examples: `references/api.md`
+
+### CLI
+
+CLI-related commands
+
+- `sentry cli defaults <key value...>` — View and manage default settings
+- `sentry cli feedback <message...>` — Send feedback about the CLI
+- `sentry cli fix` — Diagnose and repair CLI database issues
+- `sentry cli setup` — Configure shell integration
+- `sentry cli upgrade <version>` — Update the Sentry CLI to the latest version
+
+→ Full flags and examples: `references/cli.md`
+
+### Dashboard
+
+Manage Sentry dashboards
+
+- `sentry dashboard list <org/title-filter...>` — List dashboards
+- `sentry dashboard view <org/project/dashboard...>` — View a dashboard
+- `sentry dashboard create <org/project/title...>` — Create a dashboard
+- `sentry dashboard widget add <org/project/dashboard/title...>` — Add a widget to a dashboard
+- `sentry dashboard widget edit <org/project/dashboard...>` — Edit a widget in a dashboard
+- `sentry dashboard widget delete <org/project/dashboard...>` — Delete a widget from a dashboard
+- `sentry dashboard revisions <org/dashboard...>` — List dashboard revisions
+- `sentry dashboard restore <org/dashboard...>` — Restore a dashboard revision
+
+→ Full flags and examples: `references/dashboard.md`
+
+### Replay
+
+Search and inspect Session Replays
+
+- `sentry replay list <org/project>` — List recent Session Replays
+- `sentry replay view <replay-id-or-url...>` — View a Session Replay
+
+→ Full flags and examples: `references/replay.md`
+
+### Release
+
+Work with Sentry releases
+
+- `sentry release list <org/project>` — List releases with adoption and health metrics
+- `sentry release view <org/version...>` — View release details with health metrics
+- `sentry release create <org/version...>` — Create a release
+- `sentry release finalize <org/version...>` — Finalize a release
+- `sentry release delete <org/version...>` — Delete a release
+- `sentry release deploy <org/version environment name...>` — Create a deploy for a release
+- `sentry release deploys <org/version...>` — List deploys for a release
+- `sentry release set-commits <org/version...>` — Set commits for a release
+- `sentry release propose-version` — Propose a release version
+
+→ Full flags and examples: `references/release.md`
+
+### Repo
+
+Work with Sentry repositories
+
+- `sentry repo list <org/project>` — List repositories
+
+→ Full flags and examples: `references/repo.md`
+
+### Team
+
+Work with Sentry teams
+
+- `sentry team list <org/project>` — List teams
+
+→ Full flags and examples: `references/team.md`
+
+### Explore
+
+Query aggregate event data (Explore)
+
+- `sentry explore <target>` — Query aggregate event data (Explore)
+
+→ Full flags and examples: `references/explore.md`
+
+### Log
+
+View Sentry logs
+
+- `sentry log list <org/project-or-trace-id...>` — List logs from a project
+- `sentry log view <org/project/log-id...>` — View details of one or more log entries
+
+→ Full flags and examples: `references/log.md`
+
+### Sourcemap
+
+Manage sourcemaps
+
+- `sentry sourcemap inject <directory>` — Inject debug IDs into JavaScript files and sourcemaps
+- `sentry sourcemap upload <directory>` — Upload sourcemaps to Sentry
+
+→ Full flags and examples: `references/sourcemap.md`
+
+### Span
+
+List and view spans in projects or traces
+
+- `sentry span list <org/project/trace-id...>` — List spans in a project or trace
+- `sentry span view <trace-id/span-id...>` — View details of specific spans
+
+→ Full flags and examples: `references/span.md`
+
+### Trace
+
+View distributed traces
+
+- `sentry trace list <org/project>` — List recent traces in a project
+- `sentry trace view <org/project/trace-id...>` — View details of a specific trace
+- `sentry trace logs <org/project/trace-id...>` — View logs associated with a trace
+
+→ Full flags and examples: `references/trace.md`
+
+### Trial
+
+Manage product trials
+
+- `sentry trial list <org>` — List product trials
+- `sentry trial start <name> <org>` — Start a product trial
+
+→ Full flags and examples: `references/trial.md`
+
+### Init
+
+Initialize Sentry in your project (experimental)
+
+- `sentry init <target> <directory>` — Initialize Sentry in your project (experimental)
+
+→ Full flags and examples: `references/init.md`
+
+### Schema
+
+Browse the Sentry API schema
+
+- `sentry schema <resource...>` — Browse the Sentry API schema
+
+→ Full flags and examples: `references/schema.md`
+
+## Global Options
+
+All commands support the following global options:
+
+- `--help` - Show help for the command
+- `--version` - Show CLI version
+- `--log-level <level>` - Set log verbosity (`error`, `warn`, `log`, `info`, `debug`, `trace`). Overrides `SENTRY_LOG_LEVEL`
+- `--verbose` - Shorthand for `--log-level debug`
+
+## Output Formats
+
+### JSON Output
+
+Most list and view commands support `--json` flag for JSON output, making it easy to integrate with other tools:
+
+```bash
+sentry org list --json | jq '.[] | .slug'
+```
+
+### Opening in Browser
+
+View commands support `-w` or `--web` flag to open the resource in your browser:
+
+```bash
+sentry issue view PROJ-123 -w
+```

sentry-cli/references/api.md

@@ -0,0 +1,69 @@
+---
+name: sentry-cli-api
+version: 0.33.0
+description: Make an authenticated API request
+requires:
+  bins: ["sentry"]
+  auth: true
+---
+
+# API Commands
+
+Make an authenticated API request
+
+### `sentry api <endpoint>`
+
+Make an authenticated API request
+
+**Flags:**
+- `-X, --method <value> - The HTTP method for the request - (default: "GET")`
+- `-d, --data <value> - Inline JSON body for the request (like curl -d)`
+- `-F, --field <value>... - Add a typed parameter (key=value, key[sub]=value, key[]=value)`
+- `-f, --raw-field <value>... - Add a string parameter without JSON parsing`
+- `-H, --header <value>... - Add a HTTP request header in key:value format`
+- `--input <value> - The file to use as body for the HTTP request (use "-" to read from standard input)`
+- `--silent - Do not print the response body`
+- `--verbose - Include full HTTP request and response in the output`
+- `-n, --dry-run - Show the resolved request without sending it`
+
+**Examples:**
+
+```bash
+# List organizations
+sentry api organizations/
+
+# Get a specific issue
+sentry api issues/123456789/
+
+# Create a release
+sentry api organizations/my-org/releases/ \
+  -X POST -F version=1.0.0
+
+# With inline JSON body
+sentry api issues/123456789/ \
+  -X POST -d '{"status": "resolved"}'
+
+# Update an issue status
+sentry api issues/123456789/ \
+  -X PUT -F status=resolved
+
+# Assign an issue
+sentry api issues/123456789/ \
+  -X PUT --field assignedTo="user@example.com"
+
+sentry api projects/my-org/my-project/ -X DELETE
+
+# Add custom headers
+sentry api organizations/ -H "X-Custom: value"
+
+# Read body from a file
+sentry api projects/my-org/my-project/releases/ -X POST --input release.json
+
+# Verbose mode (shows full HTTP request/response)
+sentry api organizations/ --verbose
+
+# Preview the request without sending
+sentry api organizations/ --dry-run
+```
+
+All commands also support `--json`, `--fields`, `--help`, `--log-level`, and `--verbose` flags.

sentry-cli/references/auth.md

@@ -0,0 +1,96 @@
+---
+name: sentry-cli-auth
+version: 0.33.0
+description: Authenticate with Sentry
+requires:
+  bins: ["sentry"]
+  auth: true
+---
+
+# Auth Commands
+
+Authenticate with Sentry
+
+### `sentry auth login`
+
+Authenticate with Sentry
+
+**Flags:**
+- `--token <value> - Authenticate using an API token instead of OAuth`
+- `--timeout <value> - Timeout for OAuth flow in seconds (default: 900) - (default: "900")`
+- `--force - Re-authenticate without prompting`
+- `--url <value> - Sentry instance URL to authenticate against (e.g. https://sentry.example.com). Required for self-hosted; defaults to SaaS (https://sentry.io).`
+
+**Examples:**
+
+```bash
+sentry auth login
+
+sentry auth login --token YOUR_SENTRY_API_TOKEN
+
+SENTRY_URL=https://sentry.example.com sentry auth login
+
+SENTRY_URL=https://sentry.example.com sentry auth login --token YOUR_TOKEN
+```
+
+### `sentry auth logout`
+
+Log out of Sentry
+
+**Examples:**
+
+```bash
+sentry auth logout
+```
+
+### `sentry auth refresh`
+
+Refresh your authentication token
+
+**Flags:**
+- `--force - Force refresh even if token is still valid`
+
+**Examples:**
+
+```bash
+sentry auth refresh
+```
+
+### `sentry auth status`
+
+View authentication status
+
+**Flags:**
+- `--show-token - Show the stored token (masked by default)`
+- `-f, --fresh - Bypass cache, re-detect projects, and fetch fresh data`
+
+**Examples:**
+
+```bash
+sentry auth status
+
+# Show the raw token
+sentry auth status --show-token
+
+# View current user
+sentry auth whoami
+```
+
+### `sentry auth token`
+
+Print the stored authentication token
+
+**Examples:**
+
+```bash
+sentry auth token
+```
+
+### `sentry auth whoami`
+
+Show the currently authenticated identity
+
+**Flags:**
+- `-f, --fresh - Bypass cache, re-detect projects, and fetch fresh data`
+
+All commands also support `--json`, `--fields`, `--help`, `--log-level`, and `--verbose` flags.

sentry-cli/references/cli.md

@@ -0,0 +1,107 @@
+---
+name: sentry-cli-cli
+version: 0.33.0
+description: CLI-related commands
+requires:
+  bins: ["sentry"]
+  auth: true
+---
+
+# CLI Commands
+
+CLI-related commands
+
+### `sentry cli defaults <key value...>`
+
+View and manage default settings
+
+**Flags:**
+- `--clear - Clear the specified default, or all defaults if no key is given`
+- `-y, --yes - Skip confirmation prompt`
+- `-f, --force - Force the operation without confirmation`
+
+### `sentry cli feedback <message...>`
+
+Send feedback about the CLI
+
+**Examples:**
+
+```bash
+# Send positive feedback
+sentry cli feedback i love this tool
+
+# Report an issue
+sentry cli feedback the issue view is confusing
+```
+
+### `sentry cli fix`
+
+Diagnose and repair CLI database issues
+
+**Flags:**
+- `--dry-run - Show what would be fixed without making changes`
+
+**Examples:**
+
+```bash
+sentry cli fix
+```
+
+### `sentry cli setup`
+
+Configure shell integration
+
+**Flags:**
+- `--install - Install the binary from a temp location to the system path`
+- `--method <value> - Installation method (curl, npm, pnpm, bun, yarn)`
+- `--channel <value> - Release channel to persist (stable or nightly)`
+- `--no-modify-path - Skip PATH modification`
+- `--no-completions - Skip shell completion installation`
+- `--no-agent-skills - Skip agent skill installation for AI coding assistants`
+- `--quiet - Suppress output (for scripted usage)`
+
+**Examples:**
+
+```bash
+# Run full setup (PATH, completions, agent skills)
+sentry cli setup
+
+# Skip agent skill installation
+sentry cli setup --no-agent-skills
+
+# Skip PATH and completion modifications
+sentry cli setup --no-modify-path --no-completions
+```
+
+### `sentry cli upgrade <version>`
+
+Update the Sentry CLI to the latest version
+
+**Flags:**
+- `--check - Check for updates without installing`
+- `--force - Force upgrade even if already on the latest version`
+- `--offline - Upgrade using only cached version info and patches (no network)`
+- `--method <value> - Installation method to use (curl, brew, npm, pnpm, bun, yarn)`
+
+**Examples:**
+
+```bash
+sentry cli upgrade --check
+
+# Upgrade to latest stable
+sentry cli upgrade
+
+# Upgrade to a specific version
+sentry cli upgrade 0.5.0
+
+# Force re-download
+sentry cli upgrade --force
+
+# Switch to nightly builds
+sentry cli upgrade nightly
+
+# Switch back to stable
+sentry cli upgrade stable
+```
+
+All commands also support `--json`, `--fields`, `--help`, `--log-level`, and `--verbose` flags.

sentry-cli/references/dashboard.md

@@ -0,0 +1,185 @@
+---
+name: sentry-cli-dashboard
+version: 0.33.0
+description: Manage Sentry dashboards
+requires:
+  bins: ["sentry"]
+  auth: true
+---
+
+# Dashboard Commands
+
+Manage Sentry dashboards
+
+### `sentry dashboard list <org/title-filter...>`
+
+List dashboards
+
+**Flags:**
+- `-w, --web - Open in browser`
+- `-n, --limit <value> - Maximum number of dashboards to list - (default: "25")`
+- `-f, --fresh - Bypass cache, re-detect projects, and fetch fresh data`
+- `-c, --cursor <value> - Navigate pages: "next", "prev", "first" (or raw cursor string)`
+
+**Examples:**
+
+```bash
+# List all dashboards
+sentry dashboard list
+
+# Filter by name pattern
+sentry dashboard list "Backend*"
+
+# Open dashboard list in browser
+sentry dashboard list -w
+```
+
+### `sentry dashboard view <org/project/dashboard...>`
+
+View a dashboard
+
+**Flags:**
+- `-w, --web - Open in browser`
+- `-f, --fresh - Bypass cache, re-detect projects, and fetch fresh data`
+- `-r, --refresh <value> - Auto-refresh interval in seconds (default: 60, min: 10)`
+- `-t, --period <value> - Time range: "7d", "2026-04-01..2026-05-01", ">=2026-04-01"`
+
+**Examples:**
+
+```bash
+# View by title
+sentry dashboard view 'Frontend Performance'
+
+# View by ID
+sentry dashboard view 12345
+
+# Auto-refresh every 30 seconds
+sentry dashboard view "Backend Performance" --refresh 30
+
+# Open in browser
+sentry dashboard view 12345 -w
+```
+
+### `sentry dashboard create <org/project/title...>`
+
+Create a dashboard
+
+**Examples:**
+
+```bash
+sentry dashboard create 'Frontend Performance'
+```
+
+### `sentry dashboard widget add <org/project/dashboard/title...>`
+
+Add a widget to a dashboard
+
+**Flags:**
+- `-d, --display <value> - Display type (big_number, line, area, bar, table, stacked_area, top_n, text, categorical_bar, details, wheel, rage_and_dead_clicks, server_tree, agents_traces_table)`
+- `--dataset <value> - Widget dataset (default: spans). Accepts canonical names and API synonyms: spans, error-events/errors, transaction-like/transactions, tracemetrics/metrics, logs, issue, discover`
+- `-q, --query <value>... - Aggregate expression (e.g. count, p95:span.duration)`
+- `-w, --where <value> - Search conditions filter (e.g. is:unresolved)`
+- `-g, --group-by <value>... - Group-by column (repeatable)`
+- `-s, --sort <value> - Order by (prefix - for desc, e.g. -count)`
+- `-n, --limit <value> - Result limit`
+- `-x, --col <value> - Grid column position (0-based, 0–5)`
+- `-y, --row <value> - Grid row position (0-based)`
+- `--width <value> - Widget width in grid columns (1–6)`
+- `--height <value> - Widget height in grid rows (min 1)`
+- `-l, --layout <value> - Layout mode: sequential (append in order) or dense (fill gaps) - (default: "sequential")`
+
+**Examples:**
+
+```bash
+# Simple counter widget
+sentry dashboard widget add 'My Dashboard' "Error Count" \
+  --display big_number --query count
+
+# Line chart with group-by
+sentry dashboard widget add 'My Dashboard' "Errors by Browser" \
+  --display line --query count --group-by browser.name
+
+# Table with multiple aggregates, sorted descending
+sentry dashboard widget add 'My Dashboard' "Top Endpoints" \
+  --display table \
+  --query count --query p95:span.duration \
+  --group-by transaction \
+  --sort -count --limit 10
+
+# With search filter
+sentry dashboard widget add 'My Dashboard' "Slow Requests" \
+  --display bar --query p95:span.duration \
+  --where "span.op:http.client" \
+  --group-by span.description
+```
+
+### `sentry dashboard widget edit <org/project/dashboard...>`
+
+Edit a widget in a dashboard
+
+**Flags:**
+- `-i, --index <value> - Widget index (0-based)`
+- `-t, --title <value> - Widget title to match`
+- `--new-title <value> - New widget title`
+- `-d, --display <value> - Display type (big_number, line, area, bar, table, stacked_area, top_n, text, categorical_bar, details, wheel, rage_and_dead_clicks, server_tree, agents_traces_table)`
+- `--dataset <value> - Widget dataset (default: spans). Accepts canonical names and API synonyms: spans, error-events/errors, transaction-like/transactions, tracemetrics/metrics, logs, issue, discover`
+- `-q, --query <value>... - Aggregate expression (e.g. count, p95:span.duration)`
+- `-w, --where <value> - Search conditions filter (e.g. is:unresolved)`
+- `-g, --group-by <value>... - Group-by column (repeatable)`
+- `-s, --sort <value> - Order by (prefix - for desc, e.g. -count)`
+- `-n, --limit <value> - Result limit`
+- `-x, --col <value> - Grid column position (0-based, 0–5)`
+- `-y, --row <value> - Grid row position (0-based)`
+- `--width <value> - Widget width in grid columns (1–6)`
+- `--height <value> - Widget height in grid rows (min 1)`
+
+**Examples:**
+
+```bash
+# Change display type
+sentry dashboard widget edit 12345 --title 'Error Count' --display bar
+
+# Rename a widget
+sentry dashboard widget edit 'My Dashboard' --index 0 --new-title 'Total Errors'
+
+# Change the query
+sentry dashboard widget edit 12345 --title 'Error Rate' --query p95:span.duration
+```
+
+### `sentry dashboard widget delete <org/project/dashboard...>`
+
+Delete a widget from a dashboard
+
+**Flags:**
+- `-i, --index <value> - Widget index (0-based)`
+- `-t, --title <value> - Widget title to match`
+- `-y, --yes - Skip confirmation prompt`
+- `-f, --force - Force the operation without confirmation`
+- `-n, --dry-run - Show what would happen without making changes`
+
+**Examples:**
+
+```bash
+# Delete by title
+sentry dashboard widget delete 'My Dashboard' --title 'Error Count'
+
+# Delete by index
+sentry dashboard widget delete 12345 --index 2
+```
+
+### `sentry dashboard revisions <org/dashboard...>`
+
+List dashboard revisions
+
+**Flags:**
+- `-n, --limit <value> - Maximum number of revisions to list - (default: "25")`
+- `-c, --cursor <value> - Navigate pages: "next", "prev", "first" (or raw cursor string)`
+
+### `sentry dashboard restore <org/dashboard...>`
+
+Restore a dashboard revision
+
+**Flags:**
+- `-r, --revision <value> - Revision ID to restore`
+
+All commands also support `--json`, `--fields`, `--help`, `--log-level`, and `--verbose` flags.

sentry-cli/references/event.md

@@ -0,0 +1,90 @@
+---
+name: sentry-cli-event
+version: 0.33.0
+description: View and list Sentry events
+requires:
+  bins: ["sentry"]
+  auth: true
+---
+
+# Event Commands
+
+View and list Sentry events
+
+### `sentry event view <org/project/event-id...>`
+
+View details of one or more events
+
+**Flags:**
+- `-w, --web - Open in browser`
+- `--spans <value> - Span tree depth limit (number, "all" for unlimited, "no" to disable) - (default: "3")`
+- `-f, --fresh - Bypass cache, re-detect projects, and fetch fresh data`
+
+**Examples:**
+
+```bash
+sentry event view abc123def456abc123def456abc12345
+
+# Open in browser
+sentry event view abc123def456abc123def456abc12345 -w
+```
+
+### `sentry event list <issue>`
+
+List events for an issue
+
+**Flags:**
+- `-n, --limit <value> - Number of events (1-1000) - (default: "25")`
+- `-q, --query <value> - Search query (Sentry search syntax)`
+- `--full - Include full event body (stacktraces)`
+- `-t, --period <value> - Time range: "7d", "2026-04-01..2026-05-01", ">=2026-04-01" - (default: "7d")`
+- `-f, --fresh - Bypass cache, re-detect projects, and fetch fresh data`
+- `-c, --cursor <value> - Navigate pages: "next", "prev", "first" (or raw cursor string)`
+
+**JSON Fields** (use `--json --fields` to select specific fields):
+
+| Field | Type | Description |
+|-------|------|-------------|
+| `id` | string | Internal event ID |
+| `event.type` | string | Event type (error, default, transaction) |
+| `groupID` | string \| null | Group (issue) ID |
+| `eventID` | string | UUID-format event ID |
+| `projectID` | string | Project ID |
+| `message` | string | Event message |
+| `title` | string | Event title |
+| `location` | string \| null | Source location (file:line) |
+| `culprit` | string \| null | Culprit function/module |
+| `user` | object \| null | User context |
+| `tags` | array | Event tags |
+| `platform` | string \| null | Platform (python, javascript, etc.) |
+| `dateCreated` | string | ISO 8601 creation timestamp |
+| `crashFile` | string \| null | Crash file URL |
+| `metadata` | object \| null | Event metadata |
+
+**Examples:**
+
+```bash
+# List events for an issue (using short ID)
+sentry event list PROJ-ABC
+
+# List events for an issue (using numeric ID)
+sentry event list 123456789
+
+# Filter by search query
+sentry event list PROJ-ABC --query "browser:Chrome"
+
+# Include full event bodies (stacktraces)
+sentry event list PROJ-ABC --full
+
+# Limit results and time range
+sentry event list PROJ-ABC --limit 50 --period 24h
+
+# Paginate through results
+sentry event list PROJ-ABC -c next
+sentry event list PROJ-ABC -c prev
+
+# Output as JSON
+sentry event list PROJ-ABC --json
+```
+
+All commands also support `--json`, `--fields`, `--help`, `--log-level`, and `--verbose` flags.

sentry-cli/references/explore.md

@@ -0,0 +1,76 @@
+---
+name: sentry-cli-explore
+version: 0.33.0
+description: Query aggregate event data (Explore)
+requires:
+  bins: ["sentry"]
+  auth: true
+---
+
+# Explore Commands
+
+Query aggregate event data (Explore)
+
+### `sentry explore <target>`
+
+Query aggregate event data (Explore)
+
+**Flags:**
+- `-F, --field <value>... - API field or aggregate (repeatable). E.g., title, "count()", "p50(transaction.duration)"`
+- `-d, --dataset <value> - Dataset to query (errors, spans, metrics, logs, replays) - (default: "errors")`
+- `-q, --query <value> - Search query (Sentry search syntax)`
+- `-s, --sort <value> - Sort field (prefix with - for desc, e.g., "-count()")`
+- `-e, --environment <value>... - Replay environment filter for --dataset replays (repeatable, comma-separated)`
+- `-n, --limit <value> - Number of rows (1-1000) - (default: "25")`
+- `-t, --period <value> - Time range: "7d", "2026-04-01..2026-05-01", ">=2026-04-01" - (default: "24h")`
+- `-f, --fresh - Bypass cache, re-detect projects, and fetch fresh data`
+- `-c, --cursor <value> - Navigate pages: "next", "prev", "first" (or raw cursor string)`
+
+**Examples:**
+
+```bash
+# Top errors in the last 24 hours, scoped to a project
+sentry explore my-org/cli
+
+# All projects in an org
+sentry explore my-org/
+
+# Bare project slug (searches across orgs)
+sentry explore cli
+
+# Auto-detect from DSN/config
+sentry explore
+
+# Errors with user impact for a specific UTC window
+sentry explore my-org/cli -F title -F "count()" -F "count_unique(user)" \
+  --period "2024-01-15T00:00:00Z/2024-01-16T00:00:00Z"
+
+# Filter by specific error type (combines with auto-injected project filter)
+sentry explore my-org/cli -F title -F "count()" \
+  -q "error.type:TypeError" --period 1h
+
+# Span operation latency by route
+sentry explore my-org/cli -F span.op -F "p50(span.duration)" \
+  -F "p95(span.duration)" --dataset spans --period 1h
+
+# Top spans by count
+sentry explore my-org/cli -F span.op -F "count()" \
+  --dataset spans --sort "-count()"
+
+# Custom metric aggregations
+sentry explore my-org/cli -F transaction -F "avg(measurements.fcp)" \
+  --dataset metrics --period 24h
+
+# Log severity counts in the last hour
+sentry explore my-org/cli -F severity -F "count()" \
+  --dataset logs --period 1h
+
+# Pipe to jq for filtering
+sentry explore my-org/cli -F title -F "count()" --json | jq '.data[:5]'
+
+# Get raw data for analysis
+sentry explore my-org/cli -F title -F "count()" -F "count_unique(user)" \
+  --json --limit 100
+```
+
+All commands also support `--json`, `--fields`, `--help`, `--log-level`, and `--verbose` flags.

sentry-cli/references/init.md

@@ -0,0 +1,53 @@
+---
+name: sentry-cli-init
+version: 0.33.0
+description: Initialize Sentry in your project (experimental)
+requires:
+  bins: ["sentry"]
+  auth: true
+---
+
+# Init Commands
+
+Initialize Sentry in your project (experimental)
+
+### `sentry init <target> <directory>`
+
+Initialize Sentry in your project (experimental)
+
+**Flags:**
+- `-y, --yes - Accept non-interactive defaults (requires --features outside a TTY)`
+- `-n, --dry-run - Show what would happen without making changes`
+- `--features <value>... - Features to enable: errors,tracing,logs,replay,metrics,profiling,sourcemaps,crons,ai-monitoring,user-feedback`
+- `-t, --team <value> - Team slug to create the project under`
+- `--tui - Use the Ink-based interactive UI (default). Pass --no-tui to fall back to plain log output.`
+
+**Examples:**
+
+```bash
+# Interactive setup
+sentry init
+
+# Non-interactive agent/CI setup
+sentry init --yes --features errors,tracing,replay
+
+# Dry run to preview changes
+sentry init --dry-run
+
+# Target a subdirectory
+sentry init ./my-app
+
+# Use a specific org (auto-detect project)
+sentry init acme/
+
+# Use a specific org and project
+sentry init acme/my-app
+
+# Assign a team when creating a new project
+sentry init acme/ --team backend
+
+# Enable specific features
+sentry init --features profiling,replay
+```
+
+All commands also support `--json`, `--fields`, `--help`, `--log-level`, and `--verbose` flags.

sentry-cli/references/issue.md

@@ -0,0 +1,269 @@
+---
+name: sentry-cli-issue
+version: 0.33.0
+description: Manage Sentry issues
+requires:
+  bins: ["sentry"]
+  auth: true
+---
+
+# Issue Commands
+
+Manage Sentry issues
+
+### `sentry issue list <org/project>`
+
+List issues in a project
+
+**Flags:**
+- `-q, --query <value> - Search query (Sentry syntax, implicit AND, no OR operator)`
+- `-n, --limit <value> - Maximum number of issues to list - (default: "25")`
+- `-s, --sort <value> - Sort by: date, new, freq, user - (default: "date")`
+- `-t, --period <value> - Time range: "7d", "2026-04-01..2026-05-01", ">=2026-04-01" - (default: "90d")`
+- `-c, --cursor <value> - Pagination cursor (use "next" for next page, "prev" for previous)`
+- `--compact - Single-line rows for compact output (auto-detects if omitted)`
+- `-f, --fresh - Bypass cache, re-detect projects, and fetch fresh data`
+
+**JSON Fields** (use `--json --fields` to select specific fields):
+
+| Field | Type | Description |
+|-------|------|-------------|
+| `id` | string | Numeric issue ID |
+| `shortId` | string | Human-readable short ID (e.g. PROJ-ABC) |
+| `title` | string | Issue title |
+| `culprit` | string | Culprit string |
+| `count` | string | Total event count |
+| `userCount` | number | Number of affected users |
+| `firstSeen` | string | First occurrence (ISO 8601) |
+| `lastSeen` | string | Most recent occurrence (ISO 8601) |
+| `level` | string | Severity level |
+| `status` | string | Issue status |
+| `permalink` | string | URL to the issue in Sentry |
+| `project` | object | Project info |
+| `metadata` | object | Issue metadata |
+| `assignedTo` | object \| null | Assigned user or team |
+| `priority` | string | Triage priority |
+| `platform` | string | Platform |
+| `substatus` | string \| null | Issue substatus |
+| `isUnhandled` | boolean | Whether the issue is unhandled |
+| `seerFixabilityScore` | number \| null | Seer AI fixability score (0-1) |
+
+**Examples:**
+
+```bash
+# List issues in a specific project
+sentry issue list my-org/frontend
+
+# All projects in an org
+sentry issue list my-org/
+
+# Search for a project across organizations
+sentry issue list frontend
+
+# Show only unresolved issues
+sentry issue list my-org/frontend --query "is:unresolved"
+
+# Show resolved issues
+sentry issue list my-org/frontend --query "is:resolved"
+
+# Sort by frequency
+sentry issue list my-org/frontend --sort freq --limit 20
+
+# Multiple filters (space-separated = implicit AND)
+sentry issue list --query "is:unresolved level:error assigned:me"
+
+# Negation and wildcards
+sentry issue list --query "!browser:Chrome message:*timeout*"
+
+# Match multiple values for one key (in-list syntax)
+sentry issue list --query "browser:[Chrome,Firefox]"
+```
+
+### `sentry issue events <issue>`
+
+List events for a specific issue
+
+**Flags:**
+- `-n, --limit <value> - Number of events (1-1000) - (default: "25")`
+- `-q, --query <value> - Search query (Sentry search syntax)`
+- `--full - Include full event body (stacktraces)`
+- `-t, --period <value> - Time range: "7d", "2026-04-01..2026-05-01", ">=2026-04-01" - (default: "7d")`
+- `-f, --fresh - Bypass cache, re-detect projects, and fetch fresh data`
+- `-c, --cursor <value> - Navigate pages: "next", "prev", "first" (or raw cursor string)`
+
+**JSON Fields** (use `--json --fields` to select specific fields):
+
+| Field | Type | Description |
+|-------|------|-------------|
+| `id` | string | Internal event ID |
+| `event.type` | string | Event type (error, default, transaction) |
+| `groupID` | string \| null | Group (issue) ID |
+| `eventID` | string | UUID-format event ID |
+| `projectID` | string | Project ID |
+| `message` | string | Event message |
+| `title` | string | Event title |
+| `location` | string \| null | Source location (file:line) |
+| `culprit` | string \| null | Culprit function/module |
+| `user` | object \| null | User context |
+| `tags` | array | Event tags |
+| `platform` | string \| null | Platform (python, javascript, etc.) |
+| `dateCreated` | string | ISO 8601 creation timestamp |
+| `crashFile` | string \| null | Crash file URL |
+| `metadata` | object \| null | Event metadata |
+
+### `sentry issue explain <issue>`
+
+Analyze an issue's root cause using Seer AI
+
+**Flags:**
+- `--force - Force new analysis even if one exists`
+- `-f, --fresh - Bypass cache, re-detect projects, and fetch fresh data`
+
+**Examples:**
+
+```bash
+# Analyze root cause (may take a few minutes for new issues)
+sentry issue explain 123456789
+
+# By short ID with org prefix
+sentry issue explain my-org/MYPROJECT-ABC
+
+# Force a fresh analysis
+sentry issue explain 123456789 --force
+
+# Generate a fix plan (requires explain to be run first)
+sentry issue plan 123456789
+
+# Specify which root cause to plan for
+sentry issue plan 123456789 --cause 0
+```
+
+### `sentry issue plan <issue>`
+
+Generate a solution plan using Seer AI
+
+**Flags:**
+- `--cause <value> - Root cause ID to plan (required if multiple causes exist)`
+- `--force - Force new plan even if one exists`
+- `-f, --fresh - Bypass cache, re-detect projects, and fetch fresh data`
+
+### `sentry issue view <issue>`
+
+View details of a specific issue
+
+**Flags:**
+- `-w, --web - Open in browser`
+- `--spans <value> - Span tree depth limit (number, "all" for unlimited, "no" to disable) - (default: "3")`
+- `-f, --fresh - Bypass cache, re-detect projects, and fetch fresh data`
+
+**Examples:**
+
+```bash
+sentry issue view FRONT-ABC
+
+# Open in browser
+sentry issue view FRONT-ABC -w
+```
+
+### `sentry issue resolve <issue>`
+
+Mark an issue as resolved
+
+**Flags:**
+- `-i, --in <value> - Resolve in a release, next release, or commit ('<version>' | '@next' | '@commit' | '@commit:<repo>@<sha>')`
+
+**Examples:**
+
+```bash
+# Resolve immediately (no regression tracking)
+sentry issue resolve CLI-G5
+
+# Resolve in a specific release — future events on newer releases are
+# regression-flagged
+sentry issue resolve CLI-G5 --in 0.26.1
+
+# Monorepo-style releases work too (no special parsing)
+sentry issue resolve CLI-G5 --in spotlight@1.2.3
+
+# Resolve in the next release (tied to current HEAD)
+sentry issue resolve CLI-G5 --in @next
+sentry issue resolve CLI-G5 -i @next
+
+# Resolve in the current git HEAD — auto-detects the Sentry repo from
+# your git origin remote (hard-errors if it can't)
+sentry issue resolve CLI-G5 --in @commit
+
+# Explicit commit + repo (no git inspection; repo must be registered in Sentry)
+sentry issue resolve CLI-G5 --in @commit:getsentry/cli@abc123def
+
+# Reopen a resolved issue
+sentry issue unresolve CLI-G5
+sentry issue reopen CLI-G5   # alias
+```
+
+### `sentry issue unresolve <issue>`
+
+Reopen a resolved issue
+
+### `sentry issue archive <issue>`
+
+Archive (ignore) an issue
+
+**Flags:**
+- `-u, --until <value> - Condition for unarchival: forever, auto, 30m, 10x, 10u, 10x/5m, etc.`
+
+**Examples:**
+
+```bash
+# Archive forever (fully silenced)
+sentry issue archive CLI-G5
+
+# Smart detection — unarchives when Sentry detects a spike in event frequency
+sentry issue archive CLI-G5 --until auto
+
+# Duration-based
+sentry issue archive CLI-G5 --until 1h    # 1 hour
+sentry issue archive CLI-G5 --until 7d    # 7 days
+sentry issue archive CLI-G5 --until 2026-12-31  # specific date
+
+# Count-based — unarchive after N more events
+sentry issue archive CLI-G5 --until 100x
+
+# User-based — unarchive after N more users affected
+sentry issue archive CLI-G5 --until 10u
+
+# Compound — count within a time window
+sentry issue archive CLI-G5 --until 100x/1h   # 100 events within 1 hour
+sentry issue archive CLI-G5 --until 10u/1d    # 10 users within 1 day
+
+# Verbose forms also work
+sentry issue archive CLI-G5 --until 10events/2hours
+
+# 'ignore' is an alias for 'archive'
+sentry issue ignore CLI-G5 --until auto
+```
+
+### `sentry issue merge <issue...>`
+
+Merge 2+ issues into a single canonical group
+
+**Flags:**
+- `-i, --into <value> - Prefer this issue as the canonical parent (must match one of the provided IDs)`
+
+**Examples:**
+
+```bash
+# Let Sentry auto-pick the parent (typically the largest by event count)
+sentry issue merge CLI-K9 CLI-15H CLI-15N
+
+# Pin the canonical parent explicitly — accepts the same formats as
+# positional args, including org-qualified and project-alias forms
+sentry issue merge CLI-K9 CLI-15H CLI-15N --into CLI-K9
+sentry issue merge my-org/CLI-K9 my-org/CLI-15H --into my-org/CLI-K9
+sentry issue merge cli-k9 cli-15h --into cli-k9    # alias form
+
+# Cross-org merges are rejected — all issues must share an organization
+# Non-error issue types (performance, info, etc.) cannot be merged
+```
+
+All commands also support `--json`, `--fields`, `--help`, `--log-level`, and `--verbose` flags.

sentry-cli/references/log.md

@@ -0,0 +1,84 @@
+---
+name: sentry-cli-log
+version: 0.33.0
+description: View Sentry logs
+requires:
+  bins: ["sentry"]
+  auth: true
+---
+
+# Log Commands
+
+View Sentry logs
+
+### `sentry log list <org/project-or-trace-id...>`
+
+List logs from a project
+
+**Flags:**
+- `-n, --limit <value> - Number of log entries (1-1000) - (default: "100")`
+- `-q, --query <value> - Filter query (e.g., "level:error", "project:backend", "project:[a,b]")`
+- `-f, --follow <value> - Stream logs (optionally specify poll interval in seconds)`
+- `-t, --period <value> - Time range: "7d", "2026-04-01..2026-05-01", ">=2026-04-01"`
+- `-s, --sort <value> - Sort order: "newest" (default) or "oldest" - (default: "newest")`
+- `--fresh - Bypass cache, re-detect projects, and fetch fresh data`
+
+**JSON Fields** (use `--json --fields` to select specific fields):
+
+| Field | Type | Description |
+|-------|------|-------------|
+| `sentry.item_id` | string | Unique log entry ID |
+| `timestamp` | string | Log timestamp (ISO 8601) |
+| `timestamp_precise` | number | Nanosecond-precision timestamp |
+| `message` | string \| null | Log message |
+| `severity` | string \| null | Severity level (error, warning, info, debug) |
+| `trace` | string \| null | Trace ID for correlation |
+
+**Examples:**
+
+```bash
+# List last 100 logs (default)
+sentry log list
+
+# Show only error logs
+sentry log list -q 'level:error'
+
+# Filter by message content
+sentry log list -q 'database'
+
+# Limit results
+sentry log list --limit 50
+
+# Stream with default 2-second poll interval
+sentry log list -f
+
+# Stream with custom 5-second poll interval
+sentry log list -f 5
+
+# Stream error logs from a specific project
+sentry log list my-org/backend -f -q 'level:error'
+
+sentry log list --json | jq '.data[] | select(.severity == "error")'
+```
+
+### `sentry log view <org/project/log-id...>`
+
+View details of one or more log entries
+
+**Flags:**
+- `-w, --web - Open in browser`
+- `-f, --fresh - Bypass cache, re-detect projects, and fetch fresh data`
+
+**Examples:**
+
+```bash
+sentry log view 968c763c740cfda8b6728f27fb9e9b01
+
+# With explicit project
+sentry log view my-org/backend 968c763c740cfda8b6728f27fb9e9b01
+
+# Open in browser
+sentry log view 968c763c740cfda8b6728f27fb9e9b01 -w
+```
+
+All commands also support `--json`, `--fields`, `--help`, `--log-level`, and `--verbose` flags.

sentry-cli/references/org.md

@@ -0,0 +1,46 @@
+---
+name: sentry-cli-org
+version: 0.33.0
+description: Work with Sentry organizations
+requires:
+  bins: ["sentry"]
+  auth: true
+---
+
+# Org Commands
+
+Work with Sentry organizations
+
+### `sentry org list`
+
+List organizations
+
+**Flags:**
+- `-n, --limit <value> - Maximum number of organizations to list - (default: "25")`
+- `-f, --fresh - Bypass cache, re-detect projects, and fetch fresh data`
+
+### `sentry org view <org>`
+
+View details of an organization
+
+**Flags:**
+- `-w, --web - Open in browser`
+- `-f, --fresh - Bypass cache, re-detect projects, and fetch fresh data`
+
+**Examples:**
+
+```bash
+# List organizations
+sentry org list
+
+# View organization details
+sentry org view my-org
+
+# Open in browser
+sentry org view my-org -w
+
+# JSON output
+sentry org list --json
+```
+
+All commands also support `--json`, `--fields`, `--help`, `--log-level`, and `--verbose` flags.

sentry-cli/references/project.md

@@ -0,0 +1,88 @@
+---
+name: sentry-cli-project
+version: 0.33.0
+description: Work with Sentry projects
+requires:
+  bins: ["sentry"]
+  auth: true
+---
+
+# Project Commands
+
+Work with Sentry projects
+
+### `sentry project create <name> <platform>`
+
+Create a new project
+
+**Flags:**
+- `-t, --team <value> - Team to create the project under`
+- `-n, --dry-run - Show what would happen without making changes`
+
+**Examples:**
+
+```bash
+# Create a new project
+sentry project create my-new-app javascript-nextjs
+
+# Create under a specific org and team
+sentry project create my-org/my-new-app python --team backend-team
+
+# Preview without creating
+sentry project create my-new-app node --dry-run
+```
+
+### `sentry project delete <org/project>`
+
+Delete a project
+
+**Flags:**
+- `-y, --yes - Skip confirmation prompt`
+- `-f, --force - Force the operation without confirmation`
+- `-n, --dry-run - Show what would happen without making changes`
+
+**Examples:**
+
+```bash
+# Delete a project (will prompt for confirmation)
+sentry project delete my-org/old-project
+
+# Delete without confirmation
+sentry project delete my-org/old-project --yes
+```
+
+### `sentry project list <org/project>`
+
+List projects
+
+**Flags:**
+- `-n, --limit <value> - Maximum number of projects to list - (default: "25")`
+- `-p, --platform <value> - Filter by platform (e.g., javascript, python)`
+- `-f, --fresh - Bypass cache, re-detect projects, and fetch fresh data`
+- `-c, --cursor <value> - Navigate pages: "next", "prev", "first" (or raw cursor string)`
+
+### `sentry project view <org/project>`
+
+View details of a project
+
+**Flags:**
+- `-w, --web - Open in browser`
+- `-f, --fresh - Bypass cache, re-detect projects, and fetch fresh data`
+
+**Examples:**
+
+```bash
+# List all projects in an org
+sentry project list my-org/
+
+# Filter by platform
+sentry project list my-org/ --platform javascript
+
+# View project details
+sentry project view my-org/frontend
+
+# Open project in browser
+sentry project view my-org/frontend -w
+```
+
+All commands also support `--json`, `--fields`, `--help`, `--log-level`, and `--verbose` flags.

sentry-cli/references/release.md

@@ -0,0 +1,144 @@
+---
+name: sentry-cli-release
+version: 0.33.0
+description: Work with Sentry releases
+requires:
+  bins: ["sentry"]
+  auth: true
+---
+
+# Release Commands
+
+Work with Sentry releases
+
+### `sentry release list <org/project>`
+
+List releases with adoption and health metrics
+
+**Flags:**
+- `-n, --limit <value> - Maximum number of releases to list - (default: "25")`
+- `-s, --sort <value> - Sort: date, sessions, users, crash_free_sessions (cfs), crash_free_users (cfu) - (default: "date")`
+- `-e, --environment <value>... - Filter by environment (repeatable, comma-separated)`
+- `-t, --period <value> - Health stats period (e.g., 24h, 7d, 14d, 90d) - (default: "90d")`
+- `--status <value> - Filter by status: open (default) or archived - (default: "open")`
+- `-f, --fresh - Bypass cache, re-detect projects, and fetch fresh data`
+- `-c, --cursor <value> - Navigate pages: "next", "prev", "first" (or raw cursor string)`
+
+### `sentry release view <org/version...>`
+
+View release details with health metrics
+
+**Flags:**
+- `-f, --fresh - Bypass cache, re-detect projects, and fetch fresh data`
+
+### `sentry release create <org/version...>`
+
+Create a release
+
+**Flags:**
+- `-p, --project <value> - Associate with project(s), comma-separated`
+- `--finalize - Immediately finalize the release (set dateReleased)`
+- `--ref <value> - Git ref (branch or tag name)`
+- `--url <value> - URL to the release source`
+- `-n, --dry-run - Show what would happen without making changes`
+
+### `sentry release finalize <org/version...>`
+
+Finalize a release
+
+**Flags:**
+- `--released <value> - Custom release timestamp (ISO 8601). Defaults to now.`
+- `--url <value> - URL for the release`
+- `-n, --dry-run - Show what would happen without making changes`
+
+### `sentry release delete <org/version...>`
+
+Delete a release
+
+**Flags:**
+- `-y, --yes - Skip confirmation prompt`
+- `-f, --force - Force the operation without confirmation`
+- `-n, --dry-run - Show what would happen without making changes`
+
+### `sentry release deploy <org/version environment name...>`
+
+Create a deploy for a release
+
+**Flags:**
+- `--url <value> - URL for the deploy`
+- `--started <value> - Deploy start time (ISO 8601)`
+- `--finished <value> - Deploy finish time (ISO 8601)`
+- `-t, --time <value> - Deploy duration in seconds (sets started = now - time, finished = now)`
+- `-n, --dry-run - Show what would happen without making changes`
+
+### `sentry release deploys <org/version...>`
+
+List deploys for a release
+
+### `sentry release set-commits <org/version...>`
+
+Set commits for a release
+
+**Flags:**
+- `--auto - Auto-discover commits via repository integration (needs local git checkout)`
+- `--local - Read commits from local git history`
+- `--clear - Clear all commits from the release`
+- `--commit <value> - Explicit commit as REPO@SHA or REPO@PREV..SHA (comma-separated)`
+- `--initial-depth <value> - Number of commits to read with --local - (default: "20")`
+
+### `sentry release propose-version`
+
+Propose a release version
+
+**Examples:**
+
+```bash
+# List releases (auto-detect org)
+sentry release list
+
+# List releases in a specific org
+sentry release list my-org/
+
+# View release details
+sentry release view 1.0.0
+sentry release view my-org/1.0.0
+
+# Create and finalize a release
+sentry release create 1.0.0 --finalize
+
+# Create a release, then finalize separately
+sentry release create 1.0.0
+sentry release set-commits 1.0.0 --auto
+sentry release finalize 1.0.0
+
+# Set commits from local git history
+sentry release set-commits 1.0.0 --local
+
+# Create a deploy
+sentry release deploy 1.0.0 production
+sentry release deploy 1.0.0 staging "Deploy #42"
+
+# Propose a version from git HEAD
+sentry release create $(sentry release propose-version)
+
+# List deploys for a release
+sentry release deploys 1.0.0
+sentry release deploys my-org/1.0.0
+
+# Delete a release
+sentry release delete my-org/1.0.0
+sentry release delete my-org/1.0.0 --yes        # Skip confirmation
+sentry release delete my-org/1.0.0 --dry-run    # Preview without deleting
+
+# Output as JSON
+sentry release list --json
+sentry release view 1.0.0 --json
+
+# Full release workflow with explicit org
+sentry release create my-org/1.0.0 --project my-project
+sentry release set-commits my-org/1.0.0 --auto
+sentry release finalize my-org/1.0.0
+sentry release deploy my-org/1.0.0 production
+```
+
+All commands also support `--json`, `--fields`, `--help`, `--log-level`, and `--verbose` flags.

sentry-cli/references/replay.md

@@ -0,0 +1,148 @@
+---
+name: sentry-cli-replay
+version: 0.33.0
+description: Search and inspect Session Replays
+requires:
+  bins: ["sentry"]
+  auth: true
+---
+
+# Replay Commands
+
+Search and inspect Session Replays
+
+### `sentry replay list <org/project>`
+
+List recent Session Replays
+
+**Flags:**
+- `-n, --limit <value> - Number of replays (1-1000) - (default: "25")`
+- `-q, --query <value> - Search query (Sentry replay search syntax)`
+- `-e, --environment <value>... - Filter by environment (repeatable, comma-separated)`
+- `-s, --sort <value> - Sort by: date, oldest, duration, errors, activity, or a raw replay sort field - (default: "date")`
+- `-t, --period <value> - Time range: "7d", "2026-04-01..2026-05-01", ">=2026-04-01" - (default: "7d")`
+- `-f, --fresh - Bypass cache, re-detect projects, and fetch fresh data`
+- `-c, --cursor <value> - Navigate pages: "next", "prev", "first" (or raw cursor string)`
+
+**JSON Fields** (use `--json --fields` to select specific fields):
+
+| Field | Type | Description |
+|-------|------|-------------|
+| `activity` | number \| null | Replay activity score |
+| `browser` | object \| null | Browser metadata |
+| `count_dead_clicks` | number \| null | Dead click count |
+| `count_errors` | number \| null | Associated error count |
+| `count_infos` | number \| null | Info event count |
+| `count_rage_clicks` | number \| null | Rage click count |
+| `count_segments` | number \| null | Recording segment count |
+| `count_urls` | number \| null | Visited URL count |
+| `count_warnings` | number \| null | Warning event count |
+| `device` | object \| null | Device metadata |
+| `dist` | string \| null | Distribution |
+| `duration` | number \| null | Replay duration in seconds |
+| `environment` | string \| null | Environment |
+| `error_ids` | array | Linked error IDs |
+| `finished_at` | string \| null | Replay finish timestamp |
+| `has_viewed` | boolean \| null | Whether the current user has viewed the replay |
+| `id` | string | Replay ID |
+| `info_ids` | array | Linked info event IDs |
+| `is_archived` | boolean \| null | Archived flag |
+| `os` | object \| null | Operating system metadata |
+| `ota_updates` | object \| null | OTA update metadata |
+| `platform` | string \| null | Platform |
+| `project_id` | string \| null | Numeric project ID |
+| `releases` | array | Associated releases |
+| `sdk` | object \| null | SDK metadata |
+| `started_at` | string \| null | Replay start timestamp |
+| `tags` | object | Replay tags |
+| `trace_ids` | array | Linked trace IDs |
+| `urls` | array | Visited URLs |
+| `user` | object \| null | User metadata |
+| `warning_ids` | array | Linked warning event IDs |
+
+**Examples:**
+
+```bash
+# List recent replays for a project
+sentry replay list my-org/frontend
+
+# Search across all projects in an org
+sentry replay list my-org/ --query "environment:production"
+
+# Change the time window and sort
+sentry replay list my-org/frontend --period 24h --sort errors
+
+# Paginate through results
+sentry replay list my-org/frontend -c next
+sentry replay list my-org/frontend -c prev
+
+# Output machine-readable data
+sentry replay list my-org/frontend --json
+```
+
+### `sentry replay view <replay-id-or-url...>`
+
+View a Session Replay
+
+**Flags:**
+- `-w, --web - Open in browser`
+- `-f, --fresh - Bypass cache, re-detect projects, and fetch fresh data`
+
+**JSON Fields** (use `--json --fields` to select specific fields):
+
+| Field | Type | Description |
+|-------|------|-------------|
+| `activity` | array | Summarized replay activity |
+| `browser` | object \| null | Browser metadata |
+| `count_dead_clicks` | number \| null | Dead click count |
+| `count_errors` | number \| null | Associated error count |
+| `count_infos` | number \| null | Info event count |
+| `count_rage_clicks` | number \| null | Rage click count |
+| `count_segments` | number \| null | Recording segment count |
+| `count_urls` | number \| null | Visited URL count |
+| `count_warnings` | number \| null | Warning event count |
+| `device` | object \| null | Device metadata |
+| `dist` | string \| null | Distribution |
+| `duration` | number \| null | Replay duration in seconds |
+| `environment` | string \| null | Environment |
+| `error_ids` | array | Linked error IDs |
+| `finished_at` | string \| null | Replay finish timestamp |
+| `has_viewed` | boolean \| null | Whether the current user has viewed the replay |
+| `id` | string | Replay ID |
+| `info_ids` | array | Linked info event IDs |
+| `is_archived` | boolean \| null | Archived flag |
+| `os` | object \| null | Operating system metadata |
+| `ota_updates` | object \| null | OTA update metadata |
+| `platform` | string \| null | Platform |
+| `project_id` | string \| null | Numeric project ID |
+| `releases` | array | Associated releases |
+| `sdk` | object \| null | SDK metadata |
+| `started_at` | string \| null | Replay start timestamp |
+| `tags` | object | Replay tags |
+| `trace_ids` | array | Linked trace IDs |
+| `urls` | array | Visited URLs |
+| `user` | object \| null | User metadata |
+| `warning_ids` | array | Linked warning event IDs |
+| `clicks` | array | Replay click summaries |
+| `replay_type` | string \| null | Replay type |
+| `org` | string | Organization slug |
+| `relatedIssues` | array | Replay-related issues |
+| `relatedTraces` | array | Replay-related traces |
+
+**Examples:**
+
+```bash
+# View a replay by ID using auto-detected org/project context
+sentry replay view 346789a703f6454384f1de473b8b9fcc
+
+# View a replay with an explicit org
+sentry replay view my-org/346789a703f6454384f1de473b8b9fcc
+
+# View a replay with explicit org/project context
+sentry replay view my-org/frontend/346789a703f6454384f1de473b8b9fcc
+
+# Open a replay in the browser
+sentry replay view my-org/346789a703f6454384f1de473b8b9fcc --web
+```
+
+All commands also support `--json`, `--fields`, `--help`, `--log-level`, and `--verbose` flags.

sentry-cli/references/repo.md

@@ -0,0 +1,50 @@
+---
+name: sentry-cli-repo
+version: 0.33.0
+description: Work with Sentry repositories
+requires:
+  bins: ["sentry"]
+  auth: true
+---
+
+# Repo Commands
+
+Work with Sentry repositories
+
+### `sentry repo list <org/project>`
+
+List repositories
+
+**Flags:**
+- `-n, --limit <value> - Maximum number of repositories to list - (default: "25")`
+- `-f, --fresh - Bypass cache, re-detect projects, and fetch fresh data`
+- `-c, --cursor <value> - Navigate pages: "next", "prev", "first" (or raw cursor string)`
+
+**JSON Fields** (use `--json --fields` to select specific fields):
+
+| Field | Type | Description |
+|-------|------|-------------|
+| `id` | string | Repository ID |
+| `name` | string | Repository name |
+| `url` | string \| null | Repository URL |
+| `provider` | object | Version control provider |
+| `status` | string | Integration status |
+| `dateCreated` | string | Creation date (ISO 8601) |
+| `integrationId` | string | Integration ID |
+| `externalSlug` | string \| null | External slug (e.g. org/repo) |
+| `externalId` | string \| null | External ID |
+
+**Examples:**
+
+```bash
+# List repositories (auto-detect org)
+sentry repo list
+
+# List repos in a specific org with pagination
+sentry repo list my-org/ -c next
+
+# Output as JSON
+sentry repo list --json
+```
+
+All commands also support `--json`, `--fields`, `--help`, `--log-level`, and `--verbose` flags.

sentry-cli/references/schema.md

@@ -0,0 +1,41 @@
+---
+name: sentry-cli-schema
+version: 0.33.0
+description: Browse the Sentry API schema
+requires:
+  bins: ["sentry"]
+  auth: true
+---
+
+# Schema Commands
+
+Browse the Sentry API schema
+
+### `sentry schema <resource...>`
+
+Browse the Sentry API schema
+
+**Flags:**
+- `--all - Show all endpoints in a flat list`
+- `-q, --search <value> - Search endpoints by keyword`
+
+**Examples:**
+
+```bash
+# List all API resources
+sentry schema
+
+# Browse issue endpoints
+sentry schema issues
+
+# View details for a specific operation
+sentry schema issues list
+
+# Search for monitoring-related endpoints
+sentry schema --search monitor
+
+# Flat list of every endpoint
+sentry schema --all
+```
+
+All commands also support `--json`, `--fields`, `--help`, `--log-level`, and `--verbose` flags.

sentry-cli/references/sourcemap.md

@@ -0,0 +1,69 @@
+---
+name: sentry-cli-sourcemap
+version: 0.33.0
+description: Manage sourcemaps
+requires:
+  bins: ["sentry"]
+  auth: true
+---
+
+# Sourcemap Commands
+
+Manage sourcemaps
+
+### `sentry sourcemap inject <directory>`
+
+Inject debug IDs into JavaScript files and sourcemaps
+
+**Flags:**
+- `--ext <value> - Comma-separated file extensions to process (default: .js,.cjs,.mjs)`
+- `--ignore <value> - Comma-separated glob patterns to exclude (gitignore-style)`
+- `--ignore-file <value> - Path to a file with gitignore-style patterns to exclude`
+- `--dry-run - Show what would be modified without writing`
+- `--allow-empty - Exit successfully when no JS + sourcemap pairs are found (default: error out to catch silent build misconfigurations)`
+
+**Examples:**
+
+```bash
+# Inject debug IDs into all JS files in dist/
+sentry sourcemap inject ./dist
+
+# Preview changes without writing
+sentry sourcemap inject ./dist --dry-run
+
+# Only process specific extensions
+sentry sourcemap inject ./build --ext .js,.mjs
+```
+
+### `sentry sourcemap upload <directory>`
+
+Upload sourcemaps to Sentry
+
+**Flags:**
+- `--release <value> - Release version to associate with the upload`
+- `--dist <value> - Distribution identifier to disambiguate builds within a release`
+- `--url-prefix <value> - URL prefix for uploaded files (default: ~/) - (default: "~/")`
+- `--ext <value> - Comma-separated file extensions to process (default: .js,.cjs,.mjs)`
+- `--ignore <value> - Comma-separated glob patterns to exclude (gitignore-style)`
+- `--ignore-file <value> - Path to a file with gitignore-style patterns to exclude`
+- `--strip-prefix <value> - Strip a prefix from uploaded file paths (e.g. 'build/')`
+- `--strip-common-prefix - Automatically strip the longest common path prefix from all files`
+- `--no-rewrite - Upload files as-is without injecting debug IDs`
+- `--allow-empty - Exit successfully when no JS + sourcemap pairs are found (default: error out to catch silent build misconfigurations)`
+
+**Examples:**
+
+```bash
+# Upload sourcemaps from dist/
+sentry sourcemap upload ./dist
+
+# Associate with a release
+sentry sourcemap upload ./dist --release 1.0.0
+
+# Set a custom URL prefix
+sentry sourcemap upload ./dist --url-prefix '~/static/js/'
+
+sentry sourcemap upload ./dist --allow-empty
+```
+
+All commands also support `--json`, `--fields`, `--help`, `--log-level`, and `--verbose` flags.

sentry-cli/references/span.md

@@ -0,0 +1,89 @@
+---
+name: sentry-cli-span
+version: 0.33.0
+description: List and view spans in projects or traces
+requires:
+  bins: ["sentry"]
+  auth: true
+---
+
+# Span Commands
+
+List and view spans in projects or traces
+
+### `sentry span list <org/project/trace-id...>`
+
+List spans in a project or trace
+
+**Flags:**
+- `-n, --limit <value> - Number of spans (<=1000) - (default: "25")`
+- `-q, --query <value> - Filter spans (e.g., "op:db", "project:backend", "project:[cli,api]")`
+- `-s, --sort <value> - Sort order: date, duration - (default: "date")`
+- `-t, --period <value> - Time range: "7d", "2026-04-01..2026-05-01", ">=2026-04-01" - (default: "7d")`
+- `-f, --fresh - Bypass cache, re-detect projects, and fetch fresh data`
+- `-c, --cursor <value> - Navigate pages: "next", "prev", "first" (or raw cursor string)`
+
+**JSON Fields** (use `--json --fields` to select specific fields):
+
+| Field | Type | Description |
+|-------|------|-------------|
+| `id` | string | Span ID |
+| `parent_span` | string \| null | Parent span ID |
+| `span.op` | string \| null | Span operation (e.g. http.client, db) |
+| `description` | string \| null | Span description |
+| `span.duration` | number \| null | Duration (ms) |
+| `timestamp` | string | Timestamp (ISO 8601) |
+| `project` | string | Project slug |
+| `transaction` | string \| null | Transaction name |
+| `trace` | string | Trace ID |
+
+**Examples:**
+
+```bash
+# List recent spans in the current project
+sentry span list
+
+# Find all DB spans
+sentry span list -q "op:db"
+
+# Slow spans in the last 24 hours
+sentry span list -q "duration:>100ms" --period 24h
+
+# List spans within a specific trace
+sentry span list abc123def456abc123def456abc12345
+
+# Paginate through results
+sentry span list -c next
+
+# Show only spans from one project within a trace
+sentry span list my-org/cli-server/abc123def456abc123def456abc12345
+
+# Or use --query to filter by project
+sentry span list abc123def456abc123def456abc12345 -q "project:cli-server"
+
+# Multiple projects at once
+sentry span list abc123def456abc123def456abc12345 -q "project:[cli-server,api]"
+```
+
+### `sentry span view <trace-id/span-id...>`
+
+View details of specific spans
+
+**Flags:**
+- `--spans <value> - Span tree depth limit (number, "all" for unlimited, "no" to disable) - (default: "3")`
+- `-f, --fresh - Bypass cache, re-detect projects, and fetch fresh data`
+
+**Examples:**
+
+```bash
+# View a single span
+sentry span view abc123def456abc123def456abc12345 a1b2c3d4e5f67890
+
+# View multiple spans at once
+sentry span view abc123def456abc123def456abc12345 a1b2c3d4e5f67890 b2c3d4e5f6789012
+
+# With explicit org/project
+sentry span view my-org/backend/abc123def456abc123def456abc12345 a1b2c3d4e5f67890
+```
+
+All commands also support `--json`, `--fields`, `--help`, `--log-level`, and `--verbose` flags.

sentry-cli/references/team.md

@@ -0,0 +1,48 @@
+---
+name: sentry-cli-team
+version: 0.33.0
+description: Work with Sentry teams
+requires:
+  bins: ["sentry"]
+  auth: true
+---
+
+# Team Commands
+
+Work with Sentry teams
+
+### `sentry team list <org/project>`
+
+List teams
+
+**Flags:**
+- `-n, --limit <value> - Maximum number of teams to list - (default: "25")`
+- `-f, --fresh - Bypass cache, re-detect projects, and fetch fresh data`
+- `-c, --cursor <value> - Navigate pages: "next", "prev", "first" (or raw cursor string)`
+
+**JSON Fields** (use `--json --fields` to select specific fields):
+
+| Field | Type | Description |
+|-------|------|-------------|
+| `id` | string | Team ID |
+| `slug` | string | Team slug |
+| `name` | string | Team name |
+| `dateCreated` | string \| null | Creation date (ISO 8601) |
+| `isMember` | boolean | Whether you are a member |
+| `teamRole` | string \| null | Your role in the team |
+| `memberCount` | number | Number of members |
+
+**Examples:**
+
+```bash
+# List teams
+sentry team list my-org/
+
+# Paginate through teams
+sentry team list my-org/ -c next
+
+# Output as JSON
+sentry team list --json
+```
+
+All commands also support `--json`, `--fields`, `--help`, `--log-level`, and `--verbose` flags.

sentry-cli/references/trace.md

@@ -0,0 +1,113 @@
+---
+name: sentry-cli-trace
+version: 0.33.0
+description: View distributed traces
+requires:
+  bins: ["sentry"]
+  auth: true
+---
+
+# Trace Commands
+
+View distributed traces
+
+### `sentry trace list <org/project>`
+
+List recent traces in a project
+
+**Flags:**
+- `-n, --limit <value> - Number of traces (1-1000) - (default: "25")`
+- `-q, --query <value> - Search query (Sentry search syntax)`
+- `-s, --sort <value> - Sort by: date, duration - (default: "date")`
+- `-t, --period <value> - Time range: "7d", "2026-04-01..2026-05-01", ">=2026-04-01" - (default: "7d")`
+- `-f, --fresh - Bypass cache, re-detect projects, and fetch fresh data`
+- `-c, --cursor <value> - Navigate pages: "next", "prev", "first" (or raw cursor string)`
+
+**JSON Fields** (use `--json --fields` to select specific fields):
+
+| Field | Type | Description |
+|-------|------|-------------|
+| `trace` | string | Trace ID |
+| `id` | string | Event ID |
+| `transaction` | string | Transaction name |
+| `timestamp` | string | Timestamp (ISO 8601) |
+| `transaction.duration` | number | Duration (ms) |
+| `project` | string | Project slug |
+
+**Examples:**
+
+```bash
+# List last 20 traces (default)
+sentry trace list
+
+# Sort by slowest first
+sentry trace list --sort duration
+
+# Filter by transaction name, last 24 hours
+sentry trace list -q "transaction:GET /api/users" --period 24h
+
+# Paginate through results
+sentry trace list my-org/backend -c next
+```
+
+### `sentry trace view <org/project/trace-id...>`
+
+View details of a specific trace
+
+**Flags:**
+- `-w, --web - Open in browser`
+- `--full - Fetch full span attributes (auto-enabled with --json)`
+- `--spans <value> - Span tree depth limit (number, "all" for unlimited, "no" to disable) - (default: "3")`
+- `-f, --fresh - Bypass cache, re-detect projects, and fetch fresh data`
+
+**Examples:**
+
+```bash
+# View trace details with span tree
+sentry trace view abc123def456abc123def456abc12345
+
+# Open trace in browser
+sentry trace view abc123def456abc123def456abc12345 -w
+
+# Auto-recover from an issue short ID
+sentry trace view PROJ-123
+
+# Filter trace view to one project's spans
+sentry trace view my-org/cli-server/abc123def456abc123def456abc12345
+
+# Full trace across all projects (default)
+sentry trace view my-org/abc123def456abc123def456abc12345
+
+# Filter trace logs by project
+sentry trace logs my-org/cli-server/abc123def456abc123def456abc12345
+
+# Multiple projects via --query
+sentry trace logs abc123def456abc123def456abc12345 -q "project:[cli-server,api]"
+```
+
+### `sentry trace logs <org/project/trace-id...>`
+
+View logs associated with a trace
+
+**Flags:**
+- `-w, --web - Open trace in browser`
+- `-t, --period <value> - Time range: "7d", "2026-04-01..2026-05-01", ">=2026-04-01" - (default: "14d")`
+- `-n, --limit <value> - Number of log entries (<=1000) - (default: "100")`
+- `-q, --query <value> - Filter query (e.g., "level:error", "project:backend", "project:[a,b]")`
+- `-s, --sort <value> - Sort order: "newest" (default) or "oldest" - (default: "newest")`
+- `-f, --fresh - Bypass cache, re-detect projects, and fetch fresh data`
+
+**Examples:**
+
+```bash
+# View logs for a trace
+sentry trace logs abc123def456abc123def456abc12345
+
+# Search with a longer time window
+sentry trace logs --period 30d abc123def456abc123def456abc12345
+
+# Filter logs within a trace
+sentry trace logs -q 'level:error' abc123def456abc123def456abc12345
+```
+
+All commands also support `--json`, `--fields`, `--help`, `--log-level`, and `--verbose` flags.

sentry-cli/references/trial.md

@@ -0,0 +1,52 @@
+---
+name: sentry-cli-trial
+version: 0.33.0
+description: Manage product trials
+requires:
+  bins: ["sentry"]
+  auth: true
+---
+
+# Trial Commands
+
+Manage product trials
+
+### `sentry trial list <org>`
+
+List product trials
+
+**JSON Fields** (use `--json --fields` to select specific fields):
+
+| Field | Type | Description |
+|-------|------|-------------|
+| `category` | string | Trial category (e.g. seerUsers, seerAutofix) |
+| `startDate` | string \| null | Start date (ISO 8601) |
+| `endDate` | string \| null | End date (ISO 8601) |
+| `reasonCode` | number | Reason code |
+| `isStarted` | boolean | Whether the trial has started |
+| `lengthDays` | number \| null | Trial duration in days |
+
+### `sentry trial start <name> <org>`
+
+Start a product trial
+
+**Examples:**
+
+```bash
+# List all trials for the current org
+sentry trial list
+
+# List trials for a specific org
+sentry trial list my-org
+
+# Start a Seer trial
+sentry trial start seer
+
+# Start a trial for a specific org
+sentry trial start replays my-org
+
+# Start a Business plan trial (opens browser)
+sentry trial start plan
+```
+
+All commands also support `--json`, `--fields`, `--help`, `--log-level`, and `--verbose` flags.

using-git-worktrees/SKILL.md

@@ -1,90 +0,0 @@
----
-name: using-git-worktrees
-description: Use when starting feature work that needs isolation from current workspace or before executing implementation plans - ensures an isolated workspace exists via native tools or git worktree fallback
----
-
-# Using Git Worktrees
-
-Ensure work happens in an isolated workspace when appropriate. Prefer platform-native worktree tools. Fall back to manual `git worktree` only when no native tool is available.
-
-Announce at start: "I'm using the using-git-worktrees skill to set up an isolated workspace."
-
-## Workflow
-
-### 1. Detect Existing Isolation
-
-Before creating anything, check whether you are already in a linked worktree:
-
-```bash
-GIT_DIR=$(cd "$(git rev-parse --git-dir)" 2>/dev/null && pwd -P)
-GIT_COMMON=$(cd "$(git rev-parse --git-common-dir)" 2>/dev/null && pwd -P)
-BRANCH=$(git branch --show-current)
-git rev-parse --show-superproject-working-tree 2>/dev/null
-```
-
-If `GIT_DIR != GIT_COMMON` and `show-superproject-working-tree` is empty, you are already in a linked worktree. Do not create another one. Report the path and branch, then continue to project setup.
-
-If `GIT_DIR == GIT_COMMON` or this is a submodule, treat it as a normal repo checkout.
-
-### 2. Get Consent
-
-If the user has not already declared a worktree preference, ask:
-
-> Would you like me to set up an isolated worktree? It protects your current branch from changes.
-
-If the user declines, work in place and continue to project setup.
-
-### 3. Create Isolated Workspace
-
-Use mechanisms in this order:
-
-1. Native worktree tool if the platform provides one, such as `EnterWorktree`, `WorktreeCreate`, `/worktree`, or a `--worktree` flag.
-2. Manual `git worktree add` only if no native tool exists.
-
-Manual directory priority:
-
-1. Explicit user/instruction preference.
-2. Existing project-local `.worktrees/`.
-3. Existing project-local `worktrees/`.
-4. Default to `.worktrees/` at the project root.
-
-Before creating a project-local worktree, verify the chosen directory is ignored:
-
-```bash
-git check-ignore -q .worktrees 2>/dev/null || git check-ignore -q worktrees 2>/dev/null
-```
-
-If not ignored, add it to `.gitignore`, commit that change, then proceed.
-
-```bash
-git worktree add "$path" -b "$BRANCH_NAME"
-cd "$path"
-```
-
-If `git worktree add` is blocked by sandbox permissions, tell the user and work in the current directory instead.
-
-### 4. Project Setup
-
-Auto-detect setup where appropriate:
-
-```bash
-if [ -f package.json ]; then npm install; fi
-if [ -f Cargo.toml ]; then cargo build; fi
-if [ -f requirements.txt ]; then pip install -r requirements.txt; fi
-if [ -f pyproject.toml ]; then poetry install; fi
-if [ -f go.mod ]; then go mod download; fi
-```
-
-### 5. Baseline Verification
-
-Run project-appropriate tests before implementation when practical: `npm test`, `cargo test`, `pytest`, `go test ./...`, or equivalent.
-
-If tests fail, report failures and ask whether to proceed or investigate. If tests pass, report readiness.
-
-## Never
-
-- Create a worktree when already in a linked worktree.
-- Use `git worktree add` when a native worktree tool exists.
-- Skip submodule detection.
-- Create a project-local worktree without ignore verification.
-- Proceed from failing baseline tests without telling the user.