From vbounce
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.
How this skill is triggered — by the user, by Claude, or both
Slash command
/vbounce:vbounceThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Agent-first SDLC framework with explicit contracts, shared workspace, state management, unified TDD, and per-phase specialized QG agents.
references/acceptance-criteria.mdreferences/ambiguity-checklist.mdreferences/approval-matrix.mdreferences/architecture-patterns.mdreferences/coding-standards.mdreferences/edge-cases.mdreferences/hallucination-patterns.mdreferences/id-conventions.mdreferences/phase-anatomy.mdreferences/quality-criteria.mdreferences/tech-stack-commands.mdreferences/user-story-patterns.mdreferences/workflows-bugfix-track.mdreferences/workflows-by-role.mdreferences/workflows-change-request-track.mdreferences/workflows-hotfix-track.mdAgent-first SDLC framework with explicit contracts, shared workspace, state management, unified TDD, and per-phase specialized QG agents.
Based on arXiv 2408.03416 (Hymel, 2024): AI handles implementation, humans shift to validators/verifiers.
.vbounce/cycles/{cycle_id}/When the user provides a PRD or says "start vbounce cycle":
CYCLE-{PROJECT}-{YYYYMMDD}-{SEQ} (derive PROJECT from directory name, SEQ starts at 001)mkdir -p .vbounce/cycles/{cycle_id}/{requirements,design,contracts,implementation,review,deployment,knowledge,quality-gates}.vbounce/cycles/{cycle_id}/prd.mdpackage.json (JS/TS), pyproject.toml / requirements.txt (Python), *.csproj (C#), go.mod (Go), Cargo.toml (Rust), pom.xml / build.gradle (Java/Kotlin)CLAUDE.md for explicit tech stack declarations (overrides auto-detection){workspace}/tech-context.yaml with: language, runtime, package_manager, frameworks (list of {name, version, role}), build_tool, install_command, compile_command, test_command, source_dirs, test_dirs, detected_fromtech-context.yaml, check for relevant installed skills:
hallucination-patterns.md for entries matching detected ecosystem, coding-standards.md for detected language, CLAUDE.md for project-specific conventions{workspace}/tech-context-prompt.md with: primary stack info, key patterns, known hallucination risks, testing conventions.vbounce/cycles/{cycle_id}/state.yaml with v5.1 state schema (all phases including contracts set to not_started, current_phase: requirements, anatomy_step: input, tech_context populated from detection).vbounce/state.yaml with just active_cycle: {cycle_id} and workspace: .vbounce/cycles/{cycle_id}The root .vbounce/state.yaml only stores which cycle is active. All phase state lives in {workspace}/state.yaml.
Throughout this document and all agent contracts, {workspace} is a placeholder. You MUST resolve it to the actual path before any operation:
.vbounce/state.yaml → get workspace field (e.g., .vbounce/cycles/CYCLE-MYAPP-20260307-001){workspace} references with this concrete pathExample: {workspace}/requirements/requirements.md → .vbounce/cycles/CYCLE-MYAPP-20260307-001/requirements/requirements.md
{project}/.vbounce/
├── state.yaml # Active cycle pointer only
└── cycles/
└── CYCLE-{PROJECT}-{DATE}-{SEQ}/
├── prd.md # User provides
├── state.yaml # Orchestrator manages
├── tech-context.yaml # Orchestrator detects (tech stack)
├── tech-context-prompt.md # Orchestrator generates (framework context for agents)
├── requirements/ # requirements-analyst writes
│ ├── requirements.md
│ ├── test-skeletons.md
│ ├── traceability.yaml
│ └── ambiguity-report.md
├── quality-gates/ # per-phase QG agents write
│ ├── qg-requirements.yaml
│ ├── qg-design.yaml
│ ├── qg-implementation.yaml
│ └── qg-deployment.yaml
├── design/ # design-architect writes
│ ├── design.md
│ ├── security-design.md
│ ├── api-spec.md
│ ├── database-schema.md
│ ├── architecture-decisions.md
│ ├── traceability.yaml
│ ├── test-impact.md
│ └── test-specifications.md
├── contracts/ # Orchestrator generates (shared API contracts)
│ ├── contracts.{ext} # .ts/.py/.cs/.go/.md based on language
│ ├── api-surface.yaml
│ └── test-plan.yaml
├── implementation/ # implementation-engineer writes (unified TDD)
│ ├── summary.md
│ ├── package-verification.md
│ ├── test-report.md # Distribution stats, V-Model levels
│ ├── coverage-matrix.md # AC → test mapping
│ └── execution-report.md # Compile + test results per iteration
├── review/ # review-auditor writes
│ ├── review-report.md
│ ├── hallucination-report.md
│ └── security-findings.md
├── deployment/ # deployment-engineer writes
│ ├── deployment-plan.md
│ ├── acceptance-verification.md
│ ├── pre-deploy-checklist.md
│ └── monitoring.md
├── knowledge/ # knowledge-curator writes
│ ├── requirements-capture.yaml
│ ├── design-capture.yaml
│ └── ...
└── traceability.yaml # traceability-analyst writes
cycle_id: CYCLE-{PROJECT}-{YYYYMMDD}-{SEQ}
workspace: .vbounce/cycles/CYCLE-{PROJECT}-{YYYYMMDD}-{SEQ}
current_phase: requirements
anatomy_step: input | generation | quality_gate | review | refinement | approval | post_phase
tech_context:
detected: false # true after tech stack detection runs
# Full details in {workspace}/tech-context.yaml (language, runtime, frameworks, commands, dirs)
phases:
requirements:
status: not_started | in_progress | qg_pending | review_pending | approved
artifacts: []
qg_verdict: null
qg_ref: null
approved_by: null
kc_captured: false
design:
status: not_started
contracts:
status: not_started | generated
implementation:
status: not_started | in_progress | qg_pending | review_pending | approved
execution_status: not_started | running | passed | failed
execution_iterations: 0
task_groups: [] # for parallel agent teams [{group_id, modules, status, agent_id}]
artifacts: []
qg_verdict: null
approved_by: null
review:
status: not_started
deployment:
status: not_started
history:
- timestamp: "ISO-8601"
action: "description"
On every invocation:
.vbounce/state.yaml → get active_cycle and workspace path{workspace}/state.yaml → get current_phase and anatomy_step.vbounce/state.yaml does not exist, this is a new cycle — run Cycle InitializationRead {workspace}/state.yaml
→ Determine current_phase + anatomy_step
→ Route to appropriate action
Before launching any phase agent, verify its input files exist:
For each file in agent.contract.input where required=YES:
IF file does not exist at {workspace}/{path}:
BLOCK — report missing input, do not launch agent
Launch the phase agent with workspace context:
<files_to_read>
- {workspace}/{input_file_1}
- {workspace}/{input_file_2}
- ...
</files_to_read>
Workspace: {workspace}
Phase: {phase}
After agent completes, verify output files exist and contain required patterns:
For each file in agent.contract.output:
IF file does not exist at {workspace}/{path}:
FAIL — output missing
IF validation pattern specified:
IF file does not match pattern:
WARN — output may be incomplete
phases.{phase}.status: qg_pending
phases.{phase}.artifacts: [list of output files]
anatomy_step: quality_gate
history: + {timestamp, action}
Dispatch the appropriate per-phase QG agent:
qg-requirementsqg-designqg-implementationqg-deploymentThen route on verdict:
After QG passes, you MUST present the phase results to the user before proceeding. This is the human review gate.
What to show:
Artifacts produced:
- .vbounce/cycles/CYCLE-XXX/requirements/requirements.md (12 user stories, 47 ACs)
- .vbounce/cycles/CYCLE-XXX/requirements/test-skeletons.md (47 test skeletons)
- .vbounce/cycles/CYCLE-XXX/requirements/traceability.yaml (full matrix)
- .vbounce/cycles/CYCLE-XXX/requirements/ambiguity-report.md (avg score: 23)
Quality Gate: PASS (6/6 criteria passed)
If WARN, list the specific warnings.Ready for your review. Please respond with:
- APPROVED (or APPROVED AS [Role]) — proceed to next phase
- CHANGES REQUESTED — describe what needs revision
Approvers for this phase: [from approval-matrix.md]
What to do after user responds:
APPROVED / APPROVED AS [Role]:
phases.{phase}.status: approved, phases.{phase}.approved_by: [role]current_phase: {next_phase}, anatomy_step: inputCHANGES REQUESTED:
anatomy_step: refinementThe hooks/hooks.json file provides automated contract validation:
{workspace} placeholders or missing input file listThese hooks transform convention-based contracts into enforced contracts.
After Design approval and post-phase agents (trace+KC) complete:
{workspace}/design/*.md + {workspace}/requirements/*.md + {workspace}/tech-context.yaml.ts interfaces (export interface ...).py Protocol/ABC classes (class ...Protocol: ...).cs interface definitions (public interface I... { ... }).go interface types (type ... interface { ... }).java/.kt interface files.md language-agnostic pseudocode with method signatures table{workspace}/contracts/api-surface.yaml — every public method: name, params, return type, throws{workspace}/contracts/test-plan.yaml — positive/negative/edge test cases per method, mapped to ACsphases.contracts.status: generatedExecution verification is handled internally by implementation-engineer (Steps 7-10 of its process). The agent runs install → compile → test with up to 3 fix iterations and writes the results to {workspace}/implementation/execution-report.md. The orchestrator no longer runs execution as a separate step.
| Phase | Agent | Model | Input Contract | Output Contract |
|---|---|---|---|---|
| Requirements | requirements-analyst | opus | prd.md, state.yaml | requirements/*.md (4 files) |
| Design | design-architect | opus | requirements/*.md (3 files), state.yaml | design/*.md (8 files) |
| (contracts) | orchestrator direct | — | design/*.md, requirements/*.md, tech-context.yaml | contracts/ (3 files) |
| Implementation | implementation-engineer | sonnet | contracts/, requirements/*.md, design/*.md, tech-context.yaml, state.yaml | implementation/*.md (5 files) + source code + test code |
| Review | review-auditor | sonnet | contracts/, implementation/*.md, source code, test code, design/, state.yaml | review/*.md (3 files) |
| Deployment | deployment-engineer | haiku | implementation/test-report.md, implementation/coverage-matrix.md, requirements/requirements.md, implementation/summary.md, state.yaml | deployment/*.md (4 files) |
Note: tech-context-prompt.md is injected into every phase agent dispatch prompt by the orchestrator (see Agent-to-Agent Context Passing). It is not listed as a file input because agents receive it inline in the prompt text.
| Agent | Model | When Invoked | Input | Output |
|---|---|---|---|---|
| qg-requirements | sonnet | After requirements generation (anatomy step 3) | requirements/ artifacts, state.yaml | quality-gates/qg-requirements.yaml |
| qg-design | sonnet | After design generation (anatomy step 3) | design/ artifacts, requirements/requirements.md, state.yaml | quality-gates/qg-design.yaml |
| qg-implementation | sonnet | After implementation generation (anatomy step 3) | implementation/ artifacts, contracts/, source + test code, state.yaml | quality-gates/qg-implementation.yaml |
| qg-deployment | sonnet | After deployment generation (anatomy step 3) | deployment/ artifacts, implementation/test-report.md, requirements/requirements.md, state.yaml | quality-gates/qg-deployment.yaml |
| traceability-analyst | haiku | PARALLEL after phase approval (mode=update); after deployment (mode=finalize) | Phase artifacts, existing matrix | traceability.yaml |
| knowledge-curator | haiku | PARALLEL after phase approval; after QG failure | Phase artifacts, QG report | knowledge/{phase}-capture.yaml, learned rules |
When api-surface.yaml contains >= 3 independent modules (no cross-module method calls or shared types), the orchestrator MAY parallelize the Implementation phase:
api-surface.yamlimplementation-engineer gets scoped contracts + Scope: [module-list] in its promptinstall_command + compile_command + test_command) to catch cross-module integration issuesimplementation-engineer with ALL modules and the error output (max 2 integration-fix iterations)implementation.task_groups: [{group_id: "auth", modules: ["auth-service", "auth-middleware"], status: "completed", agent_id: "..."}]When NOT to parallelize: < 3 modules, shared base types across modules, or modules with circular imports.
When launching an agent via the Agent tool, construct the prompt with resolved paths (not placeholders). This is a convention — the agent reads your prompt text and follows the instructions.
Example prompt for launching design-architect:
Read these files BEFORE any work:
- .vbounce/cycles/CYCLE-MYAPP-20260307-001/requirements/requirements.md
- .vbounce/cycles/CYCLE-MYAPP-20260307-001/requirements/test-skeletons.md
- .vbounce/cycles/CYCLE-MYAPP-20260307-001/requirements/traceability.yaml
- .vbounce/cycles/CYCLE-MYAPP-20260307-001/state.yaml
Workspace: .vbounce/cycles/CYCLE-MYAPP-20260307-001
Phase: design
## Technology Context
{contents of .vbounce/cycles/CYCLE-MYAPP-20260307-001/tech-context-prompt.md}
Write all output files to: .vbounce/cycles/CYCLE-MYAPP-20260307-001/design/
Tech context injection: Include ## Technology Context\n{contents of tech-context-prompt.md} in every agent dispatch prompt. This gives every agent framework-specific knowledge without needing to load skills themselves.
Each agent's CONTRACT section lists what files it needs — use that as the checklist when constructing the prompt.
Reference files: Agent contracts list references like references/acceptance-criteria.md. These are relative to the plugin's skill directory. Agents access them via their memory: project setting and the plugin's auto-loaded context. Agents do NOT need explicit paths to reference files — they are loaded as part of the skill context.
| Command | Effect |
|---|---|
APPROVED | Proceed to next phase (triggers KC + traceability update) |
APPROVED AS [ROLE] | Approve with specific role |
CHANGES REQUESTED | Revise current output (loops to refinement) |
SKIP TO [phase] | Jump to phase (if prerequisites met) |
ROLLBACK TO [phase] | Return to previous phase |
START CR [description] | Pause feature cycle, start CR assessment |
START BUGFIX [ticket-id] | Start bugfix workflow |
During the Requirements phase, test skeletons are generated alongside stories. After Design approval, the orchestrator generates contracts/ — a shared API surface defining every interface, method signature, and type.
The unified TDD flow runs in a single agent (implementation-engineer):
api-surface.yamlThis eliminates the agent-to-agent contract mismatch problem from v5.0 by having ONE agent own tests + code + execution.
All knowledge is stored following Claude Code conventions:
~/.claude/projects/<project>/memory/
├── MEMORY.md
└── agents/
├── requirements-analyst/MEMORY.md
├── design-architect/MEMORY.md
└── ...
.claude/
├── vbounce.local.md # Per-project config overrides
└── rules/
└── vbounce-learned-rules.md # Auto-generated prevention rules
All agents can consult these reference files:
| Reference | Description | Used By |
|---|---|---|
| phase-anatomy.md | 7-Activity cycle definition | All agents |
| id-conventions.md | US-XXX, AC-XXX, NFR-XXX formats | All agents |
| approval-matrix.md | Who approves each phase | Orchestrator |
| quality-criteria.md | Phase-specific QG criteria index | qg-requirements, qg-design, qg-implementation, qg-deployment |
| acceptance-criteria.md | GIVEN-WHEN-THEN patterns | requirements-analyst |
| ambiguity-checklist.md | Ambiguity detection guide | requirements-analyst |
| user-story-patterns.md | Story templates and sizing | requirements-analyst |
| architecture-patterns.md | Architecture styles | design-architect |
| coding-standards.md | Naming and structure | implementation-engineer |
| hallucination-patterns.md | Known fake packages | implementation-engineer, review-auditor |
| edge-cases.md | Edge case checklist | implementation-engineer |
| tech-stack-commands.md | Tech stack command resolution | Orchestrator |
| workflows-bugfix-track.md | Bugfix workflow (P2/P3) | Orchestrator |
| workflows-hotfix-track.md | Hotfix workflow (P0/P1) | Orchestrator |
| workflows-change-request-track.md | Change request workflow | Orchestrator |
| workflows-by-role.md | Role-specific quick reference | All agents |
npx claudepluginhub baodq97/open-plugin --plugin vbounceGuides through V-Model workflow: assesses project state from BACKLOG.md, HANDOFFS.md, git; recommends next phase skill; audits handoffs; creates feature branches at entry points.
Guides the full SDLC workflow: planning, implementation, testing, and deployment. Automates checklist-driven development for features, bug fixes, refactoring, and releases.
Orchestrates all code-modifying development tasks like bug fixes, enhancements, and new features using adaptive phases for analysis, specs, TDD, implementation, and verification.