implement-featurelisted

# Feature Implementation Workflow Feature work in a-novel **backend services** (the `service-*` repos with the `cmd`/`internal/...`/`pkg` clean-architecture layout) runs through three gated phases: **Assess → Plan → Implement**. Phase 4 covers recovery when an earlier branch needs to change. > **Where the design comes from.** For non-trivial, multi-repo, or architectural work, `plan-feature` > settles the design first and produces a **planning issue** (an Epic, or a Feature with its Task > sub-issues). This skill executes it: the **Plan** phase below is the per-repo **branch > decomposition** of that agreed design, typically one branch/PR per Task sub-issue. Link every PR to > its issue with a `Closes #<n>` line, so merging closes the unit and advances the Epic's sub-issue > progress. A PR under an Epic spanning repos also carries the `epic:<N>` label and lands under the > gates in "Landing a Task that belongs to an Epic" below. Small, unambiguous changes start directly > here. > > **Scope: backend services only.** Frontend **`platform`** repos are deliberately more monolithic, so > the layer-by-layer branch decomposition here does **not** apply to them; their authoring conventions > arrive in a later stage. Don't force a platform change through this workflow. --- ## Phase 0: Before Writing Any Code **Check the workspace is yours.** Every checkout the task will touch must be on `master` with a clean tree — see `git-conventions` › Workspace Hygiene. A dirty tree or a fore