plan-work-items

## Project Context

- CLAUDE.md: !`find . -maxdepth 1 -name "CLAUDE.md" -type f`
- project-discovery.md: !`find . -maxdepth 3 -name "project-discovery.md" -type f`
- feature-implementation-plan.md: !`find . -maxdepth 5 -name "feature-implementation-plan.md" -type f`
- personal config directory: !`bash "${CLAUDE_PLUGIN_ROOT}/scripts/han-config-dir.sh" 2>/dev/null || echo "$HOME/.claude"`
- project .han/config.md: !`cat .han/config.md 2>/dev/null || echo ""`

As your first action, use the Read tool on `.han/config.md` inside the `personal config directory` path above. A read
that returns no file is no personal configuration: continue silently. When that file or the `project .han/config.md`
probe supplies content, apply it per [config-rule.md](../../references/config-rule.md), which governs precedence
between the two files, relative-path resolution, and what to do with a file that reads but cannot be used.

# Plan Work Items

Break an implementation plan into vertical slices (tracer bullets) and write them as work items to a single
`work-items.md` file.

This skill mostly coordinates: reading the boundary this work descends from, locating the plan or context, resolving
where the file goes, printing the breakdown, writing the work-items file. It runs autonomously apart from two named
turns: the confirmation turn it takes when no boundary record exists, and the single stop for an input only the user can
supply. Step 5 is where the judgement comes into play, in dividing up the plan.

## Operating Principles

- **Run autonomously, with two named exceptions.** After the initial request, run end to end without pausing for human
  confirmation. When a decision has a reasonable default (where the file goes, how the plan divides), make it, state it,
  and proceed. Print the work item breakdown for visibility, but never gate on approval to continue. Two situations are
  exceptions, and they are the only ones:
  - **The confirmation turn**, taken when no boundary record exists, per Step 0.
  - **The single stop**, taken once when an input only the user can supply is missing and its absence degrades the work
    items, per [operator-escalation-rule.md](../../references/operator-escalation-rule.md).

  Beyond those two, stop only when the skill genuinely cannot continue: there is no plan or context to work from at all.
  An expected artifact nobody can produce right now is recorded as a gap and does not stop the run.

- **One work-items file, no repository awareness.** This skill produces exactly one `work-items.md`. Beside it, the run
  also writes or updates the boundary record and persists any visual material it receives, per Step 0 and
  [planning-boundary-rule.md](../../references/planning-boundary-rule.md); those are companion artifacts, not a second
  breakdown. The skill does not split work by repository, count repositories, or reason about cross-repository
  integration. The breakdown is driven only by the plan or context it is given.
- **Save incrementally — never lose work.** Write the work-items file as soon as the title and intro are drafted, then
  append each work item as it is finalized. Do not buffer the whole document in conversation memory and write it at the
  end.

## Rules

- Do NOT modify, annotate, or comment on the source implementation plan or context. It is read-only input. The boundary
  record and the visual-material folder are the exception: those the run writes, per Step 0.
- **Every work item carries a justification.** It is a named field of its own, `**Justification.**`, placed immediately
  before the `**References.**` block, never a line of summary prose. It names one of three things: the work-item
  language it descends from, the visual material the operator attached, or the asked-for work it is a necessity of. A
  work item that cannot fill it does not go in the breakdown; it goes in the cut list. Full rule in
  [scope-justification-rule.md](../../references/scope-justification-rule.md).
- **Unjustifiable work goes in a visible cut list**, in the work-items file and in the closing summary, naming what the
  item would have done in plain language and why it was cut. Do not search outward to a linked, sibling, or closed item
  to find a justification for it.
- Each work item is a **vertical slice**: a narrow but complete path through the relevant layers (schema, API, UI,
  tests) that is demoable or verifiable on its own. Not a layer, not a stub.
- **Summary and acceptance criteria drive the item; criteria render at the bottom.** Draft each work item's
  plain-language summary first and its acceptance criteria immediately after — before any detail — so every remaining
  block is written in support of a criterion, and detail that supports no criterion is cut. In the rendered work item,
  the summary opens and the acceptance criteria sit at the bottom, immediately before Depends on. Test expectations
  live inside the acceptance criteria; there is no separate Tests block.
- **The summary is plain context, three to five very short sentences.** It states why the work is needed and what work
  is being done, in plain language a reader can follow without the plan open. No technical detail and no ID references —
  plan references live in the References block, each ID paired with a one-sentence description of what it is. Never
  write an inline `See plan: D-1, D-5` breadcrumb; an ID list without descriptions is clutter, not information.
- **The detail block is a plain-language work list.** After the summary, the body is a `Work to be done` bullet list:
  each bullet one to two short sentences of plain language stating a piece of the actual work. Technical detail, when
  needed, goes in a nested bullet under the plain-language bullet it belongs to — never mixed into the parent bullet
  and never as free-floating technical prose.
- **Acceptance criteria are outcomes of this work item only.** Never include standard operating procedure (commit
  pushed, CI green, PR opened, revie