By troykelly
Opinionated GitHub-native development workflow with 51 skills for autonomous, issue-driven software development. Enforces TDD, strict typing, IPv6-first networking, comprehensive code review, local service testing, and continuous issue tracking. Features GitHub-based state management (no local state files), documentation enforcement gates, autonomous orchestration with parallel workers, and PostgreSQL 18/PostGIS/TimescaleDB database skills.
npx claudepluginhub troykelly/claude-skills --plugin issue-driven-developmentExecutes bash commands
Hook triggers when Bash tool is used
Modifies files
Hook triggers on file write and edit operations
Share bugs, ideas, or general feedback.
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>
You are an expert code simplification specialist focused on enhancing code clarity, consistency, and maintainability while preserving exact functionality. Your expertise lies in applying project-specific best practices to simplify and improve code without altering its behavior. You prioritize readable, explicit code over overly compact solutions. This is a balance that you have mastered as a result your years as an expert software engineer.
Use this agent when you need to analyze code comments for accuracy, completeness, and long-term maintainability. This includes: (1) After generating large documentation comments or docstrings, (2) Before finalizing a pull request that adds or modifies comments, (3) When reviewing existing comments for potential technical debt or comment rot, (4) When you need to verify that comments accurately reflect the code they describe. <example> Context: The user is working on a pull request that adds several documentation comments to functions. user: "I've added documentation to these functions. Can you check if the comments are accurate?" assistant: "I'll use the comment-analyzer agent to thoroughly review all the comments in this pull request for accuracy and completeness." <commentary> Since the user has added documentation comments and wants them checked, use the comment-analyzer agent to verify their accuracy against the actual code. </commentary> </example> <example> Context: The user just asked to generate comprehensive documentation for a complex function. user: "Add detailed documentation for this authentication handler function" assistant: "I've added the documentation. Now let me use the comment-analyzer agent to verify that the comments are accurate and helpful for long-term maintenance." <commentary> After generating large documentation comments, proactively use the comment-analyzer to ensure quality. </commentary> </example> <example> Context: The user is preparing to create a pull request with multiple code changes and comments. user: "I think we're ready to create the PR now" assistant: "Before creating the pull request, let me use the comment-analyzer agent to review all the comments we've added or modified to ensure they're accurate and won't create technical debt." <commentary> Before finalizing a PR, use the comment-analyzer to review all comment changes. </commentary> </example>
Designs feature architectures by analyzing existing codebase patterns and conventions, then providing comprehensive implementation blueprints with specific files to create/modify, component designs, data flows, and build sequences
Deeply analyzes existing codebase features by tracing execution paths, mapping architecture layers, understanding patterns and abstractions, and documenting dependencies to inform new development
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.
Use before any code changes - hard gate ensuring work never happens on main branch, with proper feature branch creation from correct base
Use after creating PR - monitor CI pipeline, resolve failures, address review feedback, and merge when all gates pass
Use when committing code - ensures atomic, descriptive commits that leave the codebase in a merge-ready state at every point
Use after implementing features - 7-criteria code review with MANDATORY artifact posting to GitHub issue; blocks PR creation until complete
Use when encountering merge conflicts - handle conflicts cleanly, verify resolution, and maintain code integrity
MANDATORY when designing schemas, writing migrations, creating indexes, or making architectural database decisions - enforces PostgreSQL 18 best practices including AIO, UUIDv7, temporal constraints, and modern indexing strategies
Use when a review finding cannot be fixed in current PR - creates properly documented tracking issue with full context, linked to parent, following full issue-driven-development process
Use when documentation drift is detected. Comprehensively audits codebase and creates/updates Swagger, features docs, and general documentation to achieve full sync.
Use for development environment setup - create and maintain init scripts, run smoke tests, ensure consistent environment across sessions
Use for LARGE work requiring feature-level grouping. Creates epic tracking issues, manages related issues under a common label, tracks epic progress, and coordinates with milestones.
Use when encountering failures - assess severity, preserve evidence, execute rollback decision tree, and verify post-recovery state
Use when user-facing features change. Ensures features documentation is updated. Pauses work if documentation has drifted, triggering documentation-audit skill.
Use when receiving UAT feedback, bug reports, user testing results, stakeholder feedback, QA findings, or any batch of issues to investigate. Investigates each item BEFORE creating issues, classifies by type and priority, creates well-formed GitHub issues with proper project board integration.
MANDATORY before any GitHub project operations - caches project metadata to prevent rate limit exhaustion. Called by session-start. Other skills MUST use cached data.
Use when writing code, documentation, or comments - always use accessible and respectful terminology
Use for MASSIVE work requests requiring multi-epic planning. Creates research spikes, documents all unknowns and decisions, builds resumable architecture documents, and structures work into epics and milestones.
Use when writing code - ensure complete JSDoc, docstrings, and inline comments assuming documentation will be generated from code
IPv6 is THE first-class citizen. All code, tests, documentation, and configurations MUST be IPv6-first. IPv4 MAY be added only for legacy support as a second-class citizen.
Use when an issue is too large for a single task - breaks into linked sub-issues with full documentation, ensuring manageable work units
Use for any development work - the master 13-step coding process that orchestrates all other skills, ensuring GitHub issue tracking, proper branching, TDD, code review, and CI verification
Use throughout all work - ensures GitHub issues are updated continuously as work happens, not batched at the end
Use before starting ANY work - hard gate ensuring a GitHub issue exists, creating one if needed through user questioning
Use when code changes touch database, cache, queue, or other service-dependent components - enforces testing against real local services instead of mocks
Use to maintain context across sessions - integrates episodic-memory for conversation recall and mcp__memory knowledge graph for persistent facts
Use for time-based grouping of issues into delivery phases. Creates, updates, and tracks milestones, associates issues and epics, monitors progress toward milestone completion.
Use during all development - no TODOs, no FIXMEs, no "we'll add this later"; do it now or get explicit deferral permission
Source royalty-free images and videos from Pexels API for design, placeholders, or content. Supports search, curated/popular content, collections, multiple resolutions, and ALWAYS creates detailed sidecar metadata files.
MANDATORY when working with geographic data, spatial queries, geometry operations, or location-based features - enforces PostGIS 3.6.1 best practices including ST_CoverageClean, SFCGAL 3D functions, and bigint topology
MANDATORY when touching auth tables, tenant isolation, RLS policies, or multi-tenant database code - enforces Row Level Security best practices and catches common bypass vulnerabilities
Use after completing implementation - create pull request with complete documentation, proper labels, linked issues, and verification summary
Use before starting implementation - research repository documentation, codebase patterns, and external resources to inform the approach
MANDATORY for all work - the project board is THE source of truth. This skill provides verification functions and gates that other skills MUST call. No work proceeds without project board compliance.
Use to keep GitHub Project fields synchronized with actual work state - updates status, verification, criteria counts, and other project-specific fields
Use after 2 consecutive failed attempts at solving a problem - STOP guessing and research documentation, codebase, and online resources before resuming
HARD GATE before PR creation - verifies review artifact exists in issue comments, all findings addressed or tracked, blocks PR creation if requirements not met
Use before code review - determine if change is minor (review new code only) or major (review impacted code too)
MANDATORY for security-sensitive code changes - OWASP-based security review with dedicated checklist, required before PR for auth, input handling, API, database, or credential code
Use at the beginning of every work session - establishes context by checking GitHub project state, reading memory, verifying environment, and orienting before starting work
Use when writing code in typed languages - enforces full typing with no any/unknown/untyped escapes, even if it requires extra time
Use when writing code - follow Google style guides where available, otherwise follow established best practices for the language
Use when implementing features or fixes - test-driven development with RED-GREEN-REFACTOR cycle and full code coverage requirement
MANDATORY when working with time-series data, hypertables, continuous aggregates, or compression - enforces TimescaleDB 2.24.0 best practices including lightning-fast recompression, UUIDv7 continuous aggregates, and Direct Compress
Use before merging PR - final gate ensuring all tests pass, review complete, CI green, and acceptance criteria verified
Entry point for ALL work requests - triages scope from trivial to massive, asks clarifying questions, and routes to appropriate planning skills. Use this when receiving any new work request.
Use to spawn isolated worker processes for autonomous issue work. Uses Task tool with run_in_background for parallel execution and TaskOutput for monitoring. Pre-extracts context to minimize worker token usage.
Defines context handover format when workers hit turn limit. Posts structured handover to GitHub issue comments enabling replacement workers to continue seamlessly.
Defines behavior protocol for spawned worker agents. Injected into worker prompts. Covers startup, progress reporting, exit conditions, and handover preparation.
This skill should be used when the user asks to "create an agent", "add an agent", "write a subagent", "agent frontmatter", "when to use description", "agent examples", "agent tools", "agent colors", "autonomous agent", or needs guidance on agent structure, system prompts, triggering conditions, or agent development best practices for Claude Code plugins.
Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, or applications. Generates creative, polished code that avoids generic AI aesthetics.
This skill should be used when the user asks to "create a hook", "add a PreToolUse/PostToolUse/Stop hook", "validate tool use", "implement prompt-based hooks", "use ${CLAUDE_PLUGIN_ROOT}", "set up event-driven automation", "block dangerous commands", or mentions hook events (PreToolUse, PostToolUse, Stop, SubagentStop, SessionStart, SessionEnd, UserPromptSubmit, PreCompact, Notification). Provides comprehensive guidance for creating and implementing Claude Code plugin hooks with focus on advanced prompt-based hooks API.
Analyze and resolve Sentry comments on GitHub Pull Requests. Use this when asked to review or fix issues identified by Sentry in PR comments. Can review specific PRs by number or automatically find recent PRs with Sentry feedback.
Setup Sentry AI Agent Monitoring in any project. Use this when asked to add AI monitoring, track LLM calls, monitor AI agents, or instrument OpenAI/Anthropic/Vercel AI/LangChain/Google GenAI. Automatically detects installed AI SDKs and configures the appropriate Sentry integration.
Setup Sentry Logging in any project. Use this when asked to add Sentry logs, enable structured logging, setup console log capture, or integrate logging with Sentry. Supports JavaScript, TypeScript, Python, Ruby, React, Next.js, and other frameworks.
Setup Sentry Metrics in any project. Use this when asked to add Sentry metrics, track custom metrics, setup counters/gauges/distributions, or instrument application performance metrics. Supports JavaScript, TypeScript, Python, React, Next.js, and Node.js.
Setup Sentry Tracing (Performance Monitoring) in any project. Use this when asked to add performance monitoring, enable tracing, track transactions/spans, or instrument application performance. Supports JavaScript, TypeScript, Python, Ruby, React, Next.js, and Node.js.
This skill should be used when the user wants to "create a skill", "add a skill to plugin", "write a new skill", "improve skill description", "organize skill content", or needs guidance on skill structure, progressive disclosure, or skill development best practices for Claude Code plugins.
Structured agentic development methodology - from issue analysis to merge
End-to-end development workflow: design → draft-plan → orchestrate → review → pr-create → pr-review → pr-merge
AI-powered development workflow with planning, implementation, and review commands
Virtual development team: TDD, debugging, code review, backlog management, and proven workflow patterns
GitHub issue triage, creation, and management
Requires secrets
Needs API keys or credentials to function
Requires secrets
Needs API keys or credentials to function
Uses power tools
Uses Bash, Write, or Edit tools
Uses power tools
Uses Bash, Write, or Edit tools
Has parse errors
Some configuration could not be fully parsed
Has parse errors
Some configuration could not be fully parsed
Share bugs, ideas, or general feedback.