Back to Details

frontend-developer

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

frontend-developer

frontend-developer

Purpose

目标

Build and improve frontend code that is production-ready, understandable, and consistent with the product's intended experience.
This skill focuses on implementation quality: translating specs, repository patterns, and design guidance into reliable UI code without unnecessary complexity.
构建并改进可投入生产、易于理解且符合产品预期体验的前端代码。
本技能聚焦于实现质量：将需求规格、仓库模式和设计指引转化为可靠的UI代码，避免不必要的复杂性。

Use When

适用场景

  • The task requires creating or modifying frontend components, pages, or styles.
  • A feature needs responsive behavior, state handling, accessibility fixes, or interaction polish.
  • Existing frontend code needs cleanup to become more maintainable or scalable.
  • Design direction already exists and needs implementation in code.
  • 任务需要创建或修改前端组件、页面或样式。
  • 功能需要响应式表现、状态处理、无障碍修复或交互优化。
  • 现有前端代码需要清理以提升可维护性或可扩展性。
  • 已有设计方向，需要将其实现为代码。

Do Not Use When

不适用场景

  • The task is purely about visual exploration or interface direction.
  • The request is backend-only or infrastructure-only.
  • The work is limited to product scoping, design critique, or release note writing.
  • The codebase needs review findings more than implementation.
  • 任务仅涉及视觉探索或界面方向设计。
  • 请求仅针对后端或基础设施相关工作。
  • 工作范围仅限于产品规划、设计评审或发布说明撰写。
  • 代码库更需要评审意见而非代码实现。

Inputs

输入信息

  • User request or approved spec
  • Current repository structure and existing frontend patterns
  • Existing design system or direction from 
    frontend-design
  • Framework, styling, and state-management constraints
  • Acceptance criteria, validation needs, and browser/device expectations
  • 用户需求或已批准的规格说明
  • 当前仓库结构及现有前端模式
  • 来自
    frontend-design
    的现有设计系统或设计方向
  • 框架、样式及状态管理约束
  • 验收标准、验证需求及浏览器/设备适配要求

Outputs

输出成果

  • Implementation plan aligned to the current codebase
  • Production-ready frontend code changes
  • Validation notes for responsive behavior, accessibility, and edge states
  • Clear notes on risks, constraints, or follow-up work
  • 与当前代码库匹配的实现方案
  • 可投入生产的前端代码变更
  • 关于响应式表现、无障碍支持及边缘状态的验证说明
  • 关于风险、约束或后续工作的清晰说明

Workflow

工作流程

  1. Inspect the existing repo structure, UI patterns, and framework conventions before writing code.
  2. Identify the smallest coherent change that satisfies the request without drifting scope.
  3. Implement the UI behavior, states, and styling in a way that matches existing architecture and design direction.
  4. Validate loading, empty, error, keyboard, mobile, and desktop behavior where relevant.
  5. Summarize the change and any residual risks or missing coverage.
  1. 在编写代码前，检查现有仓库结构、UI模式及框架约定。
  2. 确定满足需求的最小连贯变更，避免超出范围。
  3. 按照现有架构和设计方向实现UI行为、状态及样式。
  4. 验证加载、空状态、错误状态、键盘交互、移动端及桌面端行为（如相关）。
  5. 总结变更内容及剩余风险或未覆盖项。

Rules

规则

  • Follow existing repository conventions before introducing a new pattern.
  • Keep components and styling maintainable instead of overly clever.
  • Implement all relevant user-visible states, not just the happy path.
  • Preserve accessibility and responsive behavior as core requirements.
  • If visual direction is still undefined, hand the decision back to 
    frontend-design
    instead of guessing a brand-new design language.
  • 在引入新模式前，遵循现有仓库约定。
  • 保持组件和样式的可维护性，避免过度设计。
  • 实现所有相关的用户可见状态，而非仅实现正常流程。
  • 将无障碍支持和响应式表现作为核心要求予以保留。
  • 若视觉方向尚未明确，将决策权交予
    frontend-design
    ，而非自行创造全新设计语言。

Checklist

检查清单

  • Loading, empty, error, and success states are handled where relevant.
  • The UI works on desktop and mobile breakpoints required by the task.
  • Keyboard, semantic, and accessibility concerns are addressed.
  • New code fits the structure and conventions of the repo.
  • Styling and interaction logic are not unnecessarily coupled or duplicated.
  • Validation notes mention any remaining risks or missing tests.
  • 相关场景下已处理加载、空状态、错误状态及成功状态。
  • UI在任务要求的桌面端和移动端断点均可正常工作。
  • 键盘交互、语义化及无障碍相关问题已解决。
  • 新代码符合仓库的结构和约定。
  • 样式与交互逻辑未出现不必要的耦合或重复。
  • 验证说明中提及了剩余风险或缺失的测试。

Non-Negotiable Rules

不可违背规则

  • Do not invent a new visual language when the task needs design direction first.
  • Do not ignore repository conventions just to make the local change faster.
  • Do not skip edge states, accessibility, or responsive behavior when they materially affect the result.
  • Do not expand scope beyond the approved implementation target.
  • 当任务需先明确设计方向时，不得自行创造新的视觉语言。
  • 不得为加快局部变更速度而忽略仓库约定。
  • 当边缘状态、无障碍支持或响应式表现对结果有实质性影响时，不得跳过这些环节。
  • 不得超出已批准的实现目标范围。

References

参考资料

  • Use the active spec, repository context, and existing frontend patterns as the primary source of truth.
  • When the experience still needs visual direction, use 
    frontend-design
    before implementation.
  • 以当前生效的规格说明、仓库上下文及现有前端模式为主要依据。
  • 当体验仍需明确视觉方向时，先使用
    frontend-design
    再进行实现。

Examples

示例

Example Trigger

示例触发条件

Implement the new dashboard filter panel in React, keeping it responsive, keyboard-friendly, and consistent with the existing component system.
在React中实现新的仪表盘筛选面板，确保其响应式、支持键盘交互，并与现有组件系统保持一致。

Example Output Shape

示例输出形式

Inspect the current frontend structure, modify the relevant components and styles, account for empty and loading states, and report the validation performed.
检查当前前端结构，修改相关组件和样式，处理空状态和加载状态，并报告已执行的验证工作。