Write Front-End Code Skill

Purpose

Write front-end code that is clean, correctly placed, consistent with project conventions, and free of unnecessary complexity, duplication, or boundary violations.

When to Use

• Implementing UI logic, components, hooks, or styles for a planned feature.
• Editing existing front-end code to add or change behavior.
• Any task that produces or modifies .tsx/.jsx/.ts/.js/style files in the front-end layers.

When Not to Use

• Pure backend/database work with no front-end code involved (see Database and Backend Logic Skill).
• Page/route composition specifically when the work is primarily about assembling existing components into a screen (see Assemble Page or Screen Skill) — though this skill's rules still apply to any code written there.

Required Inputs

• The plan or task description (from Plan the Feature Skill if applicable).
• Project conventions from Understand the Project Skill (framework, folder structure, styling, state).
• Existing related components/hooks/services to extend or follow as patterns.

Assumptions

• Existing project structure and conventions take precedence over the default rule of thumb.
• Code should preserve existing behavior unless the task asks for a behavior change.

Step-by-Step Workflow

1. Confirm placement: determine the correct file/folder for this code based on responsibility:

• Reusable UI → /components (or project equivalent).
• Helper/utility logic → /lib.
• API/business calls → /services.
• React logic (custom hooks) → /hooks.
• Global state → /store.
• Types → /types.
• Routes/screens → /app (or framework's routing convention).

1. Check for existing code to reuse or extend before writing new code (components, hooks, utilities, types).
2. Write the implementation:

• Keep functions and components focused on one responsibility.
• Use clear, descriptive names — avoid data, temp, stuff, helper, newThing unless context makes them unambiguous.
• Keep nesting shallow; extract logic into named functions/hooks when it improves clarity.
• Avoid duplicating logic that already exists elsewhere — extract shared logic only if reuse is real.

1. Apply styling per project convention (CSS Modules, Tailwind, etc.); keep component styles co-located with the component, not in route files or scattered globals.
2. Apply state per convention: local state first, then shared/global only if truly needed (see Manage State Skill).
3. Handle states relevant to the UI: loading, error, empty, success/disabled — at minimum acknowledge them even if handled by a child component.
4. Type everything (if TypeScript): define/extend types in /types or co-located as per convention; avoid any/as any.
5. Clean up before finishing: remove unused imports/variables, commented-out code, stray console.logs, and placeholder TODOs that aren't tied to a real follow-up.

Rules and Best Practices

• Preserve existing behavior unless the task explicitly requires a change.
• Prefer small, correct changes over large rewrites.
• Reuse existing components/hooks/services/types before creating new ones.
• Keep route/page files focused on composition — don't embed large UI blocks, component CSS, or business logic there (see Assemble Page or Screen Skill).
• Keep API calls out of UI components — use the services/data layer.
• Keep styling consistent with the existing approach; don't introduce a new styling system without approval.
• Don't use hard-coded spacing/colors/typography when tokens exist.
• Don't introduce a new dependency without flagging it (see Dependency and Config Skill).

Safety Checks

• Changes to shared components/hooks/utilities affect multiple call sites — check usages before changing signatures or default behavior.
• Don't remove error handling, loading states, or accessibility features while editing for another purpose.

Validation Checks

• Confirm the file is placed according to project convention/responsibility.
• Confirm no unused imports, dead code, or stray logs remain.
• Confirm types are correct and no any/type bypasses were introduced without justification.
• Confirm existing behavior elsewhere wasn't broken (check other usages of changed shared code).
• Run relevant lint/typecheck if available (see Validate and Test Skill).

Common Mistakes to Avoid

• Putting reusable UI, component styles, or business logic inside route/page files.
• Duplicating an existing component, hook, or utility instead of reusing/extending it.
• Using any/as any to silence type errors.
• Leaving commented-out code, debug logs, or vague TODOs.
• Introducing a new state library or styling system without approval.
• Large, sweeping rewrites when a small targeted change would do.

Output Rule

Do not invent a custom final response format for this skill. Follow the Global Agent Output and Reporting Skill. Only include skill-specific reporting details when necessary for understanding the completed work.