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>

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