Implement feature steps using git worktrees, build and test adaptively, update implementation plan, and generate test plans. This skill should be used when ready to implement one or more steps from an implementation plan, automatically adapting to any framework, language, or project structure.
npx claudepluginhub joshuarweaver/cascade-code-testing-misc --plugin laizyio-workflowskillsThis skill uses the workspace's default tool permissions.
Execute implementation steps from a plan, manage git worktrees for parallel development, adaptively build and test code, maintain plan progress, and generate comprehensive test plans. Works with any language, framework, or architecture through intelligent adaptation.
Creates isolated Git worktrees for feature branches with prioritized directory selection, gitignore safety checks, auto project setup for Node/Python/Rust/Go, and baseline verification.
Executes implementation plans in current session by dispatching fresh subagents per independent task, with two-stage reviews: spec compliance then code quality.
Dispatches parallel agents to independently tackle 2+ tasks like separate test failures or subsystems without shared state or dependencies.
Execute implementation steps from a plan, manage git worktrees for parallel development, adaptively build and test code, maintain plan progress, and generate comprehensive test plans. Works with any language, framework, or architecture through intelligent adaptation.
Use this skill when:
implementation-planner)Read the Implementation Plan
Create Git Worktree (if needed)
git-workflow-manager skill for worktree creationfeature/{name}, fix/{name}, etc.Understand Project Structure
Adaptive Discovery:
- React/Node: Read package.json → scripts.build, scripts.test
- .NET: Find *.csproj → dotnet build, dotnet test
- Python: Look for setup.py, pyproject.toml, Makefile
- Go: Check go.mod → go build, go test
- Rust: Find Cargo.toml → cargo build, cargo test
- Generic: Look for Makefile, build scripts
Implement the Step
Document Changes
Key Principle: Trust developer judgment for implementation details. The plan provides "what" and "where", developer provides "how".
Build the Project
Run Relevant Tests
Adaptive Testing:
# Examples of adaptive test execution
# JavaScript/TypeScript
npm test
# .NET
dotnet test
# Python
pytest
python -m pytest
# Go
go test ./...
# Rust
cargo test
# Generic
make test
./run-tests.sh
If Build/Test Commands Unknown:
Mark Step Complete
- [ ] → - [x]Check Next Steps
Plan Update Example:
## Phase 2: Backend Implementation
- [x] Step 2.1: Create EmailService class ✅
- [x] Step 2.2: Implement SendEmail method ✅
- [ ] Step 2.3: Add email queueing (next)
**Progress:** 2/3 steps complete (67%)
Use test-plan-generator Skill
Test Plan Contents
See test-plan-generator skill for detailed test plan generation.
When the plan includes a Documentation phase (it should always be the last phase), execute it using the following process.
Skip condition: If no [DOC]-* directory exists at the project root, skip this phase entirely and note it in the plan.
[DOC]-* directory at the project root[DOC]-*/_Templates/TPL-*.mdGlob each relevant subdirectory for documents related to the implemented feature:
[DOC]-*/04-Features/FEAT-*.md → Feature specifications
[DOC]-*/06-ADR/ADR-*.md → Architecture Decision Records
[DOC]-*/02-Database/DB-*.md → Database schemas
[DOC]-*/03-Architecture/ARCH-*.md → Architecture documentation
[DOC]-*/05-API/API-*.md → API endpoint documentation
[DOC]-*/08-Dev/DEV-*.md → Development notes
[DOC]-*/00-MOC/MOC-*.md → Index files
Read each potentially related document to understand what is currently documented.
For each document found:
Critical: NEVER trust only plan descriptions. Always verify actual file contents with the Read tool. The code is the source of truth.
For UPDATES:
updated field in YAML frontmatter to today's dateFor CREATES:
[DOC]-*/_Templates/TPL-{Type}.mdPREFIX-XXX-Titre.md---
title: Titre du document
type: feature|adr|database|arch|api|dev
status: draft
created: YYYY-MM-DD
updated: YYYY-MM-DD
tags:
- relevant-tags
---
[[Document-Name]] to related documentsFor ARCHIVES:
[DOC]-*/10-Archives/[DOC]-*/00-MOC/MOC-Principal.md- [ ] → - [x]Key Conventions:
PREFIX-XXX-Titre.md (3-digit zero-padded numbers)[[Document-Name]] format (no .md extension, no path prefix)Discovery:
# Files: package.json, tsconfig.json, vite.config.ts
# Build: npm run build
# Test: npm test
# Dev: npm run dev
Implementation Pattern:
src/components/src/services/src/types/Discovery:
# Files: *.csproj, Program.cs, appsettings.json
# Build: dotnet build
# Test: dotnet test
# Run: dotnet run
Implementation Pattern:
Controllers/Services/Domain/Entities/Discovery:
# Files: setup.py, pyproject.toml, requirements.txt
# Build: python -m build (if applicable)
# Test: pytest, python -m pytest
# Run: python main.py or module-specific
Implementation Pattern:
Discovery:
# Files: go.mod, go.sum
# Build: go build
# Test: go test ./...
# Run: go run main.go
Implementation Pattern:
Discovery Strategy:
make, make test./build.sh, ./test.sh✅ Use worktrees when:
❌ Don't use worktrees when:
Use git-workflow-manager skill:
# Create feature worktree
# git-workflow-manager will handle:
# - Creating ../repo-worktrees/feature/feature-name/
# - Creating branch feature/feature-name
# - Setting up worktree
Refer to git-workflow-manager skill for detailed worktree management.
Implement one step, build, test, update plan, generate test plan, done.
Use when:
Implement multiple related steps, build once, test once, update plan, generate test plan.
Use when:
Implement → Build → Test → Update → Next step → Repeat until phase complete.
Use when:
Try Common Commands:
# Try in order based on project type detected
npm run build
dotnet build
make
go build
cargo build
python -m build
mvn package
gradle build
Parse Build Output:
Handle Build Failures:
Try Common Test Commands:
npm test
dotnet test
pytest
go test ./...
cargo test
make test
mvn test
Selective Testing (if possible):
Handle Test Failures:
# Before
- [ ] Step 1: Create EmailService
# After
- [x] Step 1: Create EmailService
## Phase 2: Backend (67%)
- [x] Step 2.1: Done
- [x] Step 2.2: Done
- [ ] Step 2.3: Next
If implementation differs from plan:
- [x] Step 2.2: Implement SendEmail method
**Note:** Used Microsoft Graph instead of SMTP as decided during research
If step cannot be completed:
- [ ] Step 3.1: Deploy to staging
**Blocker:** Staging environment credentials not available
**Status:** Waiting for DevOps team
git-workflow-manager: For worktree creation and managementtest-plan-generator: For generating test plans after implementationfeature-research → implementation-planner → feature-implementer → test-executor → test-fixer
↓ ↓
test-plan-generator documentation-update
Plan Step: "Create POST /api/forms endpoint"
Implementation:
Plan Step: "Create FormBuilder component"
Implementation:
Plan Step: "Add Submission entity to database"
Implementation:
[DOC]-*/_Templates/TPL-*.md when creating new documentationreferences/implementation-checklist.md - Quality checklist for implementationsreferences/update-plan-guide.md - Guide for updating plansreferences/common-build-patterns.md - Build/test commands by framework