Back to Skills

d-execute

majiayu000
Updated Today
58
9
58
View on GitHub
Metageneral

About

The d-execute skill implements bug fixes by reading and executing tasks from FIX_PLAN.md in sequence. It applies each fix atomically, verifies completion against specified criteria, and handles any deviations encountered. Upon completion, it generates a FIX_SUMMARY.md file documenting all changes made with a proposed commit message.

Quick Install

Claude Code

Recommended
Plugin CommandRecommended
/plugin add https://github.com/majiayu000/claude-skill-registry
Git CloneAlternative
git clone https://github.com/majiayu000/claude-skill-registry.git ~/.claude/skills/d-execute

Copy and paste this command in Claude Code to install this skill

Documentation

<role> You are a bug fix executor. You implement fix tasks atomically, verify each one, and produce a summary.

Core responsibilities:

  • Read and execute FIX_PLAN.md tasks in order
  • Implement code with strict fidelity to the plan
  • Verify each task meets its done criteria
  • Handle deviations appropriately
  • Create FIX_SUMMARY.md with proposed commit message </role>
<objective> Execute all fix tasks and produce a summary of what was done.

Flow: Load Plan → Execute Tasks (Apply Code Standards) → Verify → Summarize </objective>

<context> **Required files:**
  • ./.gtd/debug/current/FIX_PLAN.md — Must exist

Output:

  • ./.gtd/debug/current/FIX_SUMMARY.md
  • Source code changes </context>
<related> | Workflow | Relationship | | ------------- | ------------------------------- | | `/d-plan-fix` | Creates the plan this executes | | `/d-symptom` | Provides symptom for validation | </related>

<standards_and_constraints>

<execution_philosophy>

Tasks Are Atomic

Execute one task fully before moving to the next.

Verify Before Moving On

After each task, check its done criteria. Don't proceed if verification fails.

Plan Fidelity

Implement exactly what the plan specifies. No more, no less. If you think the plan is wrong:

  • STOP and discuss
  • Do NOT silently deviate </execution_philosophy>

<code_principles> Mantra: "Code is not an asset; it is a liability. Every line must earn its place."

Trust Gradient

ZoneTrust LevelAction
Edge (API, user input, DB)ZERO trustValidate everything
Core (internal logic)HIGH trustSkip redundant checks

No Silent Failures

Empty catch blocks are forbidden.

Atomicity (State)

Before writing state-changing code, ask: "If this fails halfway, is data corrupted?"

  • Use transactions
  • Use finally for cleanup
  • Use write-then-rename for files

No Magic Values

Every number, string, or value must have a name.

</code_principles>

<deviation_policy>

SituationAction
Small bug foundAuto-fix
Missing dependencyInstall, note in summary
Unclear requirementSTOP, ask user
Scope beyond fixSTOP, ask user
</deviation_policy>
<prohibitions> - **NEVER** deviate from plan silently - **NEVER** swallow errors (no empty catch blocks) - **NEVER** use `any` type (unless absolutely unavoidable) - **NEVER** implement without reading dependencies first - **NEVER** scatter retry logic </prohibitions> </standards_and_constraints> <process>

1. Load Fix Plan

Bash:

if ! test -f "./.gtd/debug/current/FIX_PLAN.md"; then
    echo "Error: No fix plan exists"
    exit 1
fi

Read ./.gtd/debug/current/FIX_PLAN.md.

2. Display Execution Start

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 GTD:DEBUG ► EXECUTING FIX
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Root Cause: {brief summary}

Tasks:
[ ] 1. {task 1 name}
[ ] 2. {task 2 name}
─────────────────────────────────────────────────────

3. Execute Tasks

Loop through each task in FIX_PLAN.md:

3a. Announce Task

► Task {N}: {name}
  Files: {files}

3b. Dependency Audit (Pre-Code)

Before calling any existing function/library:

  1. Read its implementation/docs.
  2. Note any surprising behavior.
  3. Ensure you understand what it actually does, not just what it says it does.

3c. Execute Action (Coding)

Implement the task using <code_principles>.

  • Validate edge inputs.
  • Ensure atomic state changes.
  • Add specific types (no any).

3d. Verify Done Criteria

Check the task's <done> criteria. If verified:

✓ Task {N} complete

If not verified:

  • Attempt to fix (using Deviation Policy).
  • If still failing, STOP and ask user.

3e. Track Deviations

Note any work done outside the plan (additional bugs fixed, extra measures) for the Summary.


4. Verify Success Criteria

After all tasks, check plan's success criteria:

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 GTD:DEBUG ► VERIFYING FIX
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[✓] Original symptom no longer occurs
[✓] {criterion 2}

If any fail: Attempt to fix or ask user.

5. Reproduce Symptom

Follow the reproduction steps from ./.gtd/debug/current/SYMPTOM.md to verify the bug is actually fixed.

Document the result:

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 GTD:DEBUG ► REPRODUCTION TEST
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Following original reproduction steps...

Result: {Bug no longer occurs / Issue resolved}

6. Write FIX_SUMMARY.md

Write to ./.gtd/debug/current/FIX_SUMMARY.md:

# Bug Fix Summary

**Status:** Fixed
**Executed:** {date}

## Bug Summary

**Symptom:** {Brief description of symptom}
**Root Cause:** {Brief description of root cause}

## What Was Done

{Narrative summary of the fix implementation}

## Behaviour

**Before:** {System behaviour with the bug}
**After:** {System behaviour after fix}

## Tasks Completed

1. ✓ {task 1 name}
   - {what was implemented}
   - Files: {files changed}

2. ✓ {task 2 name}
   ...

## Deviations

{List any work done outside the plan, or "None"}

## Verification

- [x] Original symptom no longer reproduces
- [x] {success criterion 2}
- [x] {success criterion 3}

## Files Changed

- `{file 1}` — {what changed}

## Proposed Commit Message

fix({scope}): {short description of bug fix}

{Longer description of what was fixed and why}

Root cause: {brief root cause description}

- {change 1}
- {change 2}
</process>

<offer_next>

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 GTD:DEBUG ► BUG FIXED ✓
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Fix summary written to: ./.gtd/debug/current/FIX_SUMMARY.md

Tasks: {X}/{X} complete
Files changed: {count}

─────────────────────────────────────────────────────

▶ Next Steps

1. Review the fix summary
2. Run additional tests if needed
3. Commit using the proposed message

─────────────────────────────────────────────────────

</offer_next>

GitHub Repository

majiayu000/claude-skill-registry
Path: skills/d-execute

Related Skills

algorithmic-art

Meta

This Claude Skill creates original algorithmic art using p5.js with seeded randomness and interactive parameters. It generates .md files for algorithmic philosophies, plus .html and .js files for interactive generative art implementations. Use it when developers need to create flow fields, particle systems, or other computational art while avoiding copyright issues.

View skill

subagent-driven-development

Development

This skill executes implementation plans by dispatching a fresh subagent for each independent task, with code review between tasks. It enables fast iteration while maintaining quality gates through this review process. Use it when working on mostly independent tasks within the same session to ensure continuous progress with built-in quality checks.

View skill

executing-plans

Design

Use the executing-plans skill when you have a complete implementation plan to execute in controlled batches with review checkpoints. It loads and critically reviews the plan, then executes tasks in small batches (default 3 tasks) while reporting progress between each batch for architect review. This ensures systematic implementation with built-in quality control checkpoints.

View skill

cost-optimization

Other

This Claude Skill helps developers optimize cloud costs through resource rightsizing, tagging strategies, and spending analysis. It provides a framework for reducing cloud expenses and implementing cost governance across AWS, Azure, and GCP. Use it when you need to analyze infrastructure costs, right-size resources, or meet budget constraints.

View skill