edd-do

EDD-Do

Purpose

Apply exactly one planned refinement action to a target skill and/or its evaluation suite. Make only the change described in the plan.

No shell commands. Do not run shell commands (exec, git, npm, etc.) — every needed check is either a file edit or a re-read. The workflow runs validation (scope checks, the full evaluation) deterministically after this skill completes.

Prerequisites

• iterations/<n>/plan.json exists and names an authorized action, intended_files, and expected_effect.
• The target repository worktree has no stray edits from a previous, not-yet-committed-or-reverted attempt.
• If action is propose_evaluation_expectation_change, approval has already been recorded for this exact proposal. If it has not, STOP and report this to chat instead of proceeding — never apply an unapproved expectation change.

Workflow Steps

Step 1: Read the Plan

Read iterations/<n>/plan.json:
- action
- intended_files
- rationale
- expected_effect
- iteration_start_baseline

Read refinement.yaml's latest section for full narrative context and any
"changes made" notes left by a prior, related iteration.

Step 2: Load Skill and Eval Context

Read the target skill's SKILL.md / prompt and any supporting documents
named in intended_files.

If the change touches promptfooconfig.yaml, test YAML, custom
assertion/transform JS, or fixtures:
  → Consult the `promptfoo` skill FIRST.
  → Use its phase map to jump to the specific section needed
  instead of guessing at syntax or option names.

Step 3: Make the Minimal Change

Modify ONLY the files listed in intended_files.

By action type:

- refine_skill:
    Edit only the prompt/instruction sections implicated by the
    failure evidence in the plan. Do not rewrite unrelated sections.

- repair:
    Fix the fixture/assertion/helper defect without lowering the bar
    the evaluation is meant to enforce. Prefer fixing an internally
    inconsistent fixture over relaxing an assertion. If the true cause
    is a helper bug (e.g. `||` treating `0` as falsy), fix the helper,
    not the test data.

- add_coverage:
    Add the missing required test case(s). Prefer an existing,
    already-rich fixture over authoring a new one; follow the target
    skill's own fixture-naming and YAML-block conventions (copy an
    existing block, change only what differs).

- refine_supporting_docs:
    Edit only the referenced/example/template document(s) named in
    intended_files.

- propose_evaluation_expectation_change:
    Change only the approved expectation, exactly as approved. Adhere to the approved diff, other changes are forbidden

- Editing a file not listed in intended_files IS FORBIDDEN  
- Refactoring, renaming, or "improving" anything the plan did not ask for IS FORBIDDEN
- Weakening an expectation to make a failure disappear instead of
  fixing the underlying fixture, helper, or skill behavior IS FORBIDDEN