ralph-implement

Ralph Implement

Continuous-iteration implementation loop. For each task in a plan, implement the smallest change that addresses it, run the task-level checks, and iterate on failure. Stop cleanly when the budget is exhausted.

When to use

• Executing a task list produced by task-plan
• Migrating a refactor through a sequence of small changes
• Driving any code work where each step has a deterministic pass/fail check

When NOT to use

• Validating a skill against a target repo — use skill-validator
• Pure exploration where no task-level checks are defined
• Tasks already in a CI pipeline that handles iteration

Inputs

• plan_path — path to the task plan (e.g., docs/PRDs/<slug>-plan.md)
• task_checks — per-task command(s) that verify the task is done. Format: <task_id>: <command>.
• budget — max retries per task (default 3) and max minutes per task (default 30). Hard cap.

The loop (per task)

for task in plan.unchecked_tasks():
    retries = 0
    while retries < BUDGET.max_retries:
        implement(task)               # smallest change that addresses the task
        result = run(task_checks[task.id])
        if result.passed:
            invoke `code-reviewer` against the changed files
            if code-reviewer returns no Critical: mark_complete(task)
            else: log and retry with code-reviewer findings as input
            break
        retries += 1
        if same_failure_mode_as_last_retry(result):
            invoke `debugger` for reproduction-first investigation
            if debugger surfaces a root cause: apply the minimal fix and retry once
            else: invoke `five-whys` and stop_task()
    else:
        stop_task() and escalate(task)

The two agents the loop calls

The loop above names these at the two points that matter. Both are gates, not commentary.

code-reviewer — on every task whose check just passed, before it is marked done

A Critical finding sends the task back into the loop with the findings as input. The task check is a gate; it is not the only gate.