/omh-todo-checklist

name: "omh-todo-checklist"
description: "[omh] Resume or finish the work we agreed on: continue or finish the accepted work from conversation context, preserve rejected ideas, and report evidence-bounded completion. Also declare and advance the metadata-only plan checklist without starting a delivery engine. Use when the user says: todo-checklist, plan checklist, todo checklist, phase checklist, declare a plan checklist, declare the plan todo, show the plan todo, clear the plan todo."
metadata:
  hermes:
    tags: [workflow, oh-my-hermes, operator]
    category: operator
    phase: observability
    role: tracker
    quality_tier: evidence-gated

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.

##