Verify existing implementations before coding to prevent duplicate work and enable verification-focused workflows. Use before starting any new feature implementation to check if functionality already exists. Saves 20-40% of implementation time by avoiding redundant work.
Instrucciones de origen · Vista previa de solo lectura
name
pre-implementation-check
description
Verify existing implementations before coding to prevent duplicate work and enable verification-focused workflows. Use before starting any new feature implementation to check if functionality already exists. Saves 20-40% of implementation time by avoiding redundant work.
Pre-Implementation Check
Verify existing implementations before coding to prevent duplicate work. Saves 20-40% of implementation time by catching existing features early.
Overview
Before implementing new functionality, always verify:
Does this feature already exist?
Is it partially implemented?
Does it need enhancement rather than creation?
Pattern observed: Agents discovered features already implemented after starting work, wasting 20-40% of implementation time.
Mandatory Skill Loading Validation
CRITICAL: Before starting implementation, verify ALL mandatory skills are loaded. Missing mandatory skills lead to incomplete verification and protocol violations.
Add Dev Server Health Check to Pre-Implementation Workflow
Before starting implementation, verify dev server is running and healthy:
# Check if dev server is runningcheck_dev_server() {
local port=${1:-5173}# Default Vite port# Check if port is in useif lsof -i :$port > /dev/null 2>&1; thenecho"Dev server running on port $port"# Health checkif curl -f http://localhost:$port > /dev/null 2>&1; thenecho"Dev server is healthy"return 0
elseecho"Dev server not responding"return 1
fielseecho"Dev server not running on port $port"return 1
fi
}
Backend / Server (for backend tasks)
Before the first API test: Check that the target port is free (e.g. lsof -i :PORT) or that a single dev server is listening. Start command: use an explicit directory (e.g. cd /absolute/path/to/backend && npm run dev). Optional: short-timeout health check (e.g. curl -f http://localhost:PORT/api/health --max-time 5). Auth tasks: First register/login may be slow (e.g. bcrypt). Use request timeouts (e.g. 10–15 s) for register/login (e.g. curl --max-time 10).
Path convention (monorepos)
Backend library code lives under backend/src/lib/, not backend/lib/. Confirm the backend app root before creating API or lib files.
Port Verification Patterns
Pattern 1: Check Configuration Files
# Check vite.config.ts for port
PORT=$(grep -o "port: [0-9]*" vite.config.ts | grep -o "[0-9]*" || echo"5173")
# Check package.json for port in dev script
PORT=$(grep -o "vite --port [0-9]*" package.json | grep -o "[0-9]*" || echo"5173")
Pattern 2: Check Common Ports
# Check common ports in parallelfor port in 3000 5173 8080 5000; doif lsof -i :$port > /dev/null 2>&1; thenecho"Dev server found on port $port"breakfidone
Pattern 3: Parse Terminal Output
# If server is starting, parse output for port
npm run dev 2>&1 | grep -o "Local:.*http://localhost:[0-9]*" | grep -o "[0-9]*"
Server Readiness Checks
Verify server is actually serving content:
# Health check functionverify_server_ready() {
local url=$1local max_attempts=5
local attempt=0
while [ $attempt -lt $max_attempts ]; doif curl -f "$url" > /dev/null 2>&1; thenecho"Server is ready"return 0
fi
attempt=$((attempt + 1))
sleep $((2 ** $attempt)) # Exponential backoff: 2s, 4s, 8s, 16sdoneecho"Server not ready after $max_attempts attempts"return 1
}
Test Seam Availability
Check Test Seam Availability Before Implementation
For Phaser games, check test seam availability before implementation:
# Check test seam availabilitycheck_test_seam_availability() {
local url=$1local max_wait=5 # 5 seconds max# Open browser
agent-browser open "$url"# Wait for test seam with timeoutlocal elapsed=0
while [ $elapsed -lt $max_wait ]; doif agent-browser eval"window.__TEST__?.sceneKey || false"; thenecho"Test seam available"return 0
fisleep 1
elapsed=$((elapsed + 1))
doneecho"Test seam not available after $max_wait seconds"return 1
}
Document Expected Setup Times
Document expected test seam setup times:
Scenario
Expected Setup Time
Initial page load
2-5 seconds
Scene transition
1-3 seconds
Test seam initialization
1-2 seconds
Total
4-10 seconds
If test seam takes longer than expected:
Check browser console for errors
Verify test seam setup in source code
Check if scene is properly initialized
Fallback Strategies When Test Seams Aren't Ready
If test seams aren't available after timeout:
Document limitation:
## Test Seam Limitation
Test seam not available after 5 second timeout.
Proceeding with implementation, will verify via code review.
Use alternative verification:
Code review
TypeScript compilation
DOM inspection (if applicable)
Proceed with caution:
Note limitation in progress.txt
Use alternative verification methods
Document fallback method used
Dependency Verification
Check for Required Dependencies
Before implementation, verify required dependencies are installed:
# Check for required npm packagescheck_dependencies() {
local required_packages=("phaser""typescript""vite")
for package in"${required_packages[@]}"; doif ! grep -q "\"$package\"" package.json; thenecho"Missing dependency: $package"return 1
fidoneecho"All required dependencies present"return 0
}
# Check test infrastructurecheck_test_infrastructure() {
# Check for test filesif [ ! -d "tests" ] && [ ! -d "__tests__" ]; thenecho"Test directory not found"# Not a blocker, but documentfi# Check for test runnerif ! grep -q "\"test\"" package.json; thenecho"Test script not found in package.json"# Not a blocker, but documentfi# Check for agent-browser (for browser testing)if ! command -v agent-browser &> /dev/null; thenecho"agent-browser not found"# Document limitationfiecho"Test infrastructure check complete"
}
Infrastructure Checks
Verification Patterns for Common Development Environments
Pattern 1: Vite Development Environment
# Vite environment checkcheck_vite_environment() {
# Check vite.config.ts existsif [ ! -f "vite.config.ts" ] && [ ! -f "vite.config.js" ]; thenecho"vite.config not found"return 1
fi# Check dev server portlocal port=$(grep -o "port: [0-9]*" vite.config.ts 2>/dev/null | grep -o "[0-9]*" || echo"5173")
# Check if dev server is runningif lsof -i :$port > /dev/null 2>&1; thenecho"Vite dev server running on port $port"return 0
elseecho"Vite dev server not running"return 1
fi
}
Pattern 2: Phaser Game Environment
# Phaser game environment checkcheck_phaser_environment() {
# Check Phaser is installedif ! grep -q "\"phaser\"" package.json; thenecho"Phaser not found in package.json"return 1
fi# Check for scene filesif [ ! -d "src/scenes" ] && [ ! -d "scenes" ]; thenecho"Scene directory not found"# Not a blocker, but documentfi# Check for test seam setupif ! grep -r "window.__TEST__" src/ 2>/dev/null; thenecho"Test seam not found in source code"# Document limitationfiecho"Phaser environment check complete"return 0
}
Pattern 3: React Application Environment
# React environment checkcheck_react_environment() {
# Check React is installedif ! grep -q "\"react\"" package.json; thenecho"React not found in package.json"return 1
fi# Check for component filesif [ ! -d "src/components" ] && [ ! -d "components" ]; thenecho"Component directory not found"# Not a blocker, but documentfiecho"React environment check complete"return 0
}
Checklist Template for Pre-Implementation Verification
Use this checklist for every pre-implementation check:
## Pre-Implementation Verification Checklist### Mandatory Skills- [ ] All mandatory skills loaded (see Mandatory Skill Loading section)
### Dev Server- [ ] Dev server is running
- [ ] Dev server is healthy (responds to HTTP requests)
- [ ] Port verified (from config or detected)
- [ ] Server is serving content correctly
### Test Seam (for Phaser games)- [ ] Test seam available (if applicable)
- [ ] Test seam setup time documented
- [ ] Fallback strategy defined (if test seam unavailable)
### Dependencies- [ ] Required dependencies installed
- [ ] Build tools available (Node.js, npm, TypeScript)
- [ ] Test infrastructure ready (if applicable)
### Infrastructure- [ ] Development environment verified (Vite/React/Phaser)
- [ ] Configuration files present
- [ ] Source code structure verified
### Feature Check- [ ] Codebase searched for existing implementation
- [ ] Test seam commands checked (if applicable)
- [ ] Success criteria compared to existing code
- [ ] Decision made: verify existing vs. implement new
### Documentation- [ ] Findings documented in progress.txt
- [ ] Limitations documented (if any)
- [ ] Action plan documented
Verify mandatory skills loaded (see Mandatory Skill Loading section)
Check dev server:
Verify dev server is running
Check server health
Verify port configuration
Check test seam availability (for Phaser games):
Verify test seam is available
Document setup time
Define fallback strategy if unavailable
Verify dependencies:
Check required packages are installed
Verify build tools are available
Confirm test infrastructure is ready
Verify infrastructure:
Check development environment (Vite/React/Phaser)
Verify configuration files
Check source code structure
Only proceed to Step 1 after infrastructure is verified.
Step 1: Search Codebase
Use codebase_search() with relevant keywords:
// Search for existing implementationsconst results = awaitcodebase_search({
query: "How is feature X implemented?",
target_directories: []
});
// Check for function/class namesconst classResults = awaitcodebase_search({
query: "Where is FeatureX class or function defined?",
target_directories: []
});
Use grep to find specific patterns:
# Search for function/class names
grep -r "functionName" src/
grep -r "ClassName" src/
# Search for test seam commands
grep -r "clickStartGame\|goToScene\|setTimer" src/
Step 2: Check Test Seams
Test seam commands indicate existing functionality:
// Check for test seam commands in codebaseconst testSeamResults = awaitcodebase_search({
query: "What test seam commands are available?",
target_directories: []
});
// Look for window.__TEST__.commands patterns
grep -r "window.__TEST__\.commands\." src/
Common test seam commands that indicate features:
clickStartGame() → Game start functionality exists
setTimer(seconds) → Timer functionality exists
collectCoin() → Coin collection exists
goToScene(key) → Scene navigation exists
triggerGameOver() → Game over functionality exists
Step 3: Verify Current State
Run application if possible:
# Check if dev server is running
lsof -i :3000 || npm run dev
# Open browser and verify
agent-browser open http://localhost:3000
agent-browser eval"window.__TEST__?.commands"
Check test seams for existing functionality:
# Check available test seam commands
agent-browser eval"Object.keys(window.__TEST__?.commands || {})"
Step 4: Review Progress.txt
Check recent implementations:
# Read progress filecat tasks/progress.txt
# Search for task ID or feature name
grep -i "feature-name\|task-id" tasks/progress.txt
Look for:
Recent implementations of similar features
Completed tasks that might include this functionality
Learnings that mention this feature
Step 4.5: Asset Discovery Workflow
Before generating new assets, check if they already exist.
Observed Issue: Assets generated when they already existed, wasting time and API calls.
Asset Discovery Checklist
Before generating assets, verify:
Check progress.txt for previous generation
# Search progress.txt for asset generation
grep -i "character\|sprite\|tile\|asset" tasks/progress.txt
# Look for specific asset names
grep -i "wizard\|grass\|coin" tasks/progress.txt
List directory for existing assets
# Check common asset directoriesls -la public/assets/sprites/
ls -la assets/sprites/
ls -la src/assets/sprites/
ls -la public/assets/audio/
ls -la assets/audio/
Verify asset file exists
# Check for specific asset filestest -f "public/assets/sprites/character.png" && echo"Exists" || echo"Missing"test -f "assets/sprites/wizard-south.png" && echo"Exists" || echo"Missing"# Check multiple variationsls public/assets/sprites/character*.png
ls assets/sprites/wizard-*.png
// Check for test seam commandsconst testSeamCheck = awaitcodebase_search({
query: "What test seam commands exist for timer functionality?",
target_directories: []
});
// If setTimer command exists, timer feature likely existsif (testSeamCheck.some(r => r.includes("setTimer"))) {
// Verify existing implementationverifyTimerFeature();
}
Pattern 3: Browser Verification
# Verify via browser before coding
agent-browser open http://localhost:3000
agent-browser eval"window.__TEST__?.commands.setTimer"# If command exists, feature exists
Pattern 4: Progress.txt Review
# Check progress for recent implementations
grep -i "timer\|countdown" tasks/progress.txt
# Look for completed tasks
grep -A 10 "US-XXX" tasks/progress.txt | grep -i "complete\|done"
