booskills

Assumes all code is insecure, full of PII leaks, and an easy attack surface. Performs adversarial security analysis to prove real security vulnerabilities exist in first-party code and dependencies - not potential vulnerabilities, but actual exploit paths with file-level evidence. Use when thorough security vulnerability analysis is needed alongside or independent of a code review. Every finding requires a demonstrated exploit path or CVE reference. Does not report theoretical risks - if the evidence standard cannot be met, no finding is reported.

Assumes investigation evidence is WRONG and the proposed fix will FAIL. Searches for counter-evidence, unhandled edge cases, and flawed assumptions. Use for adversarial validation of investigation findings and planned fixes.

Analyzes the runtime behavior of a specified codebase focus area - data flow, error propagation, state management, and integration boundaries. Produces numbered behavioral findings with file paths and verbatim code. Use when evaluating how data moves through a system, where errors are handled or lost, and how modules interact at runtime. Does not analyze static structure or coupling - use structural-analyst. Does not assess risk of inaction - use risk-analyst. Does not investigate specific bugs - use evidence-based-investigator. Does not recommend intra-codebase changes - use software-architect. Does not recommend cross-service or bounded-context changes - use system-architect.

Analyzes concurrency and async patterns in a specified codebase focus area - race conditions, shared resource contention, deadlock potential, lock ordering, and async error handling. Produces numbered concurrency findings with file paths and verbatim code. Use when evaluating thread safety, async correctness, or parallel execution risks. Does not analyze static structure - use structural-analyst. Does not trace general data flow - use behavioral-analyst. Does not assess risk of inaction - use risk-analyst. Does not recommend intra-codebase changes - use software-architect. Does not recommend cross-service or bounded-context changes (sagas, distributed coordination, idempotency at the wire) - use system-architect.

Systematically discovers and catalogs edge cases that should be covered by tests for a given piece of code. Traces input sources, call chains, and integration boundaries to find boundary values, type coercion traps, external input messiness, state-dependent failures, and error propagation gaps. Use when exploring how code can fail, identifying untested edge cases, or preparing an edge case plan before writing tests. Does not write tests or plan overall test coverage - produces an edge case discovery and prioritization plan only. Defaults to focused mode targeting crashes, data corruption, and systemic failures; request 'exhaustive exploration' for comprehensive analysis.

Evaluates the architecture of a codebase or subsystem and recommends intra-codebase structural changes with evidence. Use for "is this well structured," coupling/cohesion questions, layering review, "should I split this," module boundary decisions. Do NOT use for producing a neutral context map; use boo-mapping-project-context. Do NOT use for reviewing one diff; use boo-reviewing-code.

Scans a codebase or module for AI slop, refactor candidates, and optimization opportunities, scored against high-quality code standards, producing a prioritized remediation backlog. Use for "clean up this codebase," "find the slop," "what needs refactoring," periodic health checks, post-vibe-coding cleanup. Do NOT use for reviewing a specific diff; use boo-reviewing-code. Do NOT use for diagnosing a failure; use boo-investigating-failures. Do NOT use to execute refactors; use boo-refactoring-code.

Builds new frontend UI (pages, screens, components, flows) to high-end design standards: deliberate color strategy, typography, layout, motion, full interaction-state coverage, accessibility, and an AI-slop self-check before handoff. Use for "build a landing page," "add a settings screen," "create this component," "make the frontend for X." Do NOT use to critique or grade existing UI; use boo-critiquing-frontend. Do NOT use for OpenSpec change-folder work; use boo-implementing-changes.

Critiques frontend UI/UX implementation and design quality: visual hierarchy, spacing, typography, interaction states, accessibility, component structure. Use for "review my UI," "does this look right," screenshot critiques, component quality checks. Do NOT use for backend code review; use boo-reviewing-code. Do NOT use for building new UI; use boo-building-ui.

Implements an existing validated OpenSpec change folder task-by-task, marking tasks.md as it goes, and verifies against specs/. Use when a change folder exists under openspec/changes/ and the operator says implement, apply, build it, or continue. Do NOT use without a change folder; use boo-planning-changes first. Do NOT use for ad-hoc fixes outside the OpenSpec flow.