Standardized frontend implementation guidance for FE Dev using the SRS-declared Frontend-Framework. Use when coding, refactoring, or reviewing UI work in React Native, ReactJS, Flutter, Vue.js, Angular, or Next.js; FE Dev reads docs/SRS.md Frontend-Framework plus §3.4.2/§3.4.5 for multi-app projects, then selects the matching reference and, for React Native or Flutter, the focused mobile companion skills for implementation, performance, or platform integration.
التثبيت
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
Standardized frontend implementation guidance for FE Dev using the SRS-declared Frontend-Framework. Use when coding, refactoring, or reviewing UI work in React Native, ReactJS, Flutter, Vue.js, Angular, or Next.js; FE Dev reads docs/SRS.md Frontend-Framework plus §3.4.2/§3.4.5 for multi-app projects, then selects the matching reference and, for React Native or Flutter, the focused mobile companion skills for implementation, performance, or platform integration.
agents
["fe-dev"]
sdlc_phase
implementation
owner
Platform Eng
status
active
FE Framework Coding Standard
When to use
You are FE Dev implementing or reviewing UI code after the stack is declared in the signed-off SRS. This skill standardizes how to write framework-specific code without turning every task into a framework migration.
Outputs: framework-native UI code that follows the project's existing architecture, names stable test selectors, implements every required Figma field/item/copy/action, reproduces the contracted composition, uses every required exported asset, handles loading / error / empty states, satisfies design tokens where available, and includes the appropriate unit / component / E2E updates.
Framework selection
Read docs/SRS.md before inspecting package files. The header Frontend-Framework: is authoritative.
If the header is one supported value, select that framework reference.
If the header is multiple, select the framework from the row that owns the task:
use SRS §3.4.2 for a surface-driven task;
use SRS §3.4.5 for a path/app-driven task;
if the task maps to more than one framework or no row matches, halt with NEEDS_CONTEXT and cite the candidate SRS rows.
If the header is N/A, do not perform FE framework implementation; report that no frontend framework applies.
If the header is missing, TBD, unsupported, or inconsistent with §3.4.2 / §3.4.5, halt and return the work to BA:
greenfield/authored SRS: BA Phase 1.X step 10c must ask the user to choose;
brownfield/extracted SRS: BA Mode E must detect from source evidence and write the SRS field.
After selecting the reference, inspect package files/source only as a consistency check. If code evidence contradicts the SRS-selected framework, halt and raise an open issue; do not silently switch references.
For mobile frameworks, the matching reference is a routing card:
React Native: always load react-native-implementation; load react-native-performance for slow/large/animated/image-heavy work; load react-native-platform-integration for native modules, permissions, deep links, app config, storage, or platform files.
Flutter: always load flutter-implementation; load flutter-performance for rebuild/jank/list/image/animation/startup work; load flutter-platform-integration for platform channels, plugins, permissions, flavors, deep links, storage, or native files.
Universal implementation procedure
Inspect nearby code before writing. Follow the project's existing folder structure, naming, state library, API client, design token system, formatter, lint rules, and test runner.
Read SRS §3.4.6 Environment Configuration before touching any API client, server URL, feature flag, analytics endpoint, or runtime config path. Use the declared frontend-owned key names and existing project config loader; if the task needs an endpoint/key that §3.4.6 does not declare, halt and raise an OQ instead of inventing a variable in code.
Map every changed screen/component to the task's SRS IDs, design handoff, Design Element Manifest, and visual spec. If the design is missing a required state, implement the required product behavior and record the design gap in the handoff or open-issues flow.
Build the screen/component from the manifest, not from memory of the screenshot:
render every required form field, label, placeholder, helper/error target, required marker, and disabled/read-only variant;
render every fixed button/link/nav/tab/chip/menu option and preserve Figma order;
render every table/list/card field, column, slot, badge, status, and counter specified by the row/card template;
render modal/toast/empty/loading/error/success copy and actions exactly when static;
reproduce the Visual Composition Contract: correct viewport variant, major region bounds, direct-child order, Auto Layout/flex/grid behavior, absolute layers, clipping/masks, overlap, and background treatment;
export and use every Asset Export Manifest row at its declared format/scales and target path, preserving fit/crop/focal point, opacity, mask, z-order, and semantics;
treat only non-rendered design-tool exclusions as non-implementation. Decorative-but-rendered imagery remains required.
Never substitute visual assets without an explicit design change. Text initials for a logo, emoji for an icon, generic icon-library glyphs, CSS approximations, stock imagery, invented gradients, and solid-color placeholders do not satisfy an AST row.
Keep boundaries explicit:
screen/page/container owns route params, data loading, permissions, and orchestration;
presentational components own layout and interaction events;
services/hooks/composables/providers own reusable data access;
shared components must stay feature-agnostic.
Implement all user-observable states: initial, loading, success, empty, validation error, recoverable error, permission denied where applicable, disabled, and optimistic rollback if optimistic UI is used.
Add or update stable selectors from docs/instrumentation-contract.md and the Design Element Manifest. Do not invent selector strings when the contract is absent; file the required contract gap and use the project convention only after it is declared.
Preserve accessibility: semantic roles / labels, focus order, keyboard interaction for web, screen-reader labels for mobile, minimum touch targets, color contrast, reduced-motion behavior when animations are present, and empty semantics for decorative imagery.
Keep data flow predictable. Prefer derived state over duplicated state. Avoid effects/listeners/subscriptions that can run repeatedly without cleanup.
Test at the right layer: unit tests for logic, component/widget tests for manifest row presence, asset-path/import tests for AST rows, structural tests for composition properties, and E2E tests for critical flows. For Visual-Critical surfaces, compare a deployed screenshot at the exact contracted viewport against the approved reference render; do not compare only against a screenshot generated from the implementation itself.
Run the project's format, lint, typecheck/analyze, and relevant tests. If a command cannot run locally, document the blocker and the narrower checks you did run.
Hard rules
Do not introduce a new FE framework, router, state library, UI kit, CSS system, or test runner unless an ADR or architecture task explicitly approves it.
Do not choose a framework from package files when docs/SRS.md declares a different Frontend-Framework:. Treat that as SRS/code drift and halt.
Do not start FE implementation while Frontend-Framework: is missing, TBD, unsupported, or multiple without a matching §3.4.2 / §3.4.5 row.
Do not rewrite established project structure to match a reference file. The reference guides decisions inside the existing architecture.
Do not ship UI code without loading, error, empty, and accessibility states for the changed surface.
Do not ship UI code that omits a Design Element Manifest row. If the implementation intentionally cannot render a row, raise an open issue and keep the task in-progress.
Do not ship UI code that omits an Asset Export Manifest row or materially changes a Visual Composition Contract row. Missing logos/backgrounds/graphics and rearranged major regions are blockers, not cosmetic follow-ups.
Do not use placeholders or approximate replacements for Figma assets unless the confirmed handoff explicitly authorizes the substitution.
Do not hardcode API/backend URLs, environment-specific endpoints, secrets, tenant IDs, locale text that belongs in i18n, or selector IDs outside the instrumentation contract. Runtime URLs must come from the SRS §3.4.6 config keys through the project config loader.
Do not bypass type errors, lints, or analyzer failures with suppressions unless the suppression is tightly scoped and justified in code.
