plan-implementation

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, 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

• The feature specification is the ground truth for what, but not for scope. This skill plans how. Do not re-open behavioral decisions the specification already settled; flag contradictions as Open Questions for the user. Scope is the exception, and it is narrow: a specification is an artifact, not a scope authority, so a commitment it carries for a subsystem, integration, or artifact the work item never asks for is cut with the citation rather than planned. The license reaches unrequested subsystems and nothing else. See ../../references/scope-justification-rule.md.
• The run stays inside the boundary it descends from. Before locating the specification, the skill records the work item's stated scope and exclusions, per ../../references/planning-boundary-rule.md. The scope gate at Step 7.5 then reads that record, including commitments the plan inherited from the specification.
• Visual material the user supplies is kept, and reaches every reviewer. Persist it beside the plan as it arrives, never at document-write time, and pass its paths in every dispatched specialist's brief. The boundary rule owns the convention.
• Questions to the user arrive one at a time, led by the consequence. An escalation carries one question, opens with what a person who will not read the code would describe, gives named candidate answers, and puts paths and identifiers below the question or leaves them out. Per ../../references/operator-escalation-rule.md. The opening confirmation turn is the one exception, and the one turn that carries more than one ask.
• The han-core:plan-synthesizer reconciles the specialists, it does not author every section. It reads what every specialist produced, tracks claims and evidence, and commits the decisions the plan records. Specialists own their domains. This skill runs the rounds itself; the synthesizer is dispatched once, at the end.
• Always include han-core:junior-developer on the team. When decisions lack strong evidence, the han-core:junior-developer reframes the issue in plain terms first — that frequently unlocks a resolution without needing the user.
• Escalate to the user only when evidence and reframing have both failed. Every escalation surfaces with a full description, the evidence considered, and a recommended answer.
• Done is when the han-core:plan-synthesizer says so. The loop exits when the han-core:plan-synthesizer reports the plan is ready to commit, or that only user-input items remain. The user is not asked to keep iterating past that point.
• YAGNI is a first-class operating principle, applied to implementation choices. The implementation plan inherits the spec's behavioral commitments but applies the evidence-based YAGNI rule from ../../references/yagni-rule.md independently to abstractions, configuration knobs, observability, runbooks, infrastructure, rollout machinery, test scaffolding, schema columns, indexes, and any other implementation artifact the plan recommends. Items that fail the evidence test get demoted to a ## Deferred (YAGNI) section in feature-implementation-plan.md with the reopening trigger named; items where a strictly simpler implementation satisfies the same evidence get the simpler implementation recorded as the decision and the larger version under Rejected alternatives:. The Sentry-runbook-on-staging-only-Sentry pattern is the named project precedent — operational machinery shipped before the system that drives it actually produces the data, traffic, or failures it covers is YAGNI by default. Every committed implementation item is ongoing maintenance and a pattern future agents will copy.
• Keep the plan at planning altitude — intention over prescription. The plan is the reader's layer: it carries the intention and goals of the work, the touch points (a module, a contract, a boundary), and the decision-bearing values (a flag default, a key name, a threshold). NEVER inline full file contents or prescribe line-level edits, BECAUSE a non-author must be able to read the plan, plans are executed after the codebase has moved on (a prescribed edit list goes stale and misleads), and the implementer — human or coding agent — reads the current code at build time. Deeper detail lives one hop away in the companion artifacts. YAGNI gates whether an item is included; this principle gates how verbose an included item is.
• Plain language leads; technical detail nests beneath it. Every section leads with plain-language prose a non-author can follow. Technical detail is minimal references only — a path, a contract name, a decision-bearing value — placed below or after the plain language it illustrates, never mixed into it and never free-standing. When choosing between more plain language and more technical detail, choose more plain language.
• Frame the work around user stories when possible. User stories give the implementer the intent at a high level before any mechanics. Derive them from behavior the specification already commits to — never invent behavior — and anchor work units to the story each one advances. When the feature has no user-facing behavior, frame stories around the operator or consuming system; skip stories only when no actor benefits in a describable way.
• The plan lives in three cross-referenced files. feature-implementation-plan.md is the primary plan and lives at the root of {folder}/; implementation-decision-log.md records every decision and implementation-iteration-history.md records each round of discussion — both companion artifacts live in {folder}/artifacts/ to keep the planning folder uncluttered. The main plan cites decisions with inline ([D-N](artifacts/implementation-decision-log.md#...)) links for non-obvious claims. The decision log and iteration history cross-link through Driven by rounds: / Decisions produced: fields (they sit as siblings inside artifacts/), and both link back into the plan through Referenced in plan: / Changed in plan: fields using ../feature-implementation-plan.md. Any edit to one file requires updating the matching fields in the others.