Todo Checklist

This is a Hermes-native todo-checklist workflow skill.

Why This Exists

todo-checklist exists because omh_todo is registered on every session while nothing in the skill surface named it: a user who wanted a plan checklist searched for one and found no skill on the subject. The delivery engines declare a checklist as part of starting work, which serves someone running an engine and nobody else.

Do Not Use When

• The work is one step, already finished, or answerable in this turn; a checklist that never advances is a panel of noise.
• The user wants an accepted implementation plan split into parallel lanes with owners and verification commands; use ultrawork.
• The user wants the planning content itself -- options, risks, acceptance criteria before execution; use ralplan.
• The user is asking what coding work is running right now rather than what the plan says; use running-work-board.

Examples

Good example:

• Prompt: declare a plan checklist for this migration so I can see where you are
• Expected behavior: Declare numbered phases in delivery order with one task per observable outcome, exactly one active, and update states as work completes.
• Why: The user wants the HUD checklist itself, for work that spans turns, without starting a delivery engine.

Bad example:

• Prompt: add a TODO comment above this function
• Expected behavior: Edit the code; the plan todo panel has nothing to do with a source comment.
• Why: todo is an everyday word in a coding session and this use of it is not a plan checklist.

Completion Checklist

• Exactly one item is active, or the list is complete and every item is done.
• Use action=advance or a complete action=set list; never drop an item by omission.
• Item states are described as declarations; observed results are cited separately or named as missing.
• Name whether work is blocked or human-deferred.

Recovery Notes

• After a partial action=set, resend every item; use action=advance for state changes.
• If the panel shows nothing, read the current projection with action=show before re-declaring, so an existing checklist is not overwritten.
• If the user redirects the session away from the plan, record that on the write rather than deleting the checklist or marking its items done.

Workflow Lane

• Current lane: Automation and status (achievements, workspace-audit, production-audit, live-incident-response, automation-blueprint, github-event-ops, github-issue-intake, buzz, +39 more) - schedules, status, health, and ops review.
• If intent belongs to another lane, hand back to oh-my-hermes or name the adjacent workflow.
• Shared product, routing, compatibility, and evidence rules: omh-routing/references/skill-common-rail.md.

Use When

Use when the user wants a declared, HUD-visible plan checklist for the work at hand, or wants to read, advance, or clear one, without starting a delivery engine. Also use when the person asks in ordinary language to finish or resume the previously accepted work; infer intent from conversation, not isolated keywords.

Strong routing signals: `todo-checklist`, `$todo`, `plan checklist`, `todo checklist`, `phase checklist`, `declare a plan checklist`, `declare the plan todo`, `show the plan todo`, `clear the plan todo`

Catalog Metadata

Category: operator Phase: observability Hermes role: tracker Quality tier: evidence-gated Reasoning demand: light

Quality bar:

• A done item is a declaration, never observed evidence.
• For accepted multi-turn work, load references/closing-a-story.md before checkpoint, recall, explicit resume or recording verification/review/QA declarations. Preserve rejected ideas separately; templates remain optional.
• Current intent overrides old plans. Stop, analysis-only and topic changes take precedence; ask only when scope is ambiguous. Missing, stale or malformed evidence is not clean; waiting for a child remains open.
• Keep exactly one item active so the HUD names the current step.
• Use action=advance with item number, text-prefix guard and new state. action=set replaces the whole list: send every item or omitted ones are lost.
• The live checklist is session-owned; another TUI, Slack or Discord session cannot see or overwrite it.
• Load references/checklist-discipline.md: blocked_reason is an item unable to proceed; deferred_reason on the write is human redirection. Do not interchange them.
• For spec fitness, load references/requirements-quality-checklist.md; its generator may not tick its items.
• Before closing, read references/closing-a-story.md, not just ticks: done with blocked_reason means skipped; OMH never observes landing.

Handoff policy:

Declare and update the checklist directly with omh_todo; a checklist item is a plan declaration and never dispatches, executes, or verifies anything.

Required inputs:

• the work to be tracked

Expected outputs:

• a declared checklist with exactly one active item
• explicit states as work completes

Artifact expectations:

• metadata-only omh_todo/v1 plan todo owned by the declaring session

Safety rules:

• Checklist states never prove execution, verification, review, CI or merge.
• Do not declare a checklist for one-step, finished or directly answerable work.

Runtime Evidence

Record observed delegation results; otherwise return not_available or not_observed. Prepared OMH routing is not execution, review, CI, merge-readiness, or merge evidence.

• Treat wrapper memory/context summaries as advisory local context, not proof of opaque Hermes memory reads or changes. Preserve workflow intent and stop conditions; verify before claiming completion. Reply in the user's own words and the host's own voice: its SOUL.md persona owns reply language, tone, speech level, and sentence endings, progress updates included (where it sets no language, use the one the user wrote in), and OMH shapes structure and content only; OMH's record terms (surface, lane, wrapper, handoff, evidence boundary, not_observed) stay in records and tool calls, never in the sentence the user reads unless they ask about one; and when a stop condition or a decision the user owns ends the turn, offer the next action as a question rather than declaring what will not be done.

Use Hermes-native subagent/delegation features when available: native subagents -> Hermes delegation when available, otherwise sequential lanes.

Shared product, compatibility, topology, memory, harness, and execution rules: omh-routing/references/skill-common-rail.md. Load it when applicable; otherwise name an unavailable capability.