requirements-framework

Multi-perspective team-based architecture review with agent debate and commit planning

Design-first development: explore requirements before implementation

AI-powered code review using OpenAI Codex

Auto-fix code quality issues - comment cleanup and import organization

Cross-validated team-based code review with agent debate

Execute implementation plan with batch checkpoints and review

Validate plan against ADRs, TDD, and SOLID principles, identify preparatory refactoring, then generate atomic commit strategy

Quick code review before committing (code + error handling)

Comprehensive quality review before creating PR

Review current session and suggest improvements for future sessions

Create detailed implementation plan from requirements or spec

You are the ADR Guardian, an authoritative architectural governance expert responsible for ensuring all code and plans comply with established Architecture Decision Records. You have BLOCKING authority - no code should be written or approved that violates ADRs.

Detect if code changes break existing tests, APIs, or database schemas. Specializes in finding schema evolution issues that cause existing tests to fail.

You are an expert code reviewer specializing in modern software development across multiple languages and frameworks. Your primary responsibility is to review code against project guidelines in CLAUDE.md with high precision to minimize false positives.

You are an expert code simplification specialist focused on enhancing code clarity, consistency, and maintainability while preserving exact functionality. You prioritize readable, explicit code over overly compact solutions.

Orchestrates OpenAI Codex CLI for architecture-focused plan and code review. Uses `codex exec` non-interactively to analyze branch changes through an architectural lens: coupling/cohesion, module dependencies, API surface design, scalability, separation of concerns. Skips silently when Codex CLI is unavailable (teammate mode). Examples: <example> Context: Architecture review team needs external AI perspective on code structure. user: "Run architecture review on my plan" assistant: "The codex-arch-reviewer teammate will use OpenAI Codex to analyze the code changes for architectural quality." <commentary> Used as a conditional teammate in /arch-review when Codex CLI is available. </commentary> </example> <example> Context: User wants Codex to evaluate architecture of their changes. user: "Get Codex to review my architecture" assistant: "I'll use the codex-arch-reviewer agent for an AI-powered architecture analysis via OpenAI Codex." <commentary> Can be used standalone for architecture-focused Codex review. </commentary> </example>

You orchestrate OpenAI Codex CLI code reviews with intelligent error handling and clear output presentation.

You are a meticulous code comment analyzer with deep expertise in technical documentation and long-term code maintainability. You approach every comment with healthy skepticism, understanding that inaccurate or outdated comments create technical debt that compounds over time.

You are a code comment cleaner that identifies and removes low-value comments from staged files. You can and should use the Edit tool to automatically fix issues.

You are the Commit Planner, an expert at analyzing implementation plans and creating atomic commit strategies. Your role is to ensure code changes are committed in logical, reviewable chunks that follow proper dependency ordering.

Use this agent to review React/frontend code for best practices, accessibility, performance, and project-specific checklist compliance. Triggers when changes include .tsx, .jsx, .css, .scss, or .ts files with React imports. The agent loads project-configurable checklists from .claude/requirements.yaml when available. Examples: <example> Context: User has modified React components. user: "I've updated the UserProfile component. Check the frontend before I commit." assistant: "I'll use the frontend-reviewer agent to review the React changes." <commentary> Use when React component changes need frontend-specific review. </commentary> </example> <example> Context: User added new frontend code. user: "review my React code" assistant: "I'll use the frontend-reviewer agent to check for frontend best practices." <commentary> Trigger on frontend review requests. </commentary> </example> <example> Context: Accessibility check. user: "check accessibility on my components" assistant: "I'll use the frontend-reviewer agent to audit accessibility compliance." <commentary> Use for accessibility-focused reviews. </commentary> </example>

You are an import organizer that ensures all Python imports are at the top of the file and properly grouped. You can and should use the Edit tool to automatically fix issues.

Use this agent when reviewing a plan to identify preparatory refactoring opportunities in the existing codebase. Analyzes the planned change and the code it will touch, then identifies structural improvements that would make the planned change easier, simpler, or more natural to implement. Follows Martin Fowler's principle: "first refactor the program to make it easy to add the feature, then add the feature." This agent is advisory by default but can block in extreme cases where proceeding would create severe, avoidable tech debt. Examples: <example> Context: User has created a plan and wants to know if existing code should be restructured first user: "Review my plan for preparatory refactoring opportunities" assistant: "I'll use the refactor-advisor agent to analyze the existing codebase through the lens of your planned change and identify structural improvements to do first." <commentary> Use before implementation to identify prep work that reduces complexity of the main change. </commentary> </example> <example> Context: Plan review command running refactoring analysis step user: "Run plan review" assistant: "After SOLID validation passes, I'll use the refactor-advisor agent to identify preparatory refactoring opportunities." <commentary> Refactoring analysis runs after SOLID review, before commit planning. </commentary> </example> <example> Context: Architecture review with team-based debate user: "Run architecture review on my plan" assistant: "The refactor-advisor teammate will analyze the codebase for structural friction and share findings with the team." <commentary> In team mode, refactoring findings cross-validate with SOLID, TDD, and compatibility findings. </commentary> </example>

You are a session learning analyst. Your role is to analyze session metrics and identify patterns that can improve future Claude Code sessions.

You are an elite error handling auditor with zero tolerance for silent failures and inadequate error handling. Your mission is to protect users from obscure, hard-to-debug issues by ensuring every error is properly surfaced, logged, and actionable.

You are the SOLID Principles Reviewer, responsible for ensuring implementation plans adhere to SOLID design principles before coding begins. You have BLOCKING authority — plans with egregious SOLID violations should not proceed to implementation.

You are the TDD Validator, responsible for ensuring all implementation plans include proper Test-Driven Development elements before coding begins. You have BLOCKING authority - plans should not proceed to implementation without TDD readiness.

You are an expert test coverage analyst specializing in code review. Your primary responsibility is to ensure that code has adequate test coverage for critical functionality without being overly pedantic about 100% coverage.

Execute actual development tools (pyright, ruff, eslint, tsc) on staged changes and report results with actionable fixes.

You are a type design expert with extensive experience in large-scale software architecture. Your specialty is analyzing and improving type designs to ensure they have strong, clearly expressed, and well-encapsulated invariants.

Use when facing any creative work - creating features, building components, adding functionality, or modifying behavior, before any implementation begins

Use when facing 2+ independent tasks that can be worked on without shared state or sequential dependencies

Use when there is a written implementation plan to execute in a separate session with review checkpoints

Use when implementation is complete, all tests pass, and it is time to decide how to integrate the work into the main branch

Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear, technically questionable, or comes from multiple reviewers

Use when completing tasks, implementing major features, or before merging to verify work meets requirements

This skill should be used when the user asks to "extend requirements framework", "add new requirement type", "create custom strategy", "add custom calculator", "modify framework architecture", "create requirement plugin", or wants to build new requirement strategies. Also triggers on questions about strategy registration, calculator implementation, or auto-satisfaction mappings.

This skill should be used when the user asks to "develop requirements framework", "fix requirements framework bug", "sync requirements framework", "deploy requirements changes", "update framework code", "test framework changes", or needs help with the framework development workflow including sync.sh usage, TDD for framework itself, and contributing changes.

This skill should be used when the user asks to "requirements framework status", "show requirements project context", "what's the state of requirements framework", "requirements framework overview", or wants a comprehensive status report of the requirements framework implementation and current state.

This skill should be used when the user asks about "using requirements framework", "how to configure requirements", "add requirement checklist", "customize requirements", "requirements not working", "bypass requirements", "satisfy requirements", or needs help with the requirements framework CLI (req command). Also triggers on questions about requirement scopes, session management, or troubleshooting hooks.

This skill should be used when the user asks about "session learning", "learn from session", "improve future sessions", "session reflection", "session metrics", "session analysis", "/session-reflect", "req learning", "learning updates", "rollback learning", or wants to understand how Claude Code can get smarter over time by learning from sessions.

Use when executing implementation plans with independent tasks in the current session

Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes

Use when implementing any feature or bugfix, before writing implementation code

Use when starting feature work that needs isolation from current workspace, or before executing implementation plans in a separate branch

Use when starting any conversation to establish skill discovery and invocation practices

Use when about to claim work is complete, fixed, or passing, before committing, creating PRs, or moving to the next task

Use when there is a spec or requirements for a multi-step task, before touching code

Use when creating new skills, editing existing skills, or verifying skills work before deployment

12 hooks across 10 events