vetr0s
- 9 skills
- 0 followers
- 6 hours ago last updated
- ▌ How · vetr0sExplain how a subsystem works, at the level of an engineer being onboarded onto it. Use for "how does X work", "walk me through X", "explain this subsystem", a code walkthrough before changing something, and placement questions like "where should this live" or "which layer owns this". Can also critique the architecture on request. Use `audit` for whole-project health and `blast-radius` for what a change breaks.
- ▌ Audit · vetr0sWhole-project read-only review of a project's current state, covering architecture, code health, correctness risks, tests, documentation drift, and tooling, using parallel exploration agents and reported as an HTML document. Use when the user says "audit the code", "audit this", "what's the state of this project", "review the whole codebase", or asks for a holistic or overall review rather than a review of a specific diff.
- ▌ Debug · vetr0sDiagnosis loop for a bug or a performance regression, built around a fast reproducible check that goes red on the bug. Use when the user says "debug this", "diagnose", "why is this broken", or reports something crashing, hanging, corrupting, leaking, giving wrong output, or running slow. Covers native crashes, memory errors, and frame-time regressions.
- ▌ Commit · vetr0sWrite a git commit for the current changes with a message that explains why the change was made. Use whenever the user asks to commit, stage and commit, "check this in", or write a commit message. Also covers amending, rewording, splitting one messy change into several commits, and fixing a message that already landed.
- ▌ Unslop · vetr0s bundleStrip AI tells out of prose. A catalogue of the patterns that make writing read as machine-generated, each with its fix. Use before shipping any README, doc, comment, commit body, blog post, or report, and when the user says "unslop this", "this reads like AI", "de-slop", or complains about em dashes, filler, or LLM voice.
- ▌ Architect · vetr0sDesign the shape of a change before writing it. Sketch the caller's usage, the types, and the signatures first, compare competing shapes, then implement against the chosen one. Use for "plan this", "design this", "architect this", "how should I structure X", "what's the plan for", and any non-trivial work where jumping into code would lock in the wrong shape.
- ▌ Blast Radius · vetr0sWork out what a change breaks somewhere else, before it ships, and prove the one fact it is safe because of by running code. Use for "blast radius", "what could this break", "is this safe to change", changes to a header or a public struct, and small diffs you do not trust. Use `how` to understand a subsystem and `debug` once something is already broken.
- ▌ Standard HTML · vetr0s bundleWrite plans, code and directory state summaries, audit reports, design docs, and decision records as plain HTML documents in a fixed house style instead of Markdown. Use whenever the user asks for a plan, an explanation of how something works, a comparison, a state-of-the-code summary, or any document holding complex structure such as tables, decisions, status, or phased work. Also use when the user says "make a doc", "write this up", "standard html", or references the house style.
- ▌ Writing For Agents · vetr0sHow to write a document an agent will execute. Use when creating or editing a skill in this repo, editing CLAUDE.md or AGENTS.md, or writing any file whose reader is an agent rather than a person. Covers frontmatter, descriptions that actually trigger, what to inline versus push behind a pointer, and how to prune.