nullvoidundefined
@nullvoidundefined
Public Skills
structure-conventions
by nullvoidundefined
The stack-specific structural and syntax rules (R-304, R-305, R-309 to R-314, R-319, R-321, R-323, R-324, R-326 to R-329, R-407). Use before creating, moving, splitting, or renaming a directory, module, migration, or test tree in a server or web client (TypeScript, Python, Vue, or Nuxt), before writing a pg migration or Alembic default, and when planning a package layout. Each rule here is also enforced mechanically at the tool call, so this skill is the pre-emptive read, not the backstop.
audit-security
by nullvoidundefined
Use this agent to conduct a security audit (CISO perspective) of a codebase: auth bypasses, CSRF, prompt injection, dependency CVEs, secrets management, credential exposure across git history and Claude Code session transcripts. Use when the user asks for a security audit, before any launch, or after touching auth, sessions, or secret handling. Produces docs/audits/YYYY-MM-DD-security.md and commits it. Has explicit authorization to read .env.example but never .env or any live credential file.
audit-engineering
by nullvoidundefined
Use this agent to conduct a comprehensive engineering audit (CTO perspective) of a codebase: architecture, code quality, security, database, API design, performance, testing, dependencies, deployment, bug-fix discipline, runbook-vs-code drift, and workspace hygiene. Use when the user asks for an engineering audit, before a major launch, or after shipping 5 or more commits on a single surface. Produces docs/audits/YYYY-MM-DD-engineering.md and commits it. Scope can be narrowed in the dispatch prompt (e.g., "focus on server/" or "only the generation pipeline").
add-stack-track
by nullvoidundefined
Use when adding a new stack or framework track to the convention files (a new CLAUDE-<TRACK>.md), or when auditing an existing track for missing wiring. Triggers on "add a stack track", "add conventions for <language or framework>", "wire up CLAUDE-<TRACK>.md", or a rules/ symlink, session-types row, or manifest entry found missing for a track.
add-stack-track
by nullvoidundefined
Use when adding a new stack or framework track to the convention files (a new CLAUDE-<TRACK>.md), or when auditing an existing track for missing wiring. Triggers on "add a stack track", "add conventions for <language or framework>", "wire up CLAUDE-<TRACK>.md", or a rules/ symlink, session-types row, or manifest entry found missing for a track.
add-stack-track
by nullvoidundefined
Use when adding a new stack or framework track to the convention files (a new CLAUDE-<TRACK>.md), or when auditing an existing track for missing wiring. Triggers on "add a stack track", "add conventions for <language or framework>", "wire up CLAUDE-<TRACK>.md", or a rules/ symlink, session-types row, or manifest entry found missing for a track.
all-hands
by nullvoidundefined
Use at the start of a work week, or when deciding what to prioritize and a single reviewer's view is not enough - engineering, security, criticism, design, UX, customer, financial, legal, and marketing all weigh in.
bug-hunt
by nullvoidundefined
Use when the user asks to find bugs, audit code quality, or hunt for issues in recent changes. Also use proactively after shipping 5+ commits on a feature branch before merge.
gof
by nullvoidundefined
Use when a spec, plan, or feature needs review from several angles at once - feasibility, security, unstated assumptions, and design - rather than one reviewer's read. Also known as Gang of Four, GoF, or four-perspective review.
known-issues
by nullvoidundefined
Use before any production deploy, or when debugging a failure that resembles a prior deployment incident.
protocol
by nullvoidundefined
Use when debugging a process failure, reviewing why a rule exists, or onboarding to the operating protocol.
spec-grounding
by nullvoidundefined
Use when handed a spec, plan, or design document written outside this repo that describes intent but names no real files, interfaces, or existing code. Grounds it against the actual codebase and outputs an updated spec. Triggers on "ground this spec", "check this spec against the codebase", "does this spec match the repo", or handing over a spec file before implementation starts. Not for writing a spec from scratch (use brainstorming and writing-plans) and not for implementing one.
documentation-create
by nullvoidundefined
Use when writing or revising any explanatory document - technical explainer, onboarding doc, architecture note, README, design rationale, post-mortem, briefing, or report. Also use when a draft reads as terse, assertive, or unsupported, or when a reader would have to infer what a sentence means.
resolve-user-feedback
by nullvoidundefined
Use when the user wants to triage or address accumulated user-submitted feature requests and bug reports held in an application feedback table.
cleanup-specs-plans
by nullvoidundefined
Use when specs and plans folders contain stale files from completed work, at session end after shipping features, or when starting a new development phase. Also use when the user says "clean up specs", "audit plans", or "what's stale in docs"
gof
by nullvoidundefined
Use when a spec, plan, or feature needs review from several angles at once - feasibility, security, unstated assumptions, and design - rather than one reviewer's read. Also known as Gang of Four, GoF, or four-perspective review.
gof
by nullvoidundefined
Use when a spec, plan, or feature needs review from several angles at once - feasibility, security, unstated assumptions, and design - rather than one reviewer's read. Also known as Gang of Four, GoF, or four-perspective review.
all-hands
by nullvoidundefined
Use at the start of a work week, or when deciding what to prioritize and a single reviewer's view is not enough - engineering, security, criticism, design, UX, customer, financial, legal, and marketing all weigh in.
protocol
by nullvoidundefined
Use when debugging a process failure, reviewing why a rule exists, or onboarding to the operating protocol.
all-hands
by nullvoidundefined
Use at the start of a work week, or when deciding what to prioritize and a single reviewer's view is not enough - engineering, security, criticism, design, UX, customer, financial, legal, and marketing all weigh in.
bug-hunt
by nullvoidundefined
Use when the user asks to find bugs, audit code quality, or hunt for issues in recent changes. Also use proactively after shipping 5+ commits on a feature branch before merge.
spec-grounding
by nullvoidundefined
Use when handed a spec, plan, or design document written outside this repo that describes intent but names no real files, interfaces, or existing code. Grounds it against the actual codebase and outputs an updated spec. Triggers on "ground this spec", "check this spec against the codebase", "does this spec match the repo", or handing over a spec file before implementation starts. Not for writing a spec from scratch (use brainstorming and writing-plans) and not for implementing one.
protocol
by nullvoidundefined
Use when debugging a process failure, reviewing why a rule exists, or onboarding to the operating protocol.
cleanup-specs-plans
by nullvoidundefined
Use when specs and plans folders contain stale files from completed work, at session end after shipping features, or when starting a new development phase. Also use when the user says "clean up specs", "audit plans", or "what's stale in docs"