Plan an 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.