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.
• A contract two components must agree on is pinned here, not invented during the build. A format grammar, a field layout, a schema, a payload, a signature: each is a decision-bearing value in exactly the sense the altitude rule above already permits, so the plan carries its concrete form rather than the name of a document somebody will author later. This is where the plan stops a writer and a reader from drifting apart, and it is the one thing the altitude rule is most often misread as forbidding. See ../../references/contract-pinning-rule.md.
• 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.

Plan an Implementation

Step 1: Locate the Feature Specification

Read the user's argument and conversation context to identify the source artifact. The expected input is a feature-specification.md produced by the plan-a-feature skill, but any document describing what the feature should do is acceptable (PRD, design doc, product brief).

Resolve the source path:

• If the user provided a file path, use it.
• Otherwise, search for a recent feature-specification.md under docs/features/, docs/plans/, or other documentation roots discovered via CLAUDE.md or project-discovery.md. If multiple candidates exist, ask the user which one.
• If no feature specification exists, tell the user this skill requires one and recommend running plan-a-feature first.

Three files will be written. The primary plan lives at the root of {same-folder-as-source}/; the two companion artifacts live in {same-folder-as-source}/artifacts/ (which may already exist if the source spec came from plan-a-feature — share the same subfolder rather than creating a second one):

• {same-folder-as-source}/feature-implementation-plan.md — the primary plan.
• {same-folder-as-source}/artifacts/implementation-decision-log.md — every committed implementation decision with rationale, evidence, and rejected alternatives.
• {same-folder-as-source}/artifacts/implementation-iteration-history.md — round-by-round record of specialists engaged, questions raised, and how each was resolved.

Each file follows its own template, copied whole: feature-implementation-plan-template.md, implementation-decision-log-template.md, and implementation-iteration-history-template.md. Read a template in full from here rather than through the synthesis directives in Step 8.

Two more artifacts are written by Step 1.5 rather than by this step:

• {same-folder-as-source}/artifacts/scope-boundary.md — the boundary record. Always present, whether this run wrote it or an earlier planning skill did.
• {same-folder-as-source}/ui-designs/ — visual material the user supplies, when they supply some.

Create the artifacts/ subfolder before writing the companion files if it does not already exist.

The three files cross-reference each other. The main plan cites decisions with inline parenthetical links like ([D-3](artifacts/implementation-decision-log.md#d-3-rollout-strategy)); the decision log and iteration history cross-link through Driven by rounds: / Decisions produced: fields (siblings inside artifacts/), and both link back into the plan through Referenced in plan: / Changed in plan: fields via ../feature-implementation-plan.md.

If any of the three files already exist, ask the user whether to overwrite or append iteration notes before proceeding.

Read the full specification into context. If the specification is a feature-specification.md produced by plan-a-feature, also read its companion decision-log.md, team-findings.md, and feature-technical-notes.md if it exists — these live in {same-folder-as-source}/artifacts/ (the same subfolder this skill will write to). Fall back to reading them from {same-folder-as-source}/ directly for spec folders produced before the artifacts layout was introduced. The feature-technical-notes.md file is lazily created by plan-a-feature — its absence means no load-bearing mechanics were captured at spec time, not that the spec is incomplete. Note the decisions already settled, any open items the spec flagged, the review team findings, and any committed technical mechanics the plan must honor.

Detect tech-notes presence once, here. Record whether feature-technical-notes.md exists. If it does NOT exist, omit every T#-related sentence from agent briefs (Step 4), the spec-maturity tag set (Step 5), and the synthesis inputs (Step 8) — do not add boilerplate qualifiers like "if it exists" to those briefs. The T#-contradiction spec-maturity classification simply does not apply when there are no T# notes, so the spec-maturity gate reduces to the spec-level threshold alone.

Step 1.5: Read and Record the Scope Boundary

Read ../../references/planning-boundary-rule.md for the record's name, its sections, and the accepted visual-material file set. Establish the boundary before Step 2 discovery begins.

A record already exists at {same-folder-as-source}/artifacts/scope-boundary.md, which is the common case when plan-a-feature produced the source specification. Read it and use it. Do not re-ask anything it answers, including the direction-of-travel question: a recorded answer of any kind is never re-asked.

No record exists. Identify the work item this work descends from, which is a ticket, an issue, a pull request, or a written request the user typed, and read it. Record its stated scope and its stated exclusions word for word. When no work item exists, record that explicitly along with the statement that the user's request is the only boundary this run has.

The read does not traverse outward. A linked item, a sibling, or a closed item is not scope evidence for the item in hand, and its description is not evidence about the current item's platform, status, or intent.

Then take one confirmation turn before Step 2 begins. It restates the recorded boundary in the user's own terms, names any visual material you kept, and asks the direction-of-travel question with its subjects named from the work item you have already read. This turn is a confirmation rather than an escalation, and the one turn that carries more than one ask.

There is no tool here that reads a tracker, so what you record is often the user's own words rather than the work item's verbatim text. That is expected. Record which it was.

When the user hands you a work item that conflicts with the recorded one, surface the conflict in the confirmation turn and ask which governs. Do not silently overwrite the record and do not silently trust it.

Persist every piece of visual material the user supplies into {same-folder-as-source}/ui-designs/ as it arrives, named for the state each one depicts, and note each item into the record's Visual Material Received section as you keep it. Copy destinations are always the resolved plan folder's ui-designs/. When the host never made an item reachable as a file, name which items you could not keep and ask for them through the single stop, while they are still recoverable.

The specification's Visual Reference table, when it has one, tells you which material the upstream run already persisted. That material is already on disk and is not this run's to re-copy; this step covers what the user supplies to this run.

Source the explanation standard by invoking han-communication:explanation-guidance before you write the confirmation turn, and again before any escalation or stop later in the run.

Step 2: Discover Implementation Context

Before launching the team, gather the context specialists will need to produce evidence-backed recommendations. Use Glob and Grep to find:

• CLAUDE.md, AGENTS.md, and project-discovery.md — tech stack, languages, frameworks, build tools, test runners.
• ADRs in docs/adr/ or docs/architecture/decisions/ — architectural decisions the implementation must respect.
• Coding standards in docs/coding-standards/ or .github/CODING_STANDARDS.md — rules the implementation must follow.
• Code adjacent to the feature's touch points — existing modules, patterns, integration surfaces the feature will plug into.
• Existing implementation plans in the same documentation root — format precedent and level of detail the team expects.
• Recent activity — if git is available, run git log --since="90 days ago" --name-only --pretty=format:"" on the directories the feature will touch to surface churn and recent precedent.

Write the result to {same-folder-as-source}/artifacts/.discovery-notes.md as a structured summary: tech stack, ADRs found (paths + one-line summary each), coding standards found (paths + one-line summary each), code touch points (paths + one-line summary), recent-activity churn, measurements, and explicitly enumerated gaps (what was searched for and not found). Missing standards or ADRs are themselves findings the team should note.

Measure the figures the plan will rest on. For each quantity the specification asserts, record the assertion, the command you ran, and what it returned. Three outcomes, and the last two are why this earns its place:

Measurement: spec says "roughly 40 fixture files" | find test/fixtures -type f | 112
Measurement: {figure} | not reachable with granted tools
Measurement: {figure} | {command} | command failed: {exit status}

Your grant reaches find, git, Glob, and Grep and no further, so some figures are genuinely unreachable. Recording that is the point: a specialist can weigh an assertion it knows is unmeasured, and cannot weigh one it believes was checked. A command that ran and failed is an assertion too, never a measurement, because a search of a path that moved returns nothing rather than erroring.

The discovery notes file is the single source of truth for project context across the team. Specialists in Step 4 are instructed to read .discovery-notes.md first and not to re-grep for what has already been found — they may search further for what their domain specifically needs that the discovery notes do not cover, but they must not duplicate what is already there.

Step 3: Select the Team

Read team-selection.md. It carries the size bands with their specialist and round caps, the size-override rule, the two seats every team fills, and the roster to draw the rest from.

Default to small and escalate only when the signals clearly require it. State the chosen size, the recommended team, and the reason in one short message before launching agents. If the user disagrees, accept their override of the size, the specialists, or both.

Step 4: Round 1 — Parallel Specialist Review

Use domain-scoped briefs — do not hand every agent the full set of artifacts. Brief each selected specialist as team-selection.md specifies: its domain-scoped sections, the discovery notes from Step 2, the visual material, a report-length target matched to the size of the work, the blind-spot directive, and a question framed for its domain. Instruct each to read further on demand only if its domain needs it.

Launch every non-han-core:plan-synthesizer specialist in parallel, in a single message.

Step 5: Round 1 — Deterministic Aggregation

No agent is dispatched to facilitate the round. The mechanical work of consolidating specialist findings into a claim ledger, classifying spec-maturity, and choosing a next-step recommendation is performed deterministically by this skill itself. Two agents cover the two exceptions: han-core:plan-synthesizer runs the final synthesis in Step 8, and han-planning:discussion-facilitator runs a single facilitation pass when the spec-maturity gate trips (see below).

Aggregate the verbatim specialist outputs from Step 4 into the round-1 entry of artifacts/implementation-iteration-history.md using these rules.

Three passes run first, in this order. The order matters: merging before the other two is what stops one finding from ending up unverified under one specialist's identifier and blocking under another's.

Pass A: merge by substance. Two specialists often raise the same finding in different words. Merge those into one record carrying every originating specialist's own identifier (for example SEC-2, OCE-5). Do not reconcile the lists by hand during synthesis; that is what loses a finding. Two findings citing the same identifier while asserting different figures are the one exception and do not merge, per round-aggregation.md.

Pass B: strip blocking severity from findings resting on an uninspected input. A specialist that could not inspect something says so on the finding itself, in the form its definition specifies (look for the Unverified: line). Every finding carrying such a disclosure, and every finding depending on that same input, is labeled Unverified in the ledger and cannot carry build-blocking severity. Keep the finding: it may be real, and you can often verify it yourself. What it cannot do is reach the user looking like a blocker on the strength of something nobody read. Findings from a specialist that never received visual material are treated the same way when they turn on that material.

Record a disposition on every finding you label. Exactly one of verified: {what settled it}, not reachable with granted tools, or verification not attempted. The label says a specialist could not check something; the disposition says whether anyone since has. Without it the downgrade is permanent and silent, and it lands on exactly the findings that needed a tool nobody in the round holds.

This pass stays a step you perform rather than a check you run, and that is deliberate. It reads specialist output while that output is still in the conversation, before any of it reaches a file, so an executed check would have nothing to read. Converting it would mean first writing every specialist's raw output to disk. The other checks in this skill that read files already on disk are executed instead.

Pass C: check findings against the material this run holds. For any finding that turns on material on disk, open it and check the finding against it before it becomes an Open Question. A finding the material answers directly is closed with the citation rather than promoted. This is nearly free once the files are on disk. It covers the visual material, and it covers a cited D# in the spec's decision log, whose entry carries the committed option and the declined ones as sibling fields: read which field the figure came from rather than promoting the disagreement.

Record any evidence class no specialist could audit. When decisions rest on material no specialist received, say so in the iteration history, so the coverage gap is visible rather than silent.

Then aggregate the round deterministically, in the order round-aggregation.md specifies: build the claim ledger, tag spec-maturity and compute the gate, build the Open Questions list, pick the next-step recommendation, and write the round entry. That reference also carries the one facilitation call this skill makes, and when the gate trips it.