/ralph-specum-implement

name: ralph-specum-implement
description: This skill should be used only when the user explicitly asks to use `$ralph-specum-implement`, or explicitly asks Ralph Specum in Codex to run implementation for approved tasks, quick mode, or an explicit continue request.
metadata:
  surface: helper
  action: implement

Ralph Specum Implement

You are a **coordinator, not an executor** -- delegate each task to a `spec-executor` sub-agent.

Contract

• Resolve the active spec by explicit path, exact name, or `.current-spec`
• Require `tasks.md`
• Recompute task counts from disk before execution
• Merge state fields only
• Reconcile prototype records before dispatch and block only dependent work
• Remove `.ralph-state.json` only when all tasks are complete, verified, and `activePrototypes` is empty

Action

1. Resolve the active spec. If none exists, stop. 2. Require `tasks.md`. Read `.progress.md`, current state, and current task markers. 3. Parse `tasks.md` once into ordered top-level task rows. Include only unindented checkboxes outside fenced example blocks whose next token is a concrete numeric task ID, `V<number>`, `VE<number>`, or `VF`; exclude nested and example checkboxes, completion criteria, and placeholder IDs. From that one list derive `total`, the completed count across all rows, and `next_index` as the zero-based position of the first incomplete row or `total` when none remains. Do not derive `next_index` from the completed count; non-prefix completion cases resume at the earliest incomplete row. 4. Resolve the dispatch task index before merging state. For fresh execution, use `next_index`. For a prototype return, require a validated non-negative `returnTaskIndex` and verify that it identifies the first eligible incomplete task. Merge state once with:

• `phase: "execution"`
• `awaitingApproval: false`
• `totalTasks: total`
• taskIndex: `next_index` for fresh execution, or the validated `returnTaskIndex` for a prototype return
• preserve `taskIteration`, `maxTaskIterations`, `globalIteration`, `maxGlobalIterations`, `commitSpec`, and `relatedSpecs`

5. Before dispatch, run `prototype_records.py reconcile` whenever state exists and run `select-downstream` whenever `activePrototypes` is nonempty or prototype history exists. Request `--target execution`, `--target "task:$TASK_INDEX"`, and `--path` for every declared current-task path. Stop when an active blocker or stale input targets the work, or when any matching `targetDecisions` entry is not both `proofAvailable: true` and `eligible: true`. Missing dependency or approved-transfer proof blocks conservatively. Report the prototype ID and resume active work through `$ralph-specum-prototype --resume <id>`; route terminal staleness to its earliest affected phase or task. 6. On a prototype return, verify that the merged `taskIndex` still equals the validated `returnTaskIndex` and identifies the first eligible incomplete task before dispatch. 7. **Delegate** each task to a `spec-executor` sub-agent. Pass the task description, file targets, success criteria, and context from `.progress.md`. The sub-agent implements the task and outputs `TASK_COMPLETE`. Do NOT implement tasks yourself. Execute tasks in order until complete or blocked. 8. `[P]` tasks may batch only when file sets do not overlap and verification is independent. 9. `[VERIFY]` tasks stay in the same run and must produce explicit verification evidence. 10. Marker syntax must be explicitly present in `tasks.md`. If markers are absent, treat tasks as non-batchable by default. 11. VE tasks are valid quality tasks when the spec includes autonomous end-to-end verification. 12. Native task sync metadata should be preserved when present. 13. After each task or safe batch:

• mark the checkbox
• update `.progress.md`
• merge the state update
• use the task `Commit` line unless commits were explicitly disabled

14. Before any batching, generated-task, CI, review-fix, branch-publication, or PR-lifecycle push, apply the Prototype Evidence Push Gate in `../../references/workflow.md`. Normal mode may ask at that boundary for separate explicit authorization naming every outbound `**/prototypes/*.md` record. Quick mode asks no question and skips every push. A skipped or denied push ends the dependent remote lifecycle path: do not run `gh pr create`, `gh pr merge`, `gh pr checks`, `gh pr view`, `gh api`, `gh run`, `gh issue`, remote review polling, issue writes, or later remote steps that depend on that push. Quick mode continues or finishes locally and reports `Remote lifecycle skipped: prototype evidence stayed local.` Preserve the existing normal remote lifecycle only after the gate completes the push. Never push an isolated prototype source branch. `commitSpec` authorizes local commits only. 15. On failure or interruption, persist the current state and stop with a resumable summary. 16. On full completion, reconcile again. If `activePrototypes` remains nonempty, preserve `.ralph-state.json` and stop with its IDs. Otherwise remove state and report completion.

Resume Rules

• Resume from the persisted task state when execution was already in progress.
• If disk state and task checkboxes disagree, prefer `tasks.md` for completion and repair state to match.
• If approval is still pending for tasks, stop and get approval unless quick mode or explicit user direction says to continue.
• A stale task or dependent active prototype always wins over resume dispatch. An unrelated active prototype does not pause the current task.