nullvoidundefined
@nullvoidundefined
Public Skills
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.
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.
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.
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"
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.
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.
audit-marketing
by nullvoidundefined
Use this agent to conduct a marketing audit (CMO perspective): positioning, conversion copy, pricing page effectiveness, trust signals, banned-word scans, and truth-vs-claim drift between marketing pages and backend behavior. Use when the user asks for a marketing audit or before any major launch or pricing change. Produces docs/audits/YYYY-MM-DD-marketing.md and commits it.
audit-financial
by nullvoidundefined
Use this agent to conduct a financial audit (CFO perspective): spending caps, unit economics, margin violations, SaaS creep, and runway forecasting. Use when the user asks for a financial audit, before a pricing change, or when adding new paid integrations. Produces docs/audits/YYYY-MM-DD-financial.md and commits it.
session-handoff
by nullvoidundefined
Use at the end of a session to write the handoff doc, route learnings to memory, and commit and push a dirty ~/.claude (R-601, R-602, R-603).
audit-design
by nullvoidundefined
Use this agent to conduct a visual design audit (Chief Design Officer perspective): brand consistency, typography, color, spacing, component coherence, and style drift. Use when the user asks for a design audit, after a visual change, or when the product feels inconsistent across surfaces. Rubric-driven and Sonnet-appropriate. Produces docs/audits/YYYY-MM-DD-design.md and commits it.
known-issues
by nullvoidundefined
Use before any production deploy, or when debugging a failure that resembles a prior deployment incident.
audit-criticism
by nullvoidundefined
Use this agent to conduct a devil's-advocate critique of a project: strategic flaws, unsustainable unit economics, organizational self-deception, moat delusion, and process-vs-outcome imbalance. Use when the user asks for a criticism audit, when a strategic decision feels too comfortable, or before committing to a direction that is hard to reverse. Produces docs/audits/YYYY-MM-DD-criticism.md and commits it.
audit-legal
by nullvoidundefined
Use this agent to conduct a legal and compliance audit (Head of Legal perspective): missing legal documents, privacy policy gaps, DPAs, unsubstantiated marketing claims, and open source license compliance. Use when the user asks for a legal audit, before any public launch, or when adding billing features. Produces docs/audits/YYYY-MM-DD-legal.md and commits it.
audit-ux
by nullvoidundefined
Use this agent to conduct a UX audit (Chief Experience Officer perspective): user flows, accessibility, error states, onboarding, form design, empty states, and friction points. Use when the user asks for a UX audit, pre-launch, or after a UI overhaul. Rubric-driven and Sonnet-appropriate. Produces docs/audits/YYYY-MM-DD-ux.md and commits it.
audit-customer
by nullvoidundefined
Use this agent to conduct a customer-perspective walkthrough of the product as an actual customer (not a UX expert, not a researcher). Walks the marketing site, signup, first session, first paid action, and reports moments of friction, confusion, trust break, and delight in plain language. Counterpart to the CXO audit; complements rather than replaces it. Use before launch, after major UX changes, when the team feels stuck on "why aren't people adopting this," or when the user explicitly asks for a customer audit. Produces docs/audits/YYYY-MM-DD-customer.md and commits it.
spec-conformance-review
by nullvoidundefined
Use this agent to review the current diff against a named spec or plan file and report only where the diff fails to satisfy that spec. Use after implementing against an approved spec, before merge, or when the user asks whether the implementation actually matches what was specified. Distinct from /code-review, which reviews a diff against itself with no spec, and from the gof skill, which reviews a spec with no diff. Requires a spec or plan file path in the dispatch prompt; without one it has nothing to review against and says so. Reports gaps only, never style, naming taste, or additional abstraction. Reports nothing and says "No gaps found." when the diff satisfies the spec.
known-issues
by nullvoidundefined
Use before any production deploy, or when debugging a failure that resembles a prior deployment incident.