Skill 4 Code Continuator

Skill 4 Code Continuator

Use this workflow when the source of truth is an existing task list rather than a freshly stated feature request. The operating contract is: discover the relevant task source, choose the next actionable coding task, complete a small validated slice, and update the task record without rewriting unrelated notes.

Task Source Discovery

Start in the directory the user named. If no directory is named, start in the current workspace.

Look for task sources in this order:

1. Explicit file or directory named by the user.
2. Ralph TUI state under .ralph-tui/, especially progress.md, session metadata, reports, and iteration logs.
3. Markdown task files such as TODO.md, TASKS.md, ROADMAP.md, PLAN.md, PROGRESS.md, README.md, and docs containing checkboxes.
4. Other nearby plain-text project notes that clearly contain pending implementation tasks.

Use rg or find to locate likely files. Prefer focused searches such as TODO, FIXME, - [ ], - [x], Status:, Blocked, Next, Task, and Acceptance.

Do not treat incidental code comments as the controlling task list unless no explicit project task source exists or the user asked for code TODOs.

Reading Task State

Parse task state conservatively:

• Pending: unchecked checkbox, TODO, Pending, Next, Open, or equivalent.
• In progress: In Progress, Active, a partially completed section, or recent ralph-tui iteration context.
• Done: checked checkbox, Done, Complete, Completed, or equivalent.
• Blocked: Blocked, waiting on external access, missing credentials, missing hardware, unresolved product decision, or repeated validation failure.

For ralph-tui, treat .ralph-tui/progress.md as continuity notes and inspect session-meta.json, recent iterations/*.log, and recent reports/*.txt only as needed to identify the current or next task. Preserve ralph-tui generated structure and avoid fabricating metadata fields.

If multiple plausible task sources disagree, prefer the one most directly named by the user. If none was named, prefer the most specific local task list over broad repository docs.

Choosing Work

Choose one coherent task slice:

• Continue an explicit in-progress task first.
• Otherwise choose the first unblocked pending task in the controlling task source.
• Prefer tasks with concrete acceptance criteria over vague cleanup.
• Skip blocked tasks after recording why they remain blocked.
• Ask the user only when two choices would lead to meaningfully different product outcomes.

Before editing code, derive a short internal contract:

• Task selected.
• Expected observable behavior.
• Files or runtime paths likely involved.
• Validation needed.
• Task record update expected at the end.

Implementation Rules

Use the same engineering discipline as autonomous coding work:

• Inspect relevant code before changing it.
• Check worktree status before edits when inside a git repo.
• Treat unrelated dirty files as user-owned.
• Make the smallest complete change that satisfies the selected task.
• Validate with the relevant build, test, runtime check, or focused harness.
• Treat failed validation as a signal to fix or mark blocked with evidence.
• Do not claim completion from static reasoning when the task depends on runtime behavior.

If the selected task expands into several independent changes, finish one validated slice and update the task list with what remains.

Updating Task Records

After implementation and validation, update only the relevant task source:

• Mark the completed item done when acceptance criteria are met.
• Add a short completion note with the validation performed.
• If blocked, mark or annotate the item as blocked with the concrete reason and the next required input.
• If partially complete, leave it pending or in progress and add a concise note about what was finished and what remains.
• Preserve surrounding wording, ordering, and author notes.
• Avoid broad reformatting of Markdown or ralph-tui files.

For Markdown checklists, prefer minimal checkbox edits:

- [x] Add focused parser coverage. Done: `pytest tests/test_parser.py` passed.
- [ ] Add CLI flag docs. Remaining: update README examples.

For ralph-tui files, prefer appending concise continuity notes to progress.md unless the format clearly provides a better task-status location. Do not edit logs or reports except when the user explicitly asks.

Reporting

In the final response, include:

• Which task source was used.
• Which task was selected.
• What changed.
• What validation passed or could not be run.
• How the task record was updated.
• The commit hash if the user asked for commits and a commit was made.

Keep the report concise. If more pending tasks remain, mention the next one only when it is useful context.