jacked

Use after adding several rules to CLAUDE.md, or when rules feel contradictory or stale. Audits for duplicates, contradictions, and vague directives. Companion to /learn.

Use before and after performance-sensitive changes. Captures web performance metrics, compares against baselines, flags regressions.

Use when browser MCP tools are failing, stuck, or unresponsive. Diagnoses connection issues, kills stale processes, and tests connectivity.

Use after a production deploy to monitor for regressions. Takes periodic screenshots, checks console errors, and compares performance against baselines.

Use after implementing security-sensitive changes — auth, RBAC, multi-tenancy, billing, credential handling. Systematic OWASP Top 10 + STRIDE threat model analysis.

Use after completing a plan, implementation, or any non-trivial code change. Auto-detects phase and spawns appropriate review threads with pre-mortem analysis.

Use after implementing a feature, fixing a bug, or completing any non-trivial code change. Recursive multi-lens review that continues until all selected lenses pass clean.

Use when a branch has code changes that may have made documentation stale, after completing a feature, or before creating a PR.

Use when debugging in a focused area or working on sensitive code to prevent accidental edits outside the target directory.

Use when setting up jacked in a new repo or after significant codebase changes. Analyzes the repo and generates faster, customized versions of jacked commands.

Use after a PR is approved and CI passes. Merges, waits for deploy, runs canary checks, and offers revert on failure.

Use after corrections, mistakes, or when the user wants to codify a preference into a permanent CLAUDE.md rule.

Use when checking PR status, creating a PR, or managing the pull request workflow for the current branch.

Use when testing UI changes for visual correctness, interactions, console errors, and edge cases. Pass a URL as argument, or let it auto-detect.

Use when an approach has gone sideways and patching patches. Scraps the current approach and re-implements from scratch with full hindsight after structured reflection.

Use when ready to cut a release. Bumps version, commits, pushes, verifies CI, creates GitHub Release for PyPI publishing.

Use periodically during long sessions or weekly. Analyzes git history for contributor metrics, test health, velocity trends, and team patterns.

Use when approaching non-trivial planning — architectural decisions, major features, system design, or any decision with multiple viable approaches.

Use when implementing a plan with multiple independent tasks that can be worked in parallel using Claude Code's experimental agent teams.

Use periodically during long sessions to scan for accumulating debt. Finds TODOs, oversized files, missing tests, linter issues, and dead code. Pass a path to focus on a specific area.

Use when done working in a frozen directory and ready to allow edits anywhere again. Removes the restriction set by /freeze.

Use when UI changes span multiple components or pages, layout or navigation changed, a new user-facing feature was added, or comprehensive UX validation is needed.

Use when the user asks "what should I work on", "what's next", "what are our priorities", or "where should I start". Recommends highest-yield next work items.

Use this agent when you need to review recently written code changes with a focus on simplicity, readability, and future-proofing. This agent excels at identifying overly complex implementations and suggesting cleaner, more maintainable alternatives that accomplish the same goals. Perfect for post-implementation reviews, refactoring sessions, or when you want to ensure your code is easily understood by other developers. Examples: <example> Context: The user wants to review code they just wrote for simplicity and readability. user: "I just implemented a new feature for processing medical claims. Can you review it?" assistant: "I'll use the code-simplicity-reviewer agent to analyze your recent changes and suggest simpler approaches." <commentary> Since the user has written new code and wants a review focused on simplicity, use the code-simplicity-reviewer agent. </commentary> </example> <example> Context: After completing a complex implementation. user: "I've finished the reflexive batch processing logic but it feels complicated." assistant: "Let me use the code-simplicity-reviewer agent to examine your implementation and identify opportunities for simplification." <commentary> The user has completed code and is concerned about complexity, making this perfect for the code-simplicity-reviewer agent. </commentary> </example>

Use this agent when you need to review code for error handling, add comprehensive error management, or audit existing code for potential failure points. This agent excels at identifying missing error handling, suggesting custom exception hierarchies, and implementing defensive programming patterns. Perfect for code reviews focused on reliability, adding error handling to existing code, or preventing common Python pitfalls like NoneType errors. Examples: - <example> Context: The user wants to review recently written code for error handling issues. user: "I just implemented a new API client module" assistant: "Let me review this code for error handling and defensive programming practices" <commentary> Since new code was written, use the defensive-error-handler agent to review for potential error scenarios and suggest improvements. </commentary> </example> - <example> Context: The user is concerned about error handling in their codebase. user: "Can you check if we're properly handling errors in our data processing pipeline?" assistant: "I'll use the defensive-error-handler agent to audit the error handling in your data processing code" <commentary> The user explicitly wants error handling reviewed, so use the defensive-error-handler agent. </commentary> </example> - <example> Context: After implementing new functionality. user: "I've added the new claim validation logic" assistant: "Now let me review this for proper error handling and defensive programming" <commentary> New code should be reviewed for error handling, use the defensive-error-handler agent. </commentary> </example>

Use this agent when you've completed a design document, planning session, or code implementation and want a fresh, critical review. This agent operates in two modes: (1) Design Review Mode - when the recent work involved creating specs, design docs, or planning for features/bugs/enhancements, it performs independent research and validates assumptions; (2) Code Review Mode - when recent work involved actual implementation, it acts as CTO/CSO reviewing for security vulnerabilities, auth gaps, cross-org data leaks, and architectural soundness. Examples:\n\n<example>\nContext: User just finished creating a design document for a new billing export feature.\nuser: "Okay I think that design doc looks good, let's move on"\nassistant: "Hold up - before we proceed, let me use the double-check-reviewer agent to validate this design with fresh eyes and independent research."\n<commentary>\nSince the user just completed a design document, use the double-check-reviewer agent in Design Review Mode to independently validate assumptions and research alternatives.\n</commentary>\n</example>\n\n<example>\nContext: User just implemented several new API endpoints and database queries for multi-tenant data access.\nuser: "Alright that implementation is done, what's next?"\nassistant: "Before we move forward, I'm going to spin up the double-check-reviewer agent to do a security and architecture review of what we just built."\n<commentary>\nSince the user just wrote implementation code with multi-tenant implications, use the double-check-reviewer agent in Code Review Mode to audit for security, auth, and data isolation issues.\n</commentary>\n</example>\n\n<example>\nContext: User completed a feature implementation touching auth routes and user data.\nuser: "double check this"\nassistant: "On it - launching the double-check-reviewer to give this implementation the CTO/CSO treatment."\n<commentary>\nExplicit request for review after code implementation - use the double-check-reviewer agent in Code Review Mode.\n</commentary>\n</example>

Use this agent when you need help managing git branches, commits, and pull requests to maintain clean, reviewable code submissions. This includes: creating new branches for features or bug fixes, determining when to split work into separate PRs, writing comprehensive PR descriptions and commit messages, analyzing uncommitted changes to suggest logical groupings, and ensuring PRs stay focused and manageable in size (typically under 200-300 lines of changes). <example> Context: The user has been making multiple code changes with Claude and wants to organize them into proper PRs. user: "I've made a bunch of changes to the codebase - added a new reflexive processing feature, fixed several bugs in the ICD validation, and updated some documentation. Help me organize this into PRs" assistant: "I'll use the git-pr-workflow-manager agent to analyze your changes and create a proper branching and PR strategy" <commentary> Since the user has multiple types of changes that need to be organized into separate, reviewable PRs, use the git-pr-workflow-manager agent. </commentary> </example> <example> Context: User is about to start implementing a major new feature. user: "I'm going to add a new specialty module for cardiology to the KRAC system" assistant: "Let me use the git-pr-workflow-manager agent to help you set up the right branch structure before you start" <commentary> Since this is a major new feature that will need its own branch and PR, use the git-pr-workflow-manager agent to establish proper workflow from the start. </commentary> </example> <example> Context: User has been fixing bugs and wants to submit changes. user: "I've fixed 5 different bugs in the validation pipeline. Should I commit these?" assistant: "I'll use the git-pr-workflow-manager agent to help you organize these bug fixes into a proper PR" <commentary> Multiple bug fixes need to be properly documented and submitted as a cohesive PR, so use the git-pr-workflow-manager agent. </commentary> </example>

Use this agent when you need to manage GitHub issues and pull requests in a coordinated manner. This includes scanning open issues, analyzing and grouping related issues for efficient resolution, managing PR workflows, and ensuring proper issue tracking throughout the development cycle. The agent excels at identifying which issues can be resolved together, creating well-structured PRs, and maintaining clear communication about work progress. Examples: - <example> Context: User wants to review and organize their GitHub issues to work on them efficiently. user: "Can you help me organize my open GitHub issues and suggest which ones I should work on together?" assistant: "I'll use the issue-pr-coordinator agent to analyze your open issues and suggest logical groupings." <commentary> The user needs help organizing GitHub issues, which is exactly what the issue-pr-coordinator agent is designed for. </commentary> </example> - <example> Context: User has multiple related bug fixes and wants to create a PR. user: "I've fixed several related bugs in the authentication module. Can you help me create a proper PR?" assistant: "Let me use the issue-pr-coordinator agent to help you create a well-structured PR with proper issue linking." <commentary> Creating PRs with proper issue linking and organization is a core function of the issue-pr-coordinator agent. </commentary> </example> - <example> Context: User wants to check the status of their repository's issues and PRs. user: "What's the current state of our open issues and PRs?" assistant: "I'll launch the issue-pr-coordinator agent to scan and analyze your repository's current status." <commentary> Checking repository status and providing organized summaries is within the issue-pr-coordinator agent's capabilities. </commentary> </example>

Use this agent when you need to check your current PR status and manage pull request workflow. Analyzes current branch state, determines if a PR exists or needs to be created, examines commits and changes, searches for related issues, and handles PR creation/updates with proper issue linking. Perfect for the typical post-coding workflow when you want to figure out what needs to happen next with your PR.

Use this agent when you need to update or maintain README documentation with current codebase information including entry points, environment variables, installation instructions, usage examples, requirements, and processing outputs. This agent should be triggered after significant code changes, when adding new features, changing APIs, modifying environment requirements, or when documentation drift is detected. <example> Context: The user has just added a new main entry point or modified the CLI interface. user: "I've updated the main CLI to add new flags for processing PDFs" assistant: "I'll use the readme-maintainer agent to update the README with the new CLI flags and usage examples" <commentary> Since the CLI interface has changed, use the readme-maintainer agent to ensure the README accurately reflects the new entry points and usage patterns. </commentary> </example> <example> Context: New environment variables have been added to the project. user: "Added KRAC_CACHE_TTL and KRAC_MAX_RETRIES environment variables" assistant: "Let me invoke the readme-maintainer agent to document these new environment variables in the README" <commentary> New environment variables need to be documented, so the readme-maintainer agent should update the environment variables section. </commentary> </example> <example> Context: The installation process has changed. user: "We now require Azure Document Intelligence SDK as a dependency" assistant: "I'll use the readme-maintainer agent to update the installation instructions and requirements" <commentary> Dependency changes affect installation, so the readme-maintainer agent needs to update both the requirements and installation sections. </commentary> </example>

Use this agent when you need to analyze, create, update, or maintain comprehensive test coverage for your codebase. This includes writing unit tests, integration tests, end-to-end tests, property-based tests, and ensuring test quality aligns with VibeCoding standards. The agent should be invoked periodically for test audits, when new features are added, or when test coverage needs improvement. Examples: <example>Context: User wants to ensure their codebase has comprehensive test coverage after implementing new features. user: "We just finished implementing the new claim validation module. Can you review and update our test coverage?" assistant: "I'll use the test-coverage-engineer agent to analyze the new module and ensure we have comprehensive test coverage." <commentary>Since the user needs test coverage analysis and updates after implementing new features, use the test-coverage-engineer agent to review and enhance the test suite.</commentary></example> <example>Context: Periodic test quality audit. user: "It's been a month since our last test review. Time to check our test coverage again." assistant: "I'll launch the test-coverage-engineer agent to perform a comprehensive test audit and update our test suite as needed." <commentary>For periodic test audits, use the test-coverage-engineer agent to maintain high-quality test coverage.</commentary></example> <example>Context: Test coverage has dropped below threshold. user: "Our CI is failing because test coverage dropped to 85% on the critical paths." assistant: "Let me use the test-coverage-engineer agent to identify gaps and write the necessary tests to bring coverage back above 90%." <commentary>When test coverage drops below requirements, use the test-coverage-engineer agent to identify and fill coverage gaps.</commentary></example>

Use this agent when you need to systematically improve test coverage in a codebase by adding both doctests and separate test files. This agent should be invoked after writing new code, during code review phases, or when explicitly asked to improve test coverage for existing code. Examples: <example> Context: The user has just written a new utility function and wants to ensure it has proper test coverage. user: "I've added a new string manipulation function to utils.py" assistant: "I'll use the test-coverage-improver agent to add appropriate tests for your new function" <commentary> Since new code was written, use the Task tool to launch the test-coverage-improver agent to add comprehensive tests. </commentary> </example> <example> Context: The user is reviewing their codebase and notices low test coverage. user: "Can you add tests for the data processing module?" assistant: "I'll use the test-coverage-improver agent to systematically add tests to the data processing module" <commentary> The user explicitly requested tests, so use the test-coverage-improver agent to analyze and add appropriate tests. </commentary> </example> <example> Context: After implementing a complex feature, the user wants comprehensive testing. user: "I've finished implementing the payment processing system" assistant: "Let me use the test-coverage-improver agent to ensure your payment processing system has thorough test coverage" <commentary> Complex functionality was added, trigger the test-coverage-improver agent to add both doctests and separate test files as appropriate. </commentary> </example>

Use this agent when you need to create, update, or maintain comprehensive GitHub Wiki documentation for a project. This includes initial wiki setup with all essential pages, updating existing documentation to reflect code changes, creating project-specific documentation pages, and ensuring documentation stays synchronized with the codebase. Examples: <example>Context: User wants to create comprehensive wiki documentation for their medical coding library project. user: 'I need complete wiki documentation for my HANK_CODESETS project' assistant: 'I'll use the wiki-documentation-architect agent to create comprehensive GitHub Wiki documentation for your project' <commentary>Since the user needs wiki documentation created, use the Task tool to launch the wiki-documentation-architect agent to analyze the project and create appropriate wiki pages.</commentary></example> <example>Context: User has made significant changes to their API and needs documentation updated. user: 'We've added new endpoints and changed authentication - update the wiki' assistant: 'Let me use the wiki-documentation-architect agent to update your wiki documentation to reflect these API changes' <commentary>The user needs wiki updates for API changes, so use the wiki-documentation-architect agent to synchronize documentation with the new code.</commentary></example> <example>Context: User is setting up a new open source project and wants professional documentation. user: 'Set up wiki documentation for my new Python package' assistant: 'I'll invoke the wiki-documentation-architect agent to create a complete wiki structure for your Python package' <commentary>New project needs wiki setup, use the wiki-documentation-architect agent to create the standard documentation structure.</commentary></example>

Use when CLAUDE.md feels bloated or too long, when starting a new project, or when optimizing documentation for token efficiency. Audits content quality, extracts reference material to sub-docs, and enforces a token budget.

Use after implementing a feature, fixing a bug, or completing any non-trivial code change. Recursive multi-lens review that continues until all selected lenses pass clean.

Use when a branch has code changes that may have made documentation stale, after completing a feature, or before creating a PR. Diffs branch against base and maps changes to affected docs.

Use when starting any significant feature or non-trivial task that deserves a thorough development cycle. Triggers on "jack it up", "do this right", "full cycle", "build this properly", or when the user wants quality-first development over speed.

Use when the user mentions a past project like "configurator", asks to continue/resume previous work, says "how did I do X before", references past sessions, or starts work on a feature that may have been done before. Searches and loads context from past Claude Code sessions.

Use when testing UI changes for visual correctness, interactions, console errors, and edge cases. Performs browser-based QA and returns a detailed issue list for planning fixes.

Use when approaching non-trivial planning — architectural decisions, major features, system design, or any decision with multiple viable approaches.

Use when UI changes span multiple components or pages, layout or navigation changed, a new user-facing feature was added, or comprehensive UX validation is needed. For single-component or bug-fix checks, use the qa skill instead.

Use when the user asks "what should I work on", "what's next", "what are our priorities", "help me prioritize", "what should we build next", "I'm not sure what to do next", or "where should I start". Analyzes plans, issues, commits, and lifecycle stage to recommend highest-yield next work items.