plan-a-feature

## Project Context

- CLAUDE.md: !`find . -maxdepth 1 -name "CLAUDE.md" -type f`
- project-discovery.md: !`find . -maxdepth 3 -name "project-discovery.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.

## Operating Principles

- **Interview relentlessly, but explore first.** If a question can be answered by reading the codebase, project docs,
  coding standards, ADRs, or existing feature specs — or by querying a read-only tool already available to this session
  that authoritatively answers it (for example a connected schema or data-source tool) — explore instead of asking. Only
  surface questions that genuinely require the user's judgment. The connected-tool path is gated on availability, not on
  a fresh judgment: use it only when such a read-only tool is actually permitted to this skill; if none is available,
  ask the user as today (see Step 4).
- **Walk the design tree.** Decisions have dependencies. Resolve foundational decisions first (what the feature does,
  who uses it, what outcome it produces). Then descend into dependent decisions (flow, states, edge cases, coordination
  points). Never ask a dependent question before its parent is settled.
- **Recommend, then ask.** For every question surfaced to the user, provide a recommended answer with rationale grounded
  in evidence (code, docs, conventions, or stated goals). The user can accept, redirect, or provide a nuanced response.
- **Behavior, not implementation, in the spec.** The specification captures WHAT the feature does, for WHOM, and WHY —
  at a level a reader who has never opened the codebase can understand. Language primitives, file/line references,
  function or class names, library mechanics, implementation patterns, and internal env/flag names DO NOT appear in
  `feature-specification.md`. Product-level subsystem names ("events processing system", "backend service"), user-facing
  UI vocabulary (popover, modal, toast), URL paths, behavioral verbs, and user-observable states DO. Technology brand
  names generalize one level up (NATS → "events processing system"; PostgreSQL → "database"; Redis → "cache"). This rule
  is language-agnostic — it applies equally to Go, Rails, Node, Python, Swift, Kotlin, and frontend JavaScript code. Any
  examples given in references or templates are illustrative, not an exhaustive deny-list.
- **Load-bearing mechanics go in `feature-technical-notes.md`, not the spec.** When a mechanic is load-bearing for a
  behavior — meaning the behavioral commitment in the spec is only correct because of that mechanic (ordering,
  durability, consistency, visibility timing) — the behavioral consequence goes in the spec sentence, and the mechanic
  goes in a `T#` note linked inline from that sentence. The tech-notes file is LAZILY created — it exists only when at
  least one load-bearing mechanic qualified. Mechanics that are discoverable from the code repo (an existing pattern, an
  in-use library, a documented convention) do NOT belong in the tech-notes file either — `plan-implementation` will find
  them from the code. Mechanics that do not affect observable behavior are pure implementation and belong in the
  implementation plan, not here.
- **YAGNI is a first-class operating principle.** Apply the evidence-based YAGNI rule in
  [yagni-rule.md](../../references/yagni-rule.md) to every commitment the spec carries. An item with no accepted
  evidence is demoted to `## Deferred (YAGNI)` with its reopening trigger, never silently dropped and never silently
  kept. An item with evidence gets the simpler-version test.
- **Evidence quality is the companion principle.** Apply [evidence-rule.md](../../references/evidence-rule.md) alongside
  YAGNI. YAGNI gates inclusion; this one characterizes the quality of what each commitment rests on, through trust
  classes, the corroboration gate on web claims, and a distinct label for no evidence at any tier.
- **The run stays inside the boundary it descends from.** The skill records the work item's stated scope and exclusions
  before the interview, per [planning-boundary-rule.md](../../references/planning-boundary-rule.md). Every commitment is
  checked against it, and anything the boundary excludes lands in a visible cut list, per
  [scope-justification-rule.md](../../references/scope-justification-rule.md).
- **Visual material the user supplies is kept, and reaches every reviewer.** Persist it beside the spec as it arrives,
  never at document-write time, and pass its paths in every reviewer's brief. The session context is the only copy until
  it reaches disk, and a compaction destroys it. The boundary rule owns the convention.
- **Questions to the user arrive one at a time, led by the consequence.** Per
  [operator-escalation-rule.md](../../references/operator-escalation-rule.md). The opening confirmation turn is the one
  exception, and the one turn that carries more than one ask.

# Plan a Feature

## Step 1: Capture the Feature Request and Output Location

Read the user's argument and conversation context to extract the feature being planned. If the request is too thin to
start (e.g., just "plan a feature"), ask the user for a one-to-two-sentence description of what the feature does and
what outcome it produces — nothing else yet.

Resolve the output location:

- If the user specified a folder path, use it.
- Otherwise, propose a folder name of **3 to 5