| name | frontend-code-implementation |
| description | Implement a vetted legacy-web UX slice in the target repository after requirements and touched-seam harnesses are green. Discovers the real frontend stack, changes code test-first, and records implementation evidence before browser validation and review. |
Frontend Code Implementation
Use this skill for code mode, after ux-modernization has designed the target
flow. It changes the actual target repository rather than producing only a UX
proposal.
Required inputs
docs/renovation/02-architecture.md: confirmed frontend package roots, routes,
API boundaries, and actual seam IDs.docs/renovation/03-requirements.md: accepted criteria and edge cases.plan.md: an explicit change entry and every touched seam marked green.docs/renovation/05-ux/README.md: approved after-flow and removal decisions.- Figma evidence only when the change opted into Figma review.
Do not start if the harness map is empty, a touched seam is absent, or any touched
seam is not green. Return to architecture-recovery or behavior-harness; never
invent a seam name to pass this gate.
First action: verify renovation state
Before discovering files or writing code, read plan.md and confirm:
gates.grilling: passed.- The change has an explicit entry with its actual touched seam IDs.
- Every declared touched seam exists in
harness and is green.
- If Figma review was requested or a Figma URL/frame is claimed as the baseline,
figma_design: approved is recorded with review evidence. Otherwise,
figma_design: not_used is recorded.
If any condition is unmet, stop and return to renovate-orchestrator,
behavior-harness, or figma-design-review. Do not inspect implementation files as
a substitute for state evidence, and do not begin code mode.
Method
- Discover the real implementation surface. Identify package manifests, lock
files, framework/version, test and lint scripts, routes/pages, components, state
boundaries, API clients, feature-flag mechanism, and existing accessibility/test
selector conventions. Reuse the target repository's patterns.
- Write a change manifest. Record the accepted requirement IDs, target package,
affected route/component/API boundary, touched seams, rollback/feature-flag
behavior, and user-visible success criteria in
docs/renovation/05-ux/frontend-implementation.md.
- Invoke
test-authoring. Write the smallest failing existing-framework tests
for every changed acceptance criterion before editing implementation code. Include
loading, error, empty, permission, and relevant bulk/concurrent states.
- Implement the vertical slice. Make focused route/component/state/API-client
changes. Preserve legacy behavior outside the approved slice; use the existing
flag or adapter seam when rollout must be reversible. Use stable accessible names
or the project's selector convention for browser tests.
- Run existing validation. Run the target package's relevant unit/component/E2E
tests, type check, lint, and build only when those scripts exist. Run the
characterization suite for every touched seam.
- Record evidence. Add commands, results, screenshots/traces if generated, and
feature-flag/rollback proof to the implementation evidence. Update the
plan.md
change entry without marking review complete.
- Handoff. Invoke
web-action-testing against the running real UI, then
strict-code-review. The slice is not done until both gates pass.
Non-negotiable safeguards
- Do not delete a legacy route, component, field, or API call solely because it looks
unused; require architecture evidence, requirement approval, and green seams.
- Do not replace API contracts, authorization behavior, or error handling with
client-only assumptions.
- Do not claim Figma parity unless the change is linked to an approved Figma review.
- Surface validation failures using the target application's established error UI;
do not silently drop failed user actions.
Output template and helper script
- Korean template: OUTPUT_TEMPLATE.md
- Scaffold script:
scripts/create-frontend-implementation-evidence.sh <repo-root> <target-name>
