Project config: {app} is the project's new-code root from .claude/rules/project-structure.md; project values (package manager, commands, base branch, error surface) come from docs/agents/project-conventions.md. Resolve both before writing any file — never assume. If a needed file is missing, stop: "Run /setup-daher-skills first — missing <file>."

Modify Feature

Two workflows over existing code: Extend (add code to a shipped feature) and Refactor (restructure without behavior change). Both share the same first and last phases.

Am I in the right skill?

If a request mixes refactor + behavior change, split it: refactor first (this skill), behavior second (pipeline or Extend). Never both in one diff.

Phase 0 — Read First (both workflows, mandatory)

1. Map the slice. ls the feature directory; Read every file you plan to touch, its co-located tests, and the feature barrel. Do not edit code you haven't read.
2. Load the relevant rules. Read the .claude/rules/ files matching what you'll touch (components → component-hook-separation, layout-ownership; hooks → tanstack-query; API → api-boundary, error-handling; anything → project-structure). Rules are the source of truth — never rely on memory of them.
3. Reuse check. Before writing anything new, search for an existing solution: the project's ui root and its custom/, shared/, and sibling features. Use existing components as-is — if one almost fits, adapt the consumer, don't extend the shared component.
4. Consumer map. Grep the call sites of every export you plan to change (repo-wide, not just the feature). This list is your blast radius — you'll re-check it in the final phase.

Workflow A — Extend

1. Placement first. Decide where the new piece lives per project-structure.md: inside the sub-feature that uses it, at the parent feature's shared level (hooks/, domain/, api/) if 2+ sub-features need it, or promoted to shared/ / ui/custom/ only when it's genuinely cross-feature.
2. Follow the neighboring pattern. The new code should look like the file next to it — same naming, same hook/component split, same test style. Consistency with the local slice beats the ideal template. When the neighbor predates a current rule, follow the rule and note the drift; don't copy the outdated pattern.
3. New API surface → the boundary applies. A new endpoint means dto schema + mapper + hand-authored domain type per api-boundary.md — even inside a feature that predates the pattern.
4. Write the code + its tests (co-located; two-level factories per the frontend-testing skill if the feature has them).
5. Go to Final Phase.

Workflow B — Refactor

1. Classify honestly. Will ANY user-visible behavior change (rendered output, requests, navigation, timing)? Yes → this is not a refactor; stop and route to the pipeline. The test for later: zero assertion changes in existing tests.
2. Safety net before touching. Do the existing tests pin the current behavior of what you're restructuring? If coverage is thin, write characterization tests FIRST and watch them pass against the current code — a refactor without a net is a gamble, not a refactor.
3. Use the standard moves (each links to its rule):
   • Extract hook from component → component-hook-separation.md (component becomes a pure renderer)
   • Split a fat component → layout-ownership.md (children render flush; the parent owns spacing)
   • Promote to shared/ or ui/custom/ → project-structure placement rules; move, update every consumer from the Phase 0 map, delete the original
   • Absorb duplication → react-clean-architecture extraction triggers (3+ occurrences, or 2 with a third in sight — not before)
   • Migrate legacy code toward {app} patterns → project-structure.md scope notes (only when already touching that code)
   • Feature predates the API boundary → migrate that endpoint's slice to dto/mapper per api-boundary.md's migration note (migrate one endpoint first and use it as the reference for the rest)
4. Execute surgically. Every changed line traces to the refactor goal (working-principles trace test). No drive-by improvements, no comment rewrites, no formatting churn — mention smells you find, don't fix them here.
5. Go to Final Phase.

Final Phase (both workflows)

1. Consumer sweep. Re-grep the Phase 0 consumer map: every call site compiles against the new shape, imports updated, no orphaned exports left behind.
   • If a Zustand action, a store-driven effect, or a query invalidation changed, run the click-path audit (a reference of the systematic-debugging skill): map which keys the action sets and which it resets that it does not own, then trace every handler on the affected screen. A refactor that moves state is where "the wizard jumps back a step" bugs are born, and the test suite rarely pins them.
2. Fresh verification (verification-before-completion.md): pnpm vitest run {feature-dir} — if the glob matches 0 test files, that's a FAIL, not a pass — and pnpm build. For Refactor: the suite must be green with zero assertion changes; an assertion you "had to" change means behavior changed — reclassify and tell the user.
3. Report honestly: what changed, what was reused vs created, any drift/smells noticed but not fixed.

Next Step

Use AskUserQuestion to offer: commit via the git-commit skill (refactor commits stay separate from feature commits — refactor(scope): vs feat(scope):), continue with another modification, or run refactoring-ui (Audit) if components changed visually.

Rules

• Never mix refactor and behavior change in one diff.
• Never skip Phase 0 — editing unread code is how conventions drift.
• Never extend a shared component to fit one consumer — adapt the consumer.
• Characterization tests are written BEFORE the refactor, never after.