Task Execution Module Skill

A Claude Code skill for structuring and executing complex multi-step development tasks — breaking work into phases, managing dependencies between steps, handling failures, and tracking progress through completion.

When to Use This Skill

Choose this skill when:

• Executing multi-file refactoring across a large codebase
• Running complex build, test, and deploy sequences
• Managing tasks with dependencies (step B requires step A's output)
• Automating development workflows with error handling
• Breaking down large features into trackable execution steps

Consider alternatives when:

• You need task planning without execution (use a planning skill)
• You need CI/CD pipeline automation (use a CI skill)
• You need simple one-step operations (just do them directly)

Quick Start

Copy
# Add to your Claude Code project
claude mcp add executing-module

# Execute a complex task with progress tracking
claude "execute the database migration plan: backup, migrate, verify, and rollback if failed"

Copy
# .claude/skills/executing-module.yml
name: executing-module
description: Execute multi-step development tasks with dependency management
triggers:
  - "execute plan"
  - "run workflow"
  - "step by step"
config:
  progress_tracking: true
  stop_on_failure: true
  rollback_enabled: true

Core Concepts

Execution Phases

Phase	Purpose	Output
Planning	Break task into ordered steps	Step list with dependencies
Validation	Check prerequisites for each step	Ready/blocked status
Execution	Run steps in dependency order	Results per step
Verification	Confirm each step succeeded	Pass/fail per step
Recovery	Handle failures and rollbacks	Recovered state
Reporting	Summarize execution results	Completion report

Execution Patterns

Copy
// Sequential execution with rollback
interface ExecutionStep {
  name: string;
  execute: () => Promise<StepResult>;
  verify: () => Promise<boolean>;
  rollback?: () => Promise<void>;
  dependsOn?: string[];
}

async function executeWorkflow(steps: ExecutionStep[]): Promise<WorkflowResult> {
  const completed: ExecutionStep[] = [];

  for (const step of steps) {
    console.log(`Executing: ${step.name}`);
    try {
      const result = await step.execute();
      const verified = await step.verify();

      if (!verified) {
        throw new Error(`Verification failed for ${step.name}`);
      }

      completed.push(step);
    } catch (error) {
      console.error(`Failed: ${step.name}`, error);

      // Rollback completed steps in reverse
      for (const done of completed.reverse()) {
        if (done.rollback) await done.rollback();
      }

      return { success: false, failedStep: step.name, error };
    }
  }

  return { success: true, completedSteps: completed.length };
}

Progress Tracking

Copy
## Execution Progress

| Step | Status | Duration | Notes |
|------|--------|----------|-------|
| 1. Backup database | ✅ Complete | 12s | Backup: backup_20260313.sql |
| 2. Run migrations | ✅ Complete | 8s | Applied 3 migrations |
| 3. Verify schema | ✅ Complete | 2s | All tables verified |
| 4. Run smoke tests | 🔄 Running | - | 5/12 tests passed |
| 5. Update configs | ⏳ Pending | - | Blocked by step 4 |
| 6. Notify team | ⏳ Pending | - | Blocked by step 5 |

Configuration

Parameter	Type	Default	Description
progress_tracking	boolean	true	Show real-time progress updates
stop_on_failure	boolean	true	Stop execution when a step fails
rollback_enabled	boolean	true	Auto-rollback completed steps on failure
parallel_enabled	boolean	false	Execute independent steps in parallel
timeout_per_step	number	300	Maximum seconds per step
retry_failed	boolean	false	Retry failed steps once before giving up
report_format	string	"markdown"	Progress report format: markdown, json

Best Practices

1. Define verification criteria for every step — each step should have a clear "done" condition that can be checked programmatically; without verification, you don't know if a step actually succeeded.

2. Implement rollback for destructive steps — any step that modifies data or state should have a corresponding rollback function; this ensures failures don't leave the system in a broken state.

3. Track progress visually — show a running status table that updates as each step completes; visibility into progress helps identify where issues occur and how far execution got.

4. Handle dependencies explicitly — if step B depends on step A's output, make that dependency explicit in the step definition rather than relying on execution order alone.

5. Set timeouts for every step — unbounded operations can hang forever; set reasonable timeouts and treat timeout as a failure that triggers rollback.

Common Issues

Steps succeed but verification fails — The operation completed but the result doesn't match expectations. This often indicates a race condition or timing issue. Add a brief delay between execution and verification, or use polling with a timeout.

Rollback leaves partial state — Rollback functions need to be idempotent — safe to run multiple times. If rollback itself fails, log the state clearly so manual recovery is possible.

Parallel execution causes conflicts — Steps that seem independent may share resources (database connections, file locks). Start with sequential execution and only parallelize after confirming no resource conflicts.