← all publishers

terion-labs

@terion-labs source repo

5 published skills

  1. Security Audit · terion-labs bundle
    Run a thorough, defender-first security audit of a codebase, modeled on the Codex/Aardvark pipeline: build/refresh a threat model, scan current code and recent commits for vulnerabilities and serious commit-introduced functional regressions, validate findings, chain exploitable issues, rank by severity, and write `.security/` artifacts. Use whenever the user invokes `/security-audit`, `/sec-audit`, `/sec-review`, or asks to scan/audit/review code they control for vulnerabilities, CVEs, XSS, SQLi, SSRF, RCE, secrets, memory-safety bugs, threat modeling, PR/diff security review, or asks whether code is safe. Defensive assessment of the user's own codebase only.
    0
    installs
  2. Writing Good Code · terion-labs bundle
    Use when writing new code in any language — implementing a feature, adding a module, sketching a design, writing a script, building an endpoint, or extending existing code with a new piece. Covers naming, module shape, abstraction depth, error handling, readability, language idioms, and practical tactics against over-engineering. Trigger whenever the user asks to "write", "implement", "build", "add", "create", "design", "prototype", or "extend" code, a function, a class, a module, a component, a script, an endpoint, or a feature — even when they do not say "quality" or "clean code". Also trigger when the user says they want code that is "simple", "clean", "readable", "maintainable", "elegant", or "idiomatic". Do NOT use for pure refactoring of existing code without behavior change (use refactoring-and-reviewing-code); do NOT use for a focused decision about whether one specific abstraction is worth extracting (use abstraction-quality).
    0
    installs
  3. Abstraction Quality · terion-labs bundle
    Use when deciding whether to extract a function, introduce an interface, create a new class, add a helper, split a module, add a plugin hook, or generalize a piece of code; when reviewing a pull request that proposes a new abstraction; when a shared helper is growing flag parameters; when you have duplication and are unsure whether to extract it; or when an existing abstraction feels wrong but you cannot name why. Also trigger when the user asks "should I extract this?", "is this the right abstraction?", "is this over-engineered?", "is this DRY enough?", "should I generalize this?", "should I add an interface here?", or "is this premature abstraction?". This skill provides a decision procedure; it is referenced by writing-good-code and refactoring-and-reviewing-code, and can also be used on its own.
    0
    installs
  4. Orpc Contract First · terion-labs
    Use when designing, implementing, refactoring, or reviewing an oRPC API with contract-first architecture, especially in a TypeScript monorepo. Trigger when the user mentions oRPC contracts, `@orpc/contract`, `implement(contract)`, shared API contracts, monorepo API packages, OpenAPI-to-oRPC generation, router-to-contract migration, or keeping web/client and API/server apps type-safe through a shared package. This skill guides agents to put contracts and schemas in a dedicated shared package, keep business logic out of the contract, implement contracts from server packages/apps, and wire clients without leaking server internals.
    0
    installs
  5. Refactoring And Reviewing Code · terion-labs bundle
    Use when asked to refactor, clean up, restructure, simplify, review, untangle, decouple, flatten, or improve existing code without changing its behavior; when diagnosing code smells; when preparing a codebase for a new feature by first making the change easy; or when the user says "this is messy / confusing / hard to follow / too complex" and wants it improved. Trigger on "refactor", "clean up", "restructure", "simplify", "review this code", "code smell", "tidy", "improve", "untangle", "decouple", "flatten", "extract", "rename", or when the user pastes code and asks what is wrong with it, what could be better, or how it could be more readable. Do NOT use when writing new code from scratch (use writing-good-code); do NOT use for the specific question of whether one abstraction is worth extracting (use abstraction-quality). When a task genuinely requires both behavior change and cleanup, refactor first under this skill, commit, then switch to writing-good-code for the behavior change.
    0
    installs