git:20260910.bcfbdae to git:20260915.3d7652b

24 added, 177 removed. Audit A to A.

---

name: dev-frontend

description: "Use when an authorized frontend change must be implemented or refactored; owns frontend source edits and risk-matched validation, not audit-only work, UI specification, browser/client operation, or Git delivery."

---

# Frontend Implementation

- ## Overview

- Implement the requested frontend behavior in the repository's existing stack. Reuse

- the nearest proven component, hook, service, style, and page structure by default;

- extend before creating, and create only when current owners cannot satisfy the task.

- Consume `urn:skills:frontend-change-request:v1` and produce

- `urn:skills:source-change-result:v1`. Typed Task, authority, graph, or package inputs

- are used when supplied; they do not replace current source and repository contracts.

- ## Workflow

- 1. Read effective repository guidance, identify the real frontend root, package

- manager, runtime, target route/component, and current Worktree state.

- 2. Read only the authorities and source needed for the target slice. Start with the

- user requirement and current implementation; use Product/UI specs and the resolved

- `<design-root>/DESIGN.md` only when they apply. A missing optional artifact or graph

- does not create a prerequisite ceremony. Treat declared Product behavior readiness

- and UI visual/interaction readiness as independent axes: when both lanes apply,

- require both matching slice verdicts to be ready before editing. One `Ready` verdict

- never upgrades the other; route a conflict or blocker to its semantic owner rather

- than choosing between authorities.

- 3. Complete a bounded search for the current owner, analogous consumer, and reusable

- component before choosing an implementation owner. If the supplied context already

- identifies the same maintained file, owner, and function for this feature, use that

- record directly and verify the target in current source; do not call `repo-map`.

- Only when a cross-owner reuse or impact edge remains unresolved may an existing

- compatible `repo-map` snapshot serve one bounded navigation query. Never scan,

- refresh, or render a map for task-local implementation. Collect only the contract facts

- changed by, depended on by, or decisive to acceptance for the target slice. Load

- [project grounding](references/project-grounding.md) only when the change crosses a

- real API/auth, environment/build, durable-data, desktop/native, compatibility,

- deployment, or cross-repository boundary. Keep unrelated risk classes out of scope.

- 4. Use the [reuse and page-ownership checklist](references/checklist.md) to freeze one

- task-local contract revision before editing: observable acceptance, non-goals,

- affected owners/contracts, reuse decision, and smallest credible validation seam.

- For API-backed behavior, resolve every decisive field from the governing contract

- and current call chain; unchanged non-decisive fields inherit their current verified

- owner. Stop rather than infer an unresolved decisive field. A correction creates a

- new revision: reject delayed work for the old revision and reconcile any landed old

- hunks before implementation resumes. Keep route/tab shells declarative; independent

- stateful sections belong in feature components rather than a large conditional page.

- 5. Make the smallest coherent source change. Preserve established framework, routing,

- state/data, component, styling, and test owners; do not introduce a parallel stack

- or speculative shared layer.

- For legacy or native-wrapper frontends, first identify whether a directive selects a

- platform, build mode, or runtime environment. Never reinterpret platform guards such

- as uni-app `APP-PLUS` as development/production selection. When environment identity

- is branch-owned, preserve the target branch's manifest, endpoints, native plugins,

- signing settings, and vendor-channel values; do not add a parallel environment map,

- wrapper build script, or package-manager policy unless the accepted task changes that

- architecture.

- 6. Batch a coherent development slice before validating it. Treat a running dev server,

- compiler, type checker, or repository diagnostic stream as the first feedback loop;

- do not run a check after every edit while that signal remains clean. At slice

- completion, before handoff, or after a real error, run one nearest focused check.

- Expand only for a changed shared contract, generated/build chain, runtime boundary,

- or affected consumer, or when no narrower credible check exists.

- For a confirmation, keep, or no-op request, select the focused check for the current

- accepted baseline; do not run a post-change check that only applies after an authorized

- change. If that focused check fails, do not report `completed`: report the failure or

- `Not verified`, preserve its evidence, then diagnose or stop.

- Before an expensive run, use low-cost static and boundary checks that can expose

- deterministic blockers. A blocker stops only dependent acceptance runs; a warning

- does not. An already-authorized minimal diagnostic run may investigate the blocker,

- but cannot count as acceptance. Keep platform/path/process checks in the project verifier.

- When no narrower credible check exists, run the existing local build or suite once

- if it can verify the changed behavior; state its reason, command, and scope first.

- Preserve separate authorization for substantial extra cost, dependency installation,

- production access, and external effects. If no supported check can establish the

- claim, report that evidence gap; do not repeat unchanged checks.

- 7. Report changed owners, reuse decisions, validation, remaining Worktree content, and

- every applicable runtime or external gap as `Not verified`. The coordinator continues

- browser/client acceptance or Git delivery through its owner when already authorized

- by the request or effective instructions; source implementation grants no new authority.

- ## Small Change Fast Path

- Use this path for one known owner and a local style, template, icon, copy, or similarly

- bounded component change with no API, state/data, public/shared contract, generation,

- build, deployment, or production-behavior change.

- 1. Perform one targeted lookup and one minimal patch. Batch adjacent edits before one

- completion checkpoint; never validate after each edit.

- 2. If an already running dev/compiler diagnostic remains clean, finish with a local

- diff inspection and `git diff --check`. A new test run is optional and should occur

- only for changed observable behavior, an existing focused regression, a real dev

- error, or an explicit request. Report tests `Not verified` when they were not run.

- 3. Avoid aggregate tests or builds unless they are the only credible check under the

- workflow above. Do not add a red test for pure style/template/icon/copy changes.

- 4. End this implementation stage after the checkpoint. Continue already-authorized

- acceptance and delivery through their owners; do not add unrelated investigation,

- delegation, review, or repeated checks, or omit requested runtime acceptance.

+ ## Entry Gate

- ## Conditional Profiles

+ Implement the smallest authorized frontend slice in the existing stack. Read effective guidance, current Worktree, target route/component, and only applicable Product/UI/DESIGN authorities. Stop when a decisive behavior or visual contract is unresolved.

- - **Selected visual source:** load [authorities](references/specification-authorities.md)

- and [visual evidence](references/frontend-visual-evidence.md) only when an accepted

- source and implementation-ready UI contract actually govern the task. Map applicable

- acceptance IDs before editing; use `ops-browser` or `ops-client` for required runtime

- evidence. Two-pass same-state comparison is a visual-completion gate, not a default

- requirement for ordinary frontend changes.

- - **Layout or affected interaction:** load

- [layout governance](references/frontend-layout-governance.md) when geometry,

- overflow, scrolling, layering, breakpoints, state transitions, competing inputs,

- focus, or hit testing materially change.

- - **Maintained CSS/Sass/Less:** load [CSS governance](references/frontend-css-governance.md)

- when spacing ownership, cascade cleanup, flex/grid choice, or rendered wrapper

- structure materially changes.

- - **Project-owned UI governance:** load

- [UI components and tokens](references/ui-components-and-tokens.md) only when the

- change adds or modifies a shared UI component, direct third-party UI dependency,

- structured token source/generated output, Component Registry, or adoption record.

- Use the project's native validator and stop on stale or conflicting ownership;

- ordinary feature composition does not activate this profile.

- - **Protocol or generated client:** load [protocol contracts](references/protocol-contracts.md)

- only for an existing or explicitly introduced contract chain.

- - **Behavior-first implementation:** load [behavior first](references/behavior-first.md)

- when a stable public seam can support one red-capable check per behavior.

- - **Framework, styling, state, desktop, tooling, quality:** load only the matching

- [framework](references/framework-profiles.md), [styling](references/styling-systems.md),

- [stack](references/stack-guidelines.md), or [code-quality](references/code-quality.md)

- profile required by the current change.

- - **Forgeway integration:** when an immutable Run and input PackageManifest are

- supplied, bind the changed result and observations to that basis. Do not require a

- Forgeway Run for normal repository development.

+ ## Route Map

- For a maintained non-LLM UI projection: Require a named owner, producer, non-LLM

- consumer, semantic version, executable validator, drift policy, and retirement rule.

- Run the repository-defined non-mutating validator before relying on it, then verify

- referenced routes and components in current source. Otherwise ignore the projection

- rather than creating or repairing one for ordinary implementation.

+ | Request condition | Read | Result |

+ | --- | --- | --- |

+ | Any frontend source change | [checklist](references/checklist.md), [stack guidelines](references/stack-guidelines.md), and [framework profiles](references/framework-profiles.md) | Reuse-first implementation |

+ | No-op or accepted-baseline confirmation | [checklist](references/checklist.md) | Exact owner-symbol and baseline-check evidence |

+ | Behavior/public seam, ownership, or quality concern applies | [behavior first](references/behavior-first.md), [codebase design](references/codebase-design.md), and/or [code quality](references/code-quality.md) | Scoped design/validation |

+ | Styling, tokens, component, layout, motion, or visual-direction change applies | [styling systems](references/styling-systems.md), [CSS governance](references/frontend-css-governance.md), [components/tokens](references/ui-components-and-tokens.md), [layout](references/frontend-layout-governance.md), [motion](references/interaction-motion-quality.md), and/or [visual direction](references/visual-direction-and-anti-slop.md) | Visual implementation contract |

+ | Selected-source visual closure applies | [specification authorities](references/specification-authorities.md) and [visual evidence](references/frontend-visual-evidence.md) | Two-pass evidence boundary |

+ | API/protocol or cross-boundary signal applies | [OpenAPI governance](references/openapi-contract-governance.md), [protocol contracts](references/protocol-contracts.md), and/or [project grounding](references/project-grounding.md) | Qualified integration work |

- ## Hard Rules

+ ## Invariants

- - Follow repository-pinned versions, lockfiles, scripts, directories, and dependency

- policy; do not normalize unrelated tooling.

- - Existing components, adapters, stores, utilities, tokens, and interaction patterns

- are the default. A new owner needs a targeted search and a concrete behavior or

- ownership reason.

- - An API filename, legacy prose example, frontend wrapper default, or screenshot is not

- sufficient authority for method/path, parameter placement, trigger timing, or

- success semantics. Resolve decisive contract fields before implementation and keep

- unavailable runtime proof `Not verified` rather than compensating with fallback code.

- - Keep page/tab shells responsible for navigation and composition, not section-specific

- APIs, forms, tables, drawers, validation, and lifecycle branches.

- - Treat reveal state for masked sensitive values as an explicit interaction contract.

- For a list intended to show at most one value, opening a new row must atomically hide

- the previous row; validate both the newly opened row and the prior row after the same

- transition rather than checking only the clicked item.

- - Prefer non-mutating validation. Compare Worktree state around tools that may generate

- or rewrite files and never absorb unexplained drift.

- - A build, lint pass, source inspection, or browser preview proves only its own layer.

- Mark unexercised visual, responsive, accessibility, network, desktop, deployment, and

- production behavior `Not verified`.

- - Stop on missing source-edit authorization, an unresolved governing contract, or a

- second failure of the same frozen runtime acceptance; preserve evidence and return to

- diagnosis instead of adding speculative patches.

- - Do not stage, commit, push, deploy, or open a pull request from this Skill.

+ - Reuse the nearest maintained owner before creating; preserve routing, state/data, component, and styling ownership.

+ - A no-op confirmation still reads and reports the exact owner path and symbol plus its matching contract before running the current-baseline focused check.

+ - Keep Product behavior and UI visual readiness independent; source/build evidence does not prove browser/client/runtime acceptance.

+ - Do not generate visual assets, operate browser/client state, review, or mutate Git.

- ## Output

+ ## Output Map

- Return capability `frontend.source.implement` with scope, project/stack, authority and

- reuse decisions, changed files/contracts, focused and expanded validation, Worktree

- drift, exclusions, and `Not verified` gaps. Include visual mapping and runtime passes

- only when the selected-source profile was active. Keep successful command output to a

- result summary; include relevant log tails only for failures.

+ Report scope, authorities, reuse decision, selected profiles, changed files/contracts, focused validation, visual evidence state when applicable, exclusions, and gaps.

- ## References

+ ## Reference Map

- - Core: [usage](references/usage.md), [checklist](references/checklist.md),

- [authorities](references/specification-authorities.md),

- [grounding](references/project-grounding.md), [evals](references/eval-cases.md).

- - Conditional: [layout](references/frontend-layout-governance.md),

- [CSS governance](references/frontend-css-governance.md),

- [UI components and tokens](references/ui-components-and-tokens.md),

- [visual direction](references/visual-direction-and-anti-slop.md),

- [motion](references/interaction-motion-quality.md),

- [visual evidence](references/frontend-visual-evidence.md),

- [visual example](references/frontend-visual-gate-example.md),

- [protocols](references/protocol-contracts.md),

- [OpenAPI governance](references/openapi-contract-governance.md),

- [behavior first](references/behavior-first.md),

- [codebase design](references/codebase-design.md),

- [frameworks](references/framework-profiles.md), [styling](references/styling-systems.md),

- [stack](references/stack-guidelines.md), [quality](references/code-quality.md).

+ - Read [checklist](references/checklist.md), [stack guidelines](references/stack-guidelines.md), and [framework profiles](references/framework-profiles.md) for baseline implementation.

+ - Load each condition-specific reference named in the Route Map only when its condition applies.

+ - Read [frontend visual gate example](references/frontend-visual-gate-example.md) only when constructing visual evidence.

+ - Read [usage](references/usage.md) for triggers and boundaries.

+ - Maintainers only: read [eval cases](references/eval-cases.md); do not load it during ordinary runtime.