speckit-generator

Initialize .claude/ foundation and speckit/ directory with git validation, tech stack detection, memory files, and project commands

Use this agent when validating Architecture Decision Records (ADRs) for completeness and compliance with MADR template requirements. <example> Context: User just completed /plan command which generated ADRs user: "[Plan generation complete with 4 ADRs]" assistant: "The plan is complete. I'll validate the ADRs to ensure they meet the required standards." <commentary> Proactive validation after plan generation to catch incomplete ADRs early. </commentary> </example> <example> Context: User wants to verify architecture decisions are properly documented user: "Validate the architecture decisions in my plan file" assistant: "I'll use the adr-validator agent to check all ADRs against MADR template requirements." <commentary> Explicit request to validate ADR documentation quality. </commentary> </example> <example> Context: Plan file exists with ADRs that may be incomplete user: "Check if the ADRs in speckit/plan.md are ready for implementation" assistant: "I'll validate the ADRs to ensure they have all required fields for their designated levels." <commentary> Pre-implementation validation to ensure ADRs are complete before task execution. </commentary> </example>

Use this agent when scanning specifications for unclear, vague, or conflicting requirements. Detects ambiguities across 13 SEAMS taxonomy categories and prioritizes by impact. <example> Context: User just completed /analyze and has a spec document user: "The spec is ready, can you check if anything is unclear?" assistant: "I'll scan the specification for ambiguities." <commentary> After analysis phase, proactively scan for specification gaps before moving to implementation. </commentary> </example> <example> Context: User has a requirements document that needs review user: "Find all the unclear requirements in this spec" assistant: "I'll use the ambiguity scanner to identify vague or conflicting requirements." <commentary> Explicit request to find unclear requirements triggers the scanner. </commentary> </example> <example> Context: Spec document exists but has quality concerns user: "This spec feels incomplete, what's missing?" assistant: "I'll scan for specification gaps and prioritize what needs clarification." <commentary> When spec clarity is questioned, scan across all 13 categories to find gaps. </commentary> </example>

Use this agent to scan code for anti-patterns before code review or after implementation. Detects common mistakes that indicate inexperience and provides remediation guidance. <example> Context: User completed implementing a feature user: "I've finished the user authentication module" assistant: "Let me scan for anti-patterns in the implementation." <commentary> Proactive trigger: After significant implementation work, check for common mistakes </commentary> </example> <example> Context: User wants to review code quality user: "Check this code for anti-patterns" assistant: "I'll scan your code against known anti-patterns for your tech stack." <commentary> Explicit trigger: User directly asks to check for anti-patterns </commentary> </example> <example> Context: PR review or code review request user: "Review my PR for issues" assistant: "Let me run anti-pattern detection to identify common code smells." <commentary> Context trigger: Code review requests should include anti-pattern scanning </commentary> </example>

Use this agent when validating code and artifacts against directive rules from constitution.md and technology-specific memory files. Triggers when checking compliance with MUST/MUST NOT rules, verifying implementation against project requirements, or ensuring artifacts follow security and testing directives. <example> Context: User just completed an implementation task with /implement user: "Check if my implementation complies with the project requirements" assistant: "I'll use the compliance-checker agent to validate your implementation against the project directives." <commentary> Proactive triggering after implementation to verify compliance with spec and project rules. </commentary> </example> <example> Context: User wants to verify code follows security requirements user: "Does my auth code follow the security rules in constitution.md?" assistant: "I'll run the compliance-checker agent to validate your auth code against the security directives." <commentary> Explicit request to verify implementation against specific directive files. </commentary> </example> <example> Context: Pre-merge review needs compliance verification user: "Before merging, make sure this follows all our MUST rules" assistant: "I'll use the compliance-checker agent to scan for any MUST/MUST NOT violations before merge." <commentary> Critical compliance gate check before code integration. </commentary> </example>

Use this agent when mapping requirements to implementation coverage, checking traceability between specs and tasks, or identifying orphan requirements and tasks. <example> Context: User just ran /tasks and wants to verify all requirements are covered user: "Check that all requirements from the spec have corresponding tasks" assistant: "I'll use the coverage-mapper agent to analyze traceability between your spec and tasks." <commentary> After task generation, coverage mapping ensures no requirements were missed. </commentary> </example> <example> Context: User is reviewing the implementation plan user: "Are there any orphan tasks that don't trace back to requirements?" assistant: "I'll use the coverage-mapper agent to identify any tasks without requirement traceability." <commentary> Explicit request to check requirements traceability and find orphan items. </commentary> </example> <example> Context: User wants to verify spec coverage before starting implementation user: "Show me which spec sections don't have any planned tasks yet" assistant: "I'll use the coverage-mapper agent to build a traceability matrix and identify uncovered spec sections." <commentary> Proactive coverage analysis to find gaps before implementation begins. </commentary> </example>

Use this agent when generating implementation designs for projects without a specific language designer, for cross-cutting concerns that span multiple technologies, or for generic algorithm and data structure design. <example> Context: User runs /design command but project uses Go, which has no specific designer user: "/design TASK-007 HierarchicalChunker" assistant: "I'll use the design-agent to create a language-agnostic implementation design for the HierarchicalChunker task." <commentary> No Go-specific designer exists, so the generic design-agent handles the request as the fallback. </commentary> </example> <example> Context: User needs algorithm design independent of implementation language user: "Design the chunking algorithm with overlap handling - we need the logic figured out before deciding on the language" assistant: "I'll use the design-agent to create a detailed algorithm design with pseudo-code that can be implemented in any language." <commentary> User explicitly wants language-agnostic design for algorithm specification before implementation decisions. </commentary> </example> <example> Context: Project uses multiple languages (Python backend, TypeScript frontend, Rust CLI) user: "/design TASK-012 SharedDataModels - these models need to work across all three services" assistant: "I'll use the design-agent since this task spans multiple languages and needs a technology-neutral approach." <commentary> Cross-cutting concern spanning multiple tech stacks benefits from generic design patterns rather than language-specific ones. </commentary> </example>

You are a Python implementation design specialist who transforms task descriptions into production-ready Python designs with Pydantic models, typed interfaces, comprehensive pytest tests, and idiomatic patterns.

Use this agent when generating implementation designs for React or Next.js projects. Triggers during /design command when project contains next.config.js, React imports, or JSX/TSX files. Creates component architectures with props interfaces, hooks, Server/Client Component patterns, and React Testing Library tests. <example> Context: User runs /design in a Next.js project (next.config.js detected) user: "/design TASK-012 ChunkViewer component" assistant: "I'll generate a React implementation design for the ChunkViewer component." <commentary> Project uses Next.js App Router. Agent triggers proactively for /design to create component hierarchy with Server/Client Component decisions, props interfaces, and accessibility patterns. </commentary> </example> <example> Context: User explicitly requests React component design with hooks user: "Design a search component with debounced input, URL sync, and keyboard navigation" assistant: "I'll use the react-designer agent to create a detailed implementation design with custom hooks and accessibility." <commentary> User explicitly wants React patterns (hooks, component design). Agent creates custom hooks for debounce/URL sync, keyboard navigation handlers, and comprehensive test cases. </commentary> </example> <example> Context: Working on frontend codebase with existing .tsx files and shadcn/ui user: "I need to add a data table with sorting, filtering, and pagination" assistant: "I'll design the DataTable component using React patterns from your existing codebase." <commentary> Context shows TSX files and shadcn/ui usage. Agent analyzes existing patterns and generates compatible component architecture with proper Tailwind styling and accessibility. </commentary> </example>

Use this agent when generating Rust implementation designs with ownership patterns, trait definitions, error handling, and comprehensive tests. <example> Context: User runs /design in a project containing Cargo.toml and .rs files user: "/design" assistant: "I'll analyze your Rust project structure to generate an implementation design." <commentary> Proactive triggering: Detected Rust project via Cargo.toml, automatically selects rust-designer for idiomatic Rust patterns. </commentary> assistant: "I'll use the rust-designer agent to create a detailed implementation design with ownership semantics and trait-based abstractions." </example> <example> Context: User explicitly requests Rust design with specific patterns user: "Design the caching module with proper ownership and lifetimes" assistant: "I'll create a design that handles ownership correctly for the caching layer." <commentary> Explicit triggering: User mentions ownership/lifetimes which are Rust-specific concepts requiring specialized design patterns. </commentary> assistant: "I'll use the rust-designer agent to design the caching module with proper lifetime annotations and ownership transfers." </example> <example> Context: Working on systems code with traits and generics user: "I need to design a plugin system where plugins implement a common trait" assistant: "I'll design a trait-based plugin architecture for your Rust project." <commentary> Context-based triggering: Trait-based design is idiomatic Rust, requiring specialized knowledge of associated types, trait bounds, and object safety. </commentary> assistant: "I'll use the rust-designer agent to design the plugin trait with appropriate bounds and dynamic dispatch considerations." </example>

Use this agent when validating task acceptance criteria against SMART framework (Specific, Measurable, Achievable, Relevant, Time-bound). Ensures all criteria are verifiable before implementation begins. <example> Context: User just ran /tasks command and tasks file was generated user: "Generate tasks for this plan" assistant: "I've generated the tasks file. Let me validate the acceptance criteria meet SMART standards." <commentary> Proactive trigger: After task generation, automatically validate criteria quality </commentary> </example> <example> Context: User wants to verify task quality before implementation user: "Check if my task acceptance criteria are testable" assistant: "I'll validate your tasks against SMART criteria to ensure they're verifiable." <commentary> Explicit trigger: User directly asks to check acceptance criteria </commentary> </example> <example> Context: Tasks file exists but criteria may be vague user: "Are these tasks ready for implementation?" assistant: "Let me run SMART validation to check if all acceptance criteria are specific and measurable." <commentary> Context trigger: Tasks file needs quality check before work begins </commentary> </example>

Use this agent when generating implementation designs for TypeScript/JavaScript projects. Triggers for /design command in projects with tsconfig.json, package.json with TypeScript dependencies, or when user requests TypeScript-specific patterns like Zod schemas, Vitest tests, or strongly-typed interfaces. <example> Context: User runs /design in a project containing tsconfig.json user: "/design" assistant: "I'll use the typescript-designer agent to generate a detailed implementation design with TypeScript types, Zod schemas, and Vitest tests." <commentary> Proactive trigger: Project has tsconfig.json indicating TypeScript stack </commentary> </example> <example> Context: User explicitly requests TypeScript design patterns user: "Design the API layer with Zod validation and Result types" assistant: "I'll use the typescript-designer agent to create a comprehensive design including Zod schemas with refinements and Result-based error handling." <commentary> Explicit trigger: User specifically requests TypeScript patterns (Zod, Result types) </commentary> </example> <example> Context: Working on Node.js/Deno backend with TypeScript user: "Create a design for the document chunking service" assistant: "I'll use the typescript-designer agent to design the chunking service with proper TypeScript interfaces, type-safe configurations, and comprehensive Vitest test cases." <commentary> Context-based trigger: Node.js/Deno project context implies TypeScript design needs </commentary> </example>

This skill should be used when writing Architecture Decision Records (ADRs), documenting technical decisions, or reviewing architecture choices. Triggers on phrases like "document this decision", "create ADR", "architecture decision", "why did we choose", "record the decision", "MADR template", or when the user is working on plan files that contain ADR sections.

This skill should be used when writing requirements, specifications, or user stories. Triggers on phrases like "write requirements", "create spec", "define user stories", "document feature", "specify behavior", "what should the system do", or when reviewing specification quality. Provides patterns for clear, testable, unambiguous requirements.

5 hooks across 3 events