issue-driven-development

MUST BE USED after implementing code changes. Performs comprehensive 7-criteria code review and posts mandatory review artifact to GitHub issue. Invoke proactively before any PR creation.

PROACTIVELY review security-sensitive code. MANDATORY for changes to auth, input handling, API endpoints, database queries, or credential handling. Read-only analysis with OWASP checklist.

Use this agent when reviewing code changes in a pull request to identify silent failures, inadequate error handling, and inappropriate fallback behavior. This agent should be invoked proactively after completing a logical chunk of work that involves error handling, catch blocks, fallback logic, or any code that could potentially suppress errors. Examples: <example> Context: Daisy has just finished implementing a new feature that fetches data from an API with fallback behavior. Daisy: "I've added error handling to the API client. Can you review it?" Assistant: "Let me use the silent-failure-hunter agent to thoroughly examine the error handling in your changes." <Task tool invocation to launch silent-failure-hunter agent> </example> <example> Context: Daisy has created a PR with changes that include try-catch blocks. Daisy: "Please review PR #1234" Assistant: "I'll use the silent-failure-hunter agent to check for any silent failures or inadequate error handling in this PR." <Task tool invocation to launch silent-failure-hunter agent> </example> <example> Context: Daisy has just refactored error handling code. Daisy: "I've updated the error handling in the authentication module" Assistant: "Let me proactively use the silent-failure-hunter agent to ensure the error handling changes don't introduce silent failures." <Task tool invocation to launch silent-failure-hunter agent> </example>

Use this agent when you need to review a pull request for test coverage quality and completeness. This agent should be invoked after a PR is created or updated to ensure tests adequately cover new functionality and edge cases. Examples: <example> Context: Daisy has just created a pull request with new functionality. user: "I've created the PR. Can you check if the tests are thorough?" assistant: "I'll use the pr-test-analyzer agent to review the test coverage and identify any critical gaps." <commentary> Since Daisy is asking about test thoroughness in a PR, use the Task tool to launch the pr-test-analyzer agent. </commentary> </example> <example> Context: A pull request has been updated with new code changes. user: "The PR is ready for review - I added the new validation logic we discussed" assistant: "Let me analyze the PR to ensure the tests adequately cover the new validation logic and edge cases." <commentary> The PR has new functionality that needs test coverage analysis, so use the pr-test-analyzer agent. </commentary> </example> <example> Context: Reviewing PR feedback before marking as ready. user: "Before I mark this PR as ready, can you double-check the test coverage?" assistant: "I'll use the pr-test-analyzer agent to thoroughly review the test coverage and identify any critical gaps before you mark it ready." <commentary> Daisy wants a final test coverage check before marking PR ready, use the pr-test-analyzer agent. </commentary> </example>

Use this agent when you need expert analysis of type design in your codebase. Specifically use it: (1) when introducing a new type to ensure it follows best practices for encapsulation and invariant expression, (2) during pull request creation to review all types being added, (3) when refactoring existing types to improve their design quality. The agent will provide both qualitative feedback and quantitative ratings on encapsulation, invariant expression, usefulness, and enforcement. <example> Context: Daisy is writing code that introduces a new UserAccount type and wants to ensure it has well-designed invariants. user: "I've just created a new UserAccount type that handles user authentication and permissions" assistant: "I'll use the type-design-analyzer agent to review the UserAccount type design" <commentary> Since a new type is being introduced, use the type-design-analyzer to ensure it has strong invariants and proper encapsulation. </commentary> </example> <example> Context: Daisy is creating a pull request and wants to review all newly added types. user: "I'm about to create a PR with several new data model types" assistant: "Let me use the type-design-analyzer agent to review all the types being added in this PR" <commentary> During PR creation with new types, use the type-design-analyzer to review their design quality. </commentary> </example>

Use after implementing features - verifies each acceptance criterion with structured testing and posts verification reports to the GitHub issue

Use when API code changes (routes, endpoints, schemas). Enforces Swagger/OpenAPI sync. Pauses work if documentation has drifted, triggering documentation-audit skill.

Use after code review - implement ALL findings; any finding not fixed MUST have tracking issue created; no finding disappears without trace

Use when starting any work session - establishes autonomous operation mode, overriding token limits and time pressure to work until goal is achieved

Use when user requests autonomous operation across multiple issues. Orchestrates parallel workers using Task tool, monitors with TaskOutput, handles SLEEP/WAKE cycles, and works until scope is complete without user intervention.

16 hooks across 4 events