vbounce

Approve the current V-Bounce phase and advance to next

Start a V-Bounce bugfix cycle (P2/P3)

Start a V-Bounce change request cycle (mid-cycle scope change)

Start a V-Bounce hotfix cycle (P0/P1 emergency)

Rollback to a previous V-Bounce phase

Use this agent when deployment plans, rollback strategies, and pre/post-deployment checklists need to be created. Handles staging and production deployments with proper approvals. STANDARD bounce time. Trigger this agent during the Deployment phase after testing is approved. <example> Context: Testing phase has been approved and deployment planning needs to begin. user: "Testing is approved. Create the deployment plan." assistant: "I'll launch the deployment-engineer agent to create the deployment plan with rollback strategy and monitoring." <commentary> Standard deployment trigger. Agent first runs acceptance verification, then produces deployment plan. </commentary> </example> <example> Context: User needs a specific deployment strategy for a new service. user: "We need a canary deployment strategy for the new API version." assistant: "Let me use the deployment-engineer agent to design a canary deployment plan with gradual traffic shifting." <commentary> Strategy-specific request. Agent designs canary with quantitative rollback triggers. </commentary> </example> <example> Context: User needs a standalone rollback plan for risk mitigation. user: "Create a rollback plan for the upcoming release." assistant: "I'll launch the deployment-engineer agent to create a rollback plan with quantitative triggers and notification procedures." <commentary> Targeted rollback planning. Agent produces trigger conditions, procedures, and verification steps. </commentary> </example>

Use this agent when the user needs to create or update technical designs for approved requirements. This includes architecture design, API design, data model design, security threat modeling (STRIDE), Architecture Decision Records (ADRs), and design-time test specifications. Trigger this agent during the Design phase. <example> Context: Requirements phase has been approved and design work needs to begin. user: "The requirements have been approved. Let's design it." assistant: "I'll launch the design-architect agent to create the full technical design based on the approved requirements." <commentary> Standard design phase trigger after requirements approval. Agent reads requirements artifacts and produces 8 design files. </commentary> </example> <example> Context: A new component needs technical design and the requirements are ready. user: "We need to add a new data ingestion pipeline. The requirements are ready for design." assistant: "Let me use the design-architect agent to produce the architecture, API spec, data model, STRIDE analysis, and ADRs." <commentary> Feature-specific design request. Agent will trace all requirements to design components. </commentary> </example> <example> Context: Design feedback received after review, architecture needs revision. user: "We got feedback on the design. Need to revise the architecture." assistant: "I'll launch the design-architect agent to revise the design based on the feedback." <commentary> Design refinement cycle (anatomy step 5). Agent reads feedback and updates design artifacts. </commentary> </example>

Unified TDD agent: writes tests from contracts (RED), implements code (GREEN), executes and verifies (REFACTOR). Self-contained execution loop with max 3 iterations. Handles the full Implementation phase including test generation, code implementation, package verification, and execution verification. Trigger this agent during the Implementation phase. <example> Context: Contracts created, design approved. Implementation needs to produce code + tests + execution. user: "Contracts are ready. Please implement the feature." assistant: "I'll launch the implementation-engineer agent in unified TDD mode to write tests (RED), implement code (GREEN), and execute verification." <commentary> Unified TDD trigger after contract generation. Agent writes tests from contracts, implements code to pass them, and verifies via execution. </commentary> </example> <example> Context: Specific modules need to be implemented in parallel mode. user: "Implement the auth module (Scope: auth-service, auth-middleware)." assistant: "I'll launch the implementation-engineer agent scoped to auth-service and auth-middleware modules only." <commentary> Parallel mode with scope restriction. Agent only implements listed modules from contracts. </commentary> </example> <example> Context: Quality gate flagged issues in the implementation that need fixing. user: "The implementation needs revisions — QG flagged test distribution imbalance and 1 unverified package." assistant: "I'll launch the implementation-engineer agent to fix the flagged issues, rebalance tests, re-verify packages, and re-execute." <commentary> Refinement cycle triggered by QG failure. Agent re-verifies and fixes issues through the full TDD loop. </commentary> </example>

Use this agent to capture knowledge from AI-assisted development cycles. Supports two modes: Per-Phase (lightweight capture after each phase approval) and End-of-Cycle (full retrospective). Also handles QG failure capture — extracting failure patterns into prevention rules. <example> Context: A phase has just been approved and learnings need to be captured. user: "The requirements phase just got approved. Capture the phase learnings." assistant: "I'll launch the knowledge-curator in Per-Phase mode to capture ambiguity patterns and clarification effectiveness." <commentary> Per-Phase capture after approval. Agent extracts phase-specific knowledge into YAML capture file. </commentary> </example> <example> Context: All SDLC phases are complete and a retrospective is needed. user: "All phases are complete. Run the end-of-cycle retrospective." assistant: "Let me use the knowledge-curator in End-of-Cycle mode to aggregate all captures and generate lessons learned." <commentary> End-of-Cycle mode aggregates all phase captures, writes prevention rules, and updates config overrides. </commentary> </example> <example> Context: Quality gate returned FAIL and the failure pattern needs to be captured before revision. user: "The quality gate failed on the requirements output." assistant: "I'll launch the knowledge-curator to capture the failure pattern and write a prevention rule before the agent revises." <commentary> QG failure capture. Agent writes prevention rule to learned-rules file so the phase agent can read and apply it. </commentary> </example>

Use this agent to validate Deployment phase output against domain-specific quality criteria. Checks acceptance verification, rollback plan quality, checklist completeness, and monitoring alerts. Returns PASS/WARN/FAIL verdict. Invoked automatically after deployment plan generation, before human review. <example> Context: Deployment agent has completed its output and needs validation. user: "Run quality gate on the deployment output." assistant: "I'll launch qg-deployment to check acceptance verification, rollback plan, checklist completeness, and monitoring alerts." <commentary> Automatic QG invocation after deployment plan generation. Agent validates deployment readiness. </commentary> </example>

Use this skill when the user wants to run a V-Bounce SDLC cycle, start a vbounce workflow, or manage a structured software development lifecycle with the V-Bounce framework. Orchestrates 12 specialized agents through phases: Requirements, Design, Contracts, Implementation (unified TDD), Review, and Deployment with mixed-model assignment, per-phase specialized QG agents, unified TDD flow, tech-aware context injection, state management, contract validation, and quality gates at every transition. Triggers: "start vbounce cycle", "run sdlc pipeline", "resume vbounce", "APPROVED", "CHANGES REQUESTED", "START BUGFIX", "START CR", "tech-aware", "TDD flow". Do NOT use for general code review, testing, design, or implementation tasks outside the V-Bounce framework.

2 hooks across 2 events