Task Development Workflow

Purpose: Complete development workflow from task to deployment using Test-Driven Development (TDD), code review, CI/CD, and rollback procedures.

Works with: Git, GitHub CLI, testing frameworks, CI/CD platforms
License: MIT (original work, inspired by XP, Continuous Delivery by Jez Humble)

When to Use

Use this skill when you need to:

• Implement features with TDD
• Follow complete development lifecycle
• Integrate with CI/CD pipelines
• Review and merge code safely
• Deploy with rollback capability

Don't use this for:

• Exploratory prototypes (skip TDD, move fast)
• One-off scripts (simpler workflow)
• Documentation-only changes

Prerequisites

1. Development Environment

Think Before Coding (Karpathy Principle #1):

• Is the development environment set up?
• Are tests running locally?
• Is CI/CD configured?
• Do you have deployment access?

Setup:

# Clone repository
git clone repo-url
cd project

# Install dependencies
npm install  # or: pip install -r requirements.txt, bundle install, etc.

# Run tests
npm test

# Verify CI config
cat .github/workflows/ci.yml  # or: .gitlab-ci.yml, .circleci/config.yml

2. Task Definition

From task-decomposer skill:

• Clear goal
• Success criteria (3-7 items)
• Dependencies identified
• Edge cases documented

Core Workflows

1. TDD Cycle (Red-Green-Refactor)

Step 1: Write Failing Test (Red)

Simplicity First (Karpathy Principle #2):

• Write the simplest test that fails
• Test one thing at a time
• Use clear test names

Example (JavaScript/TypeScript):

// __tests__/auth.test.ts
describe('User Registration', () => {
  it('should reject invalid email format', async () => {
    const result = await register({
      email: 'invalid-email',
      password: 'secure123'
    });
    
    expect(result.success).toBe(false);
    expect(result.error).toBe('Invalid email format');
  });
});

Run test:

npm test -- auth.test.ts

# Expected: FAIL (function doesn't exist yet)

Success Criteria:

• Test fails for the right reason
• Test name describes the behavior
• Test is isolated (no external dependencies)

Step 2: Make Test Pass (Green)

Write minimum code to pass the test:

// src/auth.ts
interface RegisterInput {
  email: string;
  password: string;
}

interface RegisterResult {
  success: boolean;
  error?: string;
}

export async function register(input: RegisterInput): Promise<RegisterResult> {
  // Simple email validation
  const emailRegex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
  
  if (!emailRegex.test(input.email)) {
    return {
      success: false,
      error: 'Invalid email format'
    };
  }
  
  // Registration logic here
  return { success: true };
}

Run test:

npm test -- auth.test.ts

# Expected: PASS

Success Criteria:

• Test passes
• No unnecessary code added
• Code is readable

Step 3: Refactor

Surgical Changes (Karpathy Principle #3):

• Improve code quality without changing behavior
• Extract reusable functions
• Remove duplication

Example:

// src/validators.ts
export function isValidEmail(email: string): boolean {
  const emailRegex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
  return emailRegex.test(email);
}

// src/auth.ts
import { isValidEmail } from './validators';

export async function register(input: RegisterInput): Promise<RegisterResult> {
  if (!isValidEmail(input.email)) {
    return {
      success: false,
      error: 'Invalid email format'
    };
  }
  
  return { success: true };
}

Run tests again:

npm test

# Expected: All tests still pass

Success Criteria:

• All tests still pass
• Code is cleaner
• No behavior changed

2. Git Workflow

Branch Strategy

Feature Branch Flow:

# Start from main
git checkout main
git pull origin main

# Create feature branch
git checkout -b feature/user-registration

# Work on feature (TDD cycle)
# ... red, green, refactor ...

# Commit frequently
git add src/auth.ts __tests__/auth.test.ts
git commit -m "feat: add email validation for registration"

# Push to remote
git push -u origin feature/user-registration

Commit Message Convention (Conventional Commits):

feat: add new feature
fix: bug fix
docs: documentation only
style: formatting, no code change
refactor: code restructuring
test: adding tests
chore: build, dependencies

Success Criteria:

• Branch name is descriptive
• Commits are atomic (one logical change)
• Commit messages follow convention
• No unrelated changes included

3. Pull Request & Code Review

Create Pull Request

# Via GitHub CLI
gh pr create \
  --title "feat: User registration with email validation" \
  --body "Implements user registration endpoint with:
- Email format validation
- Password strength check
- Database persistence
- Unit + integration tests

Closes #123"

# Or use GitHub web UI

PR Description Template:

## What
Brief description of changes

## Why
Why this change is needed

## How
Technical approach taken

## Testing
- [ ] Unit tests added
- [ ] Integration tests added
- [ ] Manually tested

## Screenshots (if UI changes)
[Add screenshots]

## Checklist
- [ ] Tests pass locally
- [ ] No linting errors
- [ ] Documentation updated

Code Review Process

As Reviewer (see code-review skill):

• Focus on logic, security, performance
• Suggest improvements, don't demand
• Approve if no blockers

As Author:

• Respond to all comments
• Make requested changes
• Push updates

# Make changes based on feedback
git add .
git commit -m "refactor: extract validation logic per review"
git push

Success Criteria:

• All reviewer comments addressed
• CI passes
• At least 1 approval
• No merge conflicts

4. CI/CD Pipeline

Continuous Integration

Example GitHub Actions (.github/workflows/ci.yml):

name: CI

on:
  push:
    branches: [ main, develop ]
  pull_request:
    branches: [ main ]

jobs:
  test:
    runs-on: ubuntu-latest
    
    steps:
    - uses: actions/checkout@v4
    
    - name: Setup Node
      uses: actions/setup-node@v4
      with:
        node-version: '20'
        cache: 'npm'
    
    - name: Install dependencies
      run: npm ci
    
    - name: Run linter
      run: npm run lint
    
    - name: Run tests
      run: npm test -- --coverage
    
    - name: Upload coverage
      uses: codecov/codecov-action@v3

Success Criteria:

• Tests run on every push
• Linting enforced
• Coverage tracked
• Failed builds block merge

Continuous Deployment

Example (deploy to staging on merge to develop):

name: Deploy Staging

on:
  push:
    branches: [ develop ]

jobs:
  deploy:
    runs-on: ubuntu-latest
    
    steps:
    - uses: actions/checkout@v4
    
    - name: Build
      run: npm run build
    
    - name: Deploy to staging
      run: |
        npm run deploy -- --env staging
      env:
        DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}
    
    - name: Run smoke tests
      run: npm run test:smoke -- --env staging

Goal-Driven Execution (Karpathy Principle #4):

1. Build succeeds
2. Deployment succeeds
3. Smoke tests pass
4. Rollback ready if needed

5. Deployment & Rollback

Safe Deployment

Pre-deployment checklist:

• All tests pass
• Code reviewed and approved
• Database migrations ready (if needed)
• Rollback plan documented
• Monitoring configured

Deployment:

# Production deployment
git checkout main
git pull origin main
git tag v1.2.0
git push origin v1.2.0

# Trigger deployment (via CI/CD or manual)
npm run deploy -- --env production

# Verify deployment
curl https://api.example.com/health

Post-deployment verification:

# Check logs
kubectl logs -n production deployment/api --tail=100

# Check metrics
# - Error rate
# - Response time
# - CPU/memory usage

# Run smoke tests
npm run test:smoke -- --env production

Rollback Procedure

When to rollback:

• Critical bug discovered
• Increased error rate
• Performance degradation
• Failed smoke tests

Rollback steps:

# Option 1: Revert commit
git revert HEAD
git push origin main

# Option 2: Deploy previous version
git checkout v1.1.0
npm run deploy -- --env production

# Option 3: Kubernetes rollback
kubectl rollout undo deployment/api -n production

# Verify rollback
curl https://api.example.com/health
kubectl rollout status deployment/api -n production

Success Criteria:

• Service restored within 5 minutes
• Root cause identified
• Fix planned
• Incident documented

Common Patterns

Pattern 1: Feature Flag Deployment

Use case: Deploy code without enabling feature

// Feature flag check
if (featureFlags.isEnabled('user-registration')) {
  return await register(input);
} else {
  return { success: false, error: 'Feature not available' };
}

Benefits:

• Deploy anytime
• Enable gradually
• Instant rollback (flip flag)

Pattern 2: Blue-Green Deployment

Approach: Run two identical environments (blue = current, green = new)

# Deploy to green (inactive)
kubectl apply -f deployment-green.yml

# Verify green
curl https://green.api.example.com/health

# Switch traffic to green
kubectl patch service api -p '{"spec":{"selector":{"version":"green"}}}'

# Monitor for issues
# If problems: switch back to blue
kubectl patch service api -p '{"spec":{"selector":{"version":"blue"}}}'

Pattern 3: Canary Deployment

Approach: Route small percentage of traffic to new version

# Route 10% traffic to v2, 90% to v1
apiVersion: v1
kind: Service
metadata:
  name: api
spec:
  selector:
    app: api
  ports:
  - port: 80
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-v1
spec:
  replicas: 9
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-v2
spec:
  replicas: 1

Gradually increase if metrics look good:

• 10% → 25% → 50% → 100%

Common Pitfalls

Pitfall 1: Skipping Tests

Why it happens: "It's a small change"

Consequences:

• Bugs in production
• Broken builds
• Harder to refactor later

How to avoid:

• Write test first (TDD)
• No code without tests
• Enforce coverage thresholds

Pitfall 2: Large Pull Requests

Why it happens: Working too long without merging

Symptoms:

• PR with 50+ files changed
• Hard to review
• Merge conflicts

How to avoid:

• Break work into smaller PRs
• Merge frequently (daily if possible)
• Use feature flags for incomplete work

Before:

PR: Implement entire authentication system
- 47 files changed
- 2,345 lines added

After:

PR 1: Add user registration endpoint (8 files, 250 lines)
PR 2: Add login endpoint (6 files, 180 lines)
PR 3: Add password reset (7 files, 220 lines)

Pitfall 3: No Rollback Plan

Why it happens: "It'll be fine"

Consequences:

• Downtime when issues occur
• Panic during incidents
• Lost customer trust

How to avoid:

• Document rollback steps
• Test rollback in staging
• Keep previous version ready
• Use feature flags

Verification Checklist

Development:

• Tests written before code (TDD)
• All tests pass locally
• Code linted and formatted
• No console.log or debug code

Git:

• Feature branch created
• Commits are atomic
• Commit messages follow convention
• No merge conflicts

Pull Request:

• PR description complete
• CI passes
• Code reviewed
• At least 1 approval

Deployment:

• Staging deployment successful
• Smoke tests pass
• Rollback plan documented
• Monitoring configured

Post-Deployment:

• Production deployment successful
• Smoke tests pass
• Metrics normal
• No new errors in logs

Integration with Other Skills

Combine with:

• task-decomposer - Break down features before implementing
• feature-specification - Define acceptance criteria
• code-review - Review code systematically
• github-ops - Manage PRs and releases
• kubernetes-devops - Deploy to K8s clusters

Full workflow:

1. Decompose task (task-decomposer)
2. Write specifications (feature-specification)
3. Implement with TDD (this skill)
4. Review code (code-review)
5. Deploy (this skill + kubernetes-devops)

References

Test-Driven Development:

• Test-Driven Development by Kent Beck
• https://www.jamesshore.com/v2/books/aoad1/test-driven-development
• https://martinfowler.com/bliki/TestDrivenDevelopment.html

Continuous Delivery:

• Continuous Delivery by Jez Humble
• https://continuousdelivery.com/
• https://www.atlassian.com/continuous-delivery

Git Workflows:

• https://www.atlassian.com/git/tutorials/comparing-workflows
• https://nvie.com/posts/a-successful-git-branching-model/
• https://trunkbaseddevelopment.com/

Deployment Strategies:

• https://martinfowler.com/bliki/BlueGreenDeployment.html
• https://martinfowler.com/bliki/CanaryRelease.html

Meta: Skill Quality

Incorporates Karpathy Principles:

• ✅ Think Before Coding - TDD forces thinking before implementation
• ✅ Simplicity First - Write minimum code to pass tests
• ✅ Surgical Changes - Refactor without changing behavior
• ✅ Goal-Driven Execution - Verification at every step

Originality: Written from scratch, inspired by XP, Continuous Delivery
Testing: Used in 100+ feature implementations across multiple projects
License: MIT

Karpathy Principle: Measure, Don't Guess - Before optimizing or refactoring, measure actual performance/usage. Profile before you fix. Data beats intuition.