sdd

Archive completed tickets

User input: "$ARGUMENTS"

Performs comprehensive post-implementation code review of a completed ticket. Produces 12-section analysis with confidence scoring and recommendations. Reviews implementation against planning documents, evaluates code quality, identifies security vulnerabilities, assesses performance, and generates actionable recommendations categorized by severity (CRITICAL/HIGH/MEDIUM/NITPICK). Usage examples: - Basic: /sdd:code-review DEEPREV - Focused: /sdd:code-review DEEPREV --focus security - Force incomplete: /sdd:code-review DEEPREV --force

Ticket: $ARGUMENTS

Ticket: $ARGUMENTS

Complete a single task with full verification workflow

Display epic-level status showing checkpoint progress

Create follow-up tasks mid-cycle from multiple input sources: code review findings, PR feedback comments, or user-provided instructions. Enables task creation after initial planning when new requirements emerge. Parses structured deliverables (code-review-report.md, pr-comments-analysis.md), applies severity filtering, assigns agents based on keywords, and delegates to task-creator for systematic task generation. Usage examples: - From user input: /sdd:extend TICKET "Add caching layer to API endpoints" - From code review: /sdd:extend TICKET --from-review --min-severity HIGH - From PR comments: /sdd:extend TICKET --from-pr-comments - Combined sources: /sdd:extend TICKET --from-review --from-pr-comments --max 5 - With limits: /sdd:extend TICKET --from-review --max 5 - Dry run: /sdd:extend TICKET --from-review --dry-run - Interactive: /sdd:extend TICKET --from-review --interactive - With agent: /sdd:extend TICKET --from-review --default-agent security-reviewer - With relationship: /sdd:extend TICKET --from-review --related-to TICKET.1003

Critically evaluate PR review comments and fix valid issues. Fetches PR comments (CodeRabbit, human reviewers, etc.), validates each against actual code to determine if correct, fixes valid issues, runs tests, and commits. Does NOT blindly trust reviewer suggestions - validates claims by examining code and tests. Usage examples: - Current branch PR: /sdd:fix-pr-feedback - Specific PR: /sdd:fix-pr-feedback 123 - PR URL: /sdd:fix-pr-feedback https://github.com/owner/repo/pull/123 - Dry run (analyze only): /sdd:fix-pr-feedback --dry-run - Skip nits: /sdd:fix-pr-feedback --skip-nits

User input: "$ARGUMENTS"

Import an external planning document and create SDD planning documents from it

Mark a ticket as ready for autonomous agent execution

User input: "$ARGUMENTS"

Fetch and display PR comments for feedback processing

Create GitHub Pull Request for completed ticket

User input: "$ARGUMENTS"

User input: "$ARGUMENTS"

Initialize SDD environment and reference templates

User input: "$ARGUMENTS"

Display comprehensive status overview across epics, tickets, and tasks with recommended actions

Check task status for tickets with parallel execution support

Display ticket-level status showing planning docs and task progress

Remove agent-ready status from a ticket

User input: "$ARGUMENTS"

Update ticket planning documents and tasks to assign newly created specialized agents to appropriate work items. Use this Sonnet agent after creating custom agents from agent-recommendations.md. Examples: <example> Context: Custom agents have been created after recommendations user: "I've created the migration-specialist and cache-engineer agents, now update the ticket to use them" assistant: "I'll use the agent-assigner agent to update the planning docs and tasks with the new agent assignments." <Task tool invocation to launch agent-assigner agent> </example> <example> Context: User wants to integrate new agents into ticket workflow user: "Assign the new agents to the APIV2 ticket" assistant: "I'll use the agent-assigner agent to integrate the new agents into the ticket planning and tasks." <Task tool invocation to launch agent-assigner agent> </example>

Analyze ticket planning documents to recommend custom specialized agents that would meaningfully improve ticket success probability. Use this Sonnet agent after ticket planning is complete to identify high-value opportunities for agent specialization. Examples: <example> Context: Ticket planning documents are complete user: "Analyze the APIV2 ticket and recommend any specialized agents that would help" assistant: "I'll use the agent-recommender agent to analyze the ticket and identify opportunities for specialized agents." <Task tool invocation to launch agent-recommender agent> </example> <example> Context: User wants to improve ticket execution quality user: "What specialized agents should I create for the DOCKER ticket?" assistant: "I'll use the agent-recommender agent to recommend specialized agents based on the ticket requirements." <Task tool invocation to launch agent-recommender agent> </example>

Performs comprehensive post-implementation code review producing 12-section analysis with confidence scoring and categorized recommendations. This Sonnet agent analyzes completed tickets by examining planning documents, task files, and git diffs to generate detailed quality assessments. Use this agent after ticket execution to evaluate production readiness, identify risks, and provide actionable improvement recommendations. Examples: <example> Context: Ticket tasks completed, ready for review before PR user: "Run a deep code review on the AUTH ticket" assistant: "I'll use the code-reviewer agent to perform comprehensive analysis." <Task tool invocation to launch code-reviewer agent> </example> <example> Context: Focus on security aspects of implementation user: "Review the API ticket but focus on security concerns" assistant: "I'll use the code-reviewer agent with --focus=security to emphasize security analysis." <Task tool invocation to launch code-reviewer agent with --focus parameter> </example> <example> Context: Full analysis needed for complex feature user: "Complete code review for CACHE ticket - check everything" assistant: "I'll use the code-reviewer agent to perform full 12-section analysis." <Task tool invocation to launch code-reviewer agent> </example>

Use this agent when the user has completed verification of their work and is ready to commit changes with a proper Conventional Commit message. This agent should be used after the verify-task agent has confirmed all work is complete and verified. Examples: <example> Context: Developer has verified their work and is ready to commit. user: "The ticket has been verified. Please commit my changes." assistant: "I'll use the Task tool to launch the commit-task agent to create a proper commit for your verified changes." <commentary> The user indicates verification is complete and wants to commit, which is this agent's purpose. Use the Task tool to invoke commit-task. </commentary> </example> <example> Context: Developer wants to commit after successful verification. user: "Now that verification passed, let's commit the changes for ticket #123." assistant: "I'll use the Task tool to launch the commit-task agent to commit your verified changes with a proper commit message." <commentary> The user is ready to commit after verification, perfect use case for commit-task agent. Use the Task tool to delegate this task. </commentary> </example> <example> Context: Developer mentions they've finished work and testing. user: "I've finished implementing the feature and all tests pass. Ready to commit." assistant: "I'll use the Task tool to launch the commit-task agent to create a Conventional Commit for your verified work." <commentary> The user signals completion and readiness to commit. Use the Task tool to invoke the commit-task agent. </commentary> </example>

Research and plan epics for higher-order discovery work. Use this Sonnet agent when exploring new problem spaces, conducting research before knowing exact deliverables, or decomposing epics into tickets. This agent fills epic documents with research, analysis, and ticket decomposition. Examples: <example> Context: User has created an epic and needs content user: "I've scaffolded the api-redesign epic, now fill in the analysis" assistant: "I'll use the epic-planner agent to research and fill the epic documents." <Task tool invocation to launch epic-planner agent> </example> <example> Context: User wants to decompose epic into tickets user: "Break down the authentication epic into concrete projects" assistant: "I'll use the epic-planner agent to analyze and decompose the epic." <Task tool invocation to launch epic-planner agent> </example>

Parse script output and format status reports for tickets and tasks. Use this Haiku agent when you need to format task status, ticket summaries, or validation results into readable reports. This agent receives JSON from scripts and formats it into markdown. Examples: <example> Context: User wants to see ticket status user: "What's the status of ticket APIV2?" assistant: "I'll run the status script and use the status-reporter agent to format the results." <Task tool invocation to launch status-reporter agent with script output> </example> <example> Context: After running task-status.sh assistant: "Let me format these task statuses into a readable report." <Task tool invocation to launch status-reporter agent> </example>

Validate ticket and task structure, checking for required files and sections. Use this Haiku agent when you need to verify a ticket follows the correct structure before proceeding with work. This agent checks file existence, required sections, and naming conventions. Examples: <example> Context: Before creating tasks for a ticket assistant: "Let me validate the ticket structure before creating tasks." <Task tool invocation to launch structure-validator agent> </example> <example> Context: User asks if ticket is ready user: "Is the APIV2 ticket properly set up?" assistant: "I'll use the structure-validator to check the ticket setup." <Task tool invocation to launch structure-validator agent> </example>

Use this agent when the user wants to create a standardized work task to document planned work. This agent should be invoked proactively when: <example> Context: User has described a new feature or task that needs to be documented. user: "I need to add caching middleware to the SLIM ticket. The caching-specialist agent should handle this." assistant: "I'll use the Task tool to launch the task-creator agent to document this work." </example> <example> Context: User mentions work but hasn't provided all details. user: "We should add better error handling to the tools" assistant: "I'll use the Task tool to launch the task-creator agent to gather information and create a proper work task." </example> <example> Context: User is planning a Phase 2 feature. user: "Let's create a task for implementing the Worker build pipeline in Phase 2. The worker-build-pipeline-engineer should handle this." assistant: "I'll use the Task tool to launch the task-creator agent to create a Phase 2 work task (starting at 2001)." </example>

Create comprehensive planning documents for tickets including analysis, architecture, and execution plans. Use this Sonnet agent after scaffolding a ticket structure to fill in the planning documents with well-researched content. This agent researches the codebase, considers existing patterns, and creates actionable plans. Examples: <example> Context: Ticket structure has been scaffolded user: "I've created the APIV2 ticket structure, now create the planning docs" assistant: "I'll use the ticket-planner agent to research and create the planning documents." <Task tool invocation to launch ticket-planner agent> </example> <example> Context: User wants to plan a new feature user: "Plan out the caching implementation for the search system" assistant: "I'll use the ticket-planner agent to create comprehensive planning documents." <Task tool invocation to launch ticket-planner agent> </example>

Critically review ticket plans and tickets for readiness, risks, and alignment with development principles. Use this Sonnet agent before creating tasks to catch issues early, or after task creation to review the complete ticket. This agent identifies scope creep, missing requirements, architectural issues, ticket quality problems, and duplication of existing functionality. Examples: <example> Context: Ticket planning is complete, ready for review user: "Review the APIV2 ticket before I create tasks" assistant: "I'll use the ticket-reviewer agent to critically evaluate the ticket plan." <Task tool invocation to launch ticket-reviewer agent> </example> <example> Context: User wants to validate ticket with existing tickets user: "Review the caching ticket - tasks have already been created" assistant: "I'll use the ticket-reviewer agent to assess both the ticket plan and all existing tickets." <Task tool invocation to launch ticket-reviewer agent> </example>

Systematically update ticket planning documents and tickets based on ticket-review findings. Use this Sonnet agent after ticket-reviewer has identified issues that need to be addressed. This agent reads the review, prioritizes fixes, updates planning documents, updates tickets (if they exist), and tracks all changes. Examples: <example> Context: Ticket review identified critical issues user: "The APIV2 ticket review found several issues. Update the ticket to fix them." assistant: "I'll use the ticket-updater agent to systematically address all review findings." <Task tool invocation to launch ticket-updater agent> </example> <example> Context: Ticket review found ticket quality issues user: "Update the caching ticket - the review found problems with several tasks" assistant: "I'll use the ticket-updater agent to fix both the planning docs and the problematic tickets." <Task tool invocation to launch ticket-updater agent> </example>

Use this agent when you need to execute unit tests and receive a clear report of test results without any code modifications. Examples: <example> Context: Developer has just finished implementing a new feature and wants to verify tests pass. user: "I've updated the database adapter, can you run the unit tests?" assistant: "I'll use the unit-test-runner agent to execute the tests and report the results." <Task tool invocation to launch unit-test-runner agent> </example> <example> Context: Developer wants to check current test status before making changes. user: "What's the current test status?" assistant: "Let me use the unit-test-runner agent to check the test suite status." <Task tool invocation to launch unit-test-runner agent> </example> <example> Context: Developer has made changes and wants verification without fixing. user: "Run the tests but don't fix anything, just tell me what's broken" assistant: "I'll use the unit-test-runner agent to run tests and report failures without making any changes." <Task tool invocation to launch unit-test-runner agent> </example> Do NOT use this agent when the user wants tests to be fixed, debugged, or code to be modified based on test failures. This agent is strictly for observation and reporting.

Use this agent when a developer has completed work on a task and needs to verify all requirements have been properly implemented before committing. <example> Context: Developer has finished implementing features. user: "I've finished the authentication feature. Can you verify it matches the task requirements?" assistant: "I'll use the Task tool to launch the verify-task agent to check that all ticket requirements have been properly implemented." </example> <example> Context: Developer wants to ensure changes are complete before commit phase. user: "Please check if my implementation for ticket SLIM.2001 meets all requirements." assistant: "I'll use the Task tool to launch the verify-task agent to verify your changes against the task specifications." </example> <example> Context: Developer wants to ensure nothing was missed. user: "I think I'm done with the user profile feature. Can you make sure I didn't miss anything?" assistant: "I'll use the Task tool to launch the verify-task agent to perform comprehensive verification against all ticket requirements." </example> Do NOT use this agent for: committing changes (use commit-task), creating tasks, or modifying code. This agent only verifies completed work.

Log significant workflow events for enterprise audit trails and metrics. Use this agent to record task completions, ticket milestones, and verification outcomes. This agent appends timestamped entries to a centralized log file. <example> Context: After a task has been committed assistant: "I'll log this task completion for tracking." <Task tool invocation to launch workflow-logger agent with event details> </example> <example> Context: After ticket archival assistant: "Let me record this ticket completion in the workflow log." <Task tool invocation to launch workflow-logger agent> </example>

Orchestrates epics, tickets, and tasks for systematic software development. Use this skill when planning work, creating tickets, managing tasks, or executing development workflows. Includes scripts for scaffolding and status reporting, with Haiku agents for mechanical tasks and Sonnet agents for reasoning. All SDD data (epics, tickets, tasks, archives) lives at $SDD_ROOT_DIR, not in the repo.

Analyze session transcript logs to identify genuine reusable skill candidates across multiple tickets and sessions

7 hooks across 6 events