Problem Statement
When execution fails, the rescue mechanism creates a draft PR with partial progress. However,
retrying requires /approve which restarts from scratch — wasting turns on already-completed
steps and risking conflicts with existing commits.
Proposed Solution
Add a /retry command that:
- Checks out the existing branch from the failed execution
- Parses completed steps from git commit history (
step N: pattern)
- Resumes execution from the next incomplete step
Technical Approach
New files:
src/prompts/retry.ts — Retry prompt builder
Files to modify:
src/types.ts — Add "retry" to LeonidasModesrc/main.ts — Add handleRetryMode(), extend isValidLeonidasMode()src/github.ts — Add getCompletedSteps(branchName, baseBranch) using octokit.rest.repos.compareCommits()src/i18n.ts — Add keys: retry_starting, retry_no_branch, retry_no_stepssrc/comment_builder.ts — Handle retry mode in buildFailureComment()src/post_process_cli.ts — Extend mode validation in runPostFailure()
Dynamic turn budget:
const MIN_RETRY_TURNS = 15;
const proportionalTurns = Math.ceil((remainingSteps / totalSteps) * maxTurns);
const retryMaxTurns = Math.min(
Math.max(proportionalTurns, MIN_RETRY_TURNS),
maxTurns,
);
Retry prompt structure:
- Include original plan comment (wrapped with
wrapUserContent())
- List already-completed step commits
- Instruct:
git fetch origin {branch} && git checkout {branch}
- Continue from next step, following standard execute mode flow
/retry + /revise interaction:
/retry always reads the current (latest) plan comment. If user runs /revise after failure
then /retry, the revised plan is used — this is intentional.
Error handling:
| Scenario |
Action |
| Branch not on remote |
Comment: "Cannot retry — no branch from previous execution" + core.setFailed() |
| No step commits found |
Comment: "No completed steps found. Use /approve instead." + core.setFailed() |
| No plan comment |
Comment: "No plan found. Add leonidas label first." + core.setFailed() |
| Conflict with base |
Warning comment, proceed (Claude attempts resolution) |
Cross-cutting changes (shared with A1):
action.yml: retry uses same composite steps as execute (post-completion, rescue, post-process-pr, trigger-ci)- Workflow YAML: Already extended in A1 to match
/retry
Depends on: #250 (A1: /revise — shares workflow trigger changes)
Benefits from: #251 (A2: Progress Tracking — helps identify failure point)
Acceptance Criteria
Problem Statement
When execution fails, the rescue mechanism creates a draft PR with partial progress. However,
retrying requires
/approvewhich restarts from scratch — wasting turns on already-completedsteps and risking conflicts with existing commits.
Proposed Solution
Add a
/retrycommand that:step N:pattern)Technical Approach
New files:
src/prompts/retry.ts— Retry prompt builderFiles to modify:
src/types.ts— Add"retry"toLeonidasModesrc/main.ts— AddhandleRetryMode(), extendisValidLeonidasMode()src/github.ts— AddgetCompletedSteps(branchName, baseBranch)usingoctokit.rest.repos.compareCommits()src/i18n.ts— Add keys:retry_starting,retry_no_branch,retry_no_stepssrc/comment_builder.ts— Handle retry mode inbuildFailureComment()src/post_process_cli.ts— Extend mode validation inrunPostFailure()Dynamic turn budget:
Retry prompt structure:
wrapUserContent())git fetch origin {branch} && git checkout {branch}/retry + /revise interaction:
/retryalways reads the current (latest) plan comment. If user runs/reviseafter failurethen
/retry, the revised plan is used — this is intentional.Error handling:
core.setFailed()/approveinstead." +core.setFailed()leonidaslabel first." +core.setFailed()Cross-cutting changes (shared with A1):
action.yml: retry uses same composite steps as execute (post-completion, rescue, post-process-pr, trigger-ci)/retryDepends on: #250 (A1: /revise — shares workflow trigger changes)
Benefits from: #251 (A2: Progress Tracking — helps identify failure point)
Acceptance Criteria
/retryresumes execution from the last completed stepwrapUserContent()handleRetryMode(),getCompletedSteps(), retry prompt builder, all error scenarios