/gemini-frontend

gemini-frontend - Gemini CLI 前端开发专用 Skill

Description

专注于前端和移动端开发的 skill，通过 Gemini CLI（via clink）发挥多模态和超长上下文优势。

**适用场景：**

• React/Vue/Angular 组件开发
• React Native/Flutter 移动端开发
• 设计稿 → 前端代码实现
• UI/UX 实现和优化
• 前端项目重构

**核心优势（基于 Gemini 3.0）：**

• 📷 **多模态能力**：直接理解设计稿、UI 截图
• 📚 **超长上下文**：100万 token，处理大型 monorepo
• 🎨 **UI 理解**：博士级推理能力，理解复杂 UI 逻辑
• 🚀 **代码生成**：擅长 React/Vue/Flutter 代码生成

---

⚠️ 重要说明

**阶段命名澄清：**

• 本 skill 的 **Phase 1-5** 是内部工作流阶段（Skill-level phases）
• 与 CLAUDE.md 的 **P1-P4**（分析问题、制定方案、执行方案、错误处理）是不同层级
• gemini-frontend 通常在 **P3（执行方案）** 阶段被 main-router 调用
• Phase 1-5 是在 P3 阶段内部顺序执行的子步骤

**层级关系示例：**

P3（执行方案） [CLAUDE.md 项目阶段]
  └─ gemini-frontend skill [由 main-router 调用]
      ├─ Phase 1: 初始化 Gemini CLI 会话
      ├─ Phase 2: 需求分析与设计
      ├─ Phase 3: 代码生成
      ├─ Phase 4: 质量检查
      └─ Phase 5: 文档生成

---

How It's Invoked（如何被调用）

**调用方式：** 由 **main-router skill** 自动路由

**路由触发条件：**

• 用户请求包含前端框架关键词（React, Vue, Angular, Flutter, React Native）
• 用户请求包含 UI/组件/页面 等关键词
• 用户提供设计稿/UI 截图
• frontend_score ≥ 50（参见 main-router 评分机制）

**评分机制详解：**

main-router 使用以下评分规则判断是否路由到 gemini-frontend：

| 评分项 | 分值 | 示例关键词 | |--------|------|------------| | Tier 1 关键词 | +30~35分 | React, Vue, Angular, component, 组件, 页面, UI, 前端 | | Tier 2 关键词 | +15~20分 | Flutter, React Native, mobile, 移动端, iOS, Android | | Tier 3 上下文 | +10分 | package.json 存在且包含前端依赖 | | 图片附件 | +25分 | 设计稿、UI 截图 | | 后端信号抵消 | -15~-25分 | API, backend, database, FastAPI, Django |

**路由决策阈值：**

• **Score ≥ 80**：自动路由到 gemini-frontend（高置信度）
• **Score 50-79**：询问用户是否使用 gemini-frontend（中置信度）
• **Score < 50 且 backend_signals ≥ 2**：全栈项目，建议任务分解

**参数继承：**

• `automation_mode`: 从 main-router 继承（见 CLAUDE.md 共享概念）
• `coverage_target`: 从 main-router 继承（默认 85%，最低 70%）

**示例流程：**

用户请求: "帮我开发一个 React 登录组件"
  ↓
main-router 检测:
  - "React" (Tier 1) → +35分
  - "组件" (Tier 1) → +30分
  - 总分: 65分
  ↓
路由决策: 50 ≤ 65 < 80 → 询问用户
  ↓
用户确认: "是"
  ↓
调用 gemini-frontend skill
  ↓
gemini-frontend 执行 Phase 1-5
  ↓
返回完整的 React 组件 + 文档 + 质量报告

**详细示例：** 参见 `skills/main-router/references/routing_examples.md` 示例 12-13

---

Workflow（5 阶段工作流）

Phase 1: 初始化 Gemini CLI 会话

**目标：** 通过 clink 启动 Gemini CLI，建立会话上下文

**操作：**

session = clink(
    prompt="启动 Gemini CLI 进行前端开发",
    cli_name="gemini",
    role="default"
)
session_id = session["continuation_id"]

**环境自适应（G10 合规）：**

在调用 clink 前，必须检测操作系统环境：

import platform
import os

def get_cli_environment():
    """环境自适应 CLI 调用（遵循 G10 规范）"""
    os_type = platform.system()

    if os_type == "Windows":
        # 检测是否在 WSL 中
        if os.path.exists("/mnt/c"):
            return "wsl"
        else:
            return "windows"
    elif os_type == "Linux":
        return "linux"
    elif os_type == "Darwin":
        return "macos"
    else:
        raise EnvironmentError(f"不支持的操作系统: {os_type}")

# Phase 1 中使用环境自适应
env = get_cli_environment()
session = clink(
    prompt="启动 Gemini CLI 进行前端开发",
    cli_name="gemini",
    role="default"
)

**重要提示：** 详见 `references/standards/cli_env_g10.md` 获取完整的环境自适应规范。

**输出：** Gemini CLI 会话 ID（用于后续 Phase）

---

Phase 2: 需求分析与设计

**目标：** 利用 Gemini 多模态能力分析前端需求

**操作：**

analysis = clink(
    prompt=f"""
    分析以下前端需求：
    {user_request}

    **前置检查（G6 合规 - 遵循既有架构决策）：**
    1. 读取 PROJECTWIKI.md 的 ADR（Architecture Decision Record）部分
    2. 检查现有架构决策是否与本次需求冲突
    3. 如有冲突，提供替代方案或修订建议
    4. 标注需要遵循的架构约束

    请提供：
    1. 组件架构设计（遵循既有 ADR 和架构决策）
    2. 状态管理方案（符合项目现有模式）
    3. 样式实现策略（遵循项目规范）
    4. 技术栈建议（考虑现有技术栈兼容性）
    5. ADR 冲突检查结果（如有）
    """,
    cli_name="gemini",
    files=design_files + ["PROJECTWIKI.md"] if design_files else ["PROJECTWIKI.md"],  # 包含项目文档
    continuation_id=session_id
)

**特殊处理：**

• 如有设计稿/UI 截图，通过 `files` 参数传递
• Gemini 会自动识别图片内容并生成对应代码

**输出：** 前端设计方案（架构、状态管理、样式策略）

---

Phase 3: 代码生成

**目标：** Gemini 生成高质量前端代码

**操作：**

code = clink(
    prompt="""
    基于上述设计方案，生成完整的前端代码，包括：
    1. 组件代码（.tsx/.vue）
    2. 样式文件（.css/.scss/Tailwind）
    3. 类型定义（TypeScript）
    4. 状态管理代码（Redux/Zustand）
    5. 单元测试（Jest/Vitest）

    确保：
    - 代码符合最佳实践
    - 遵循项目现有规范
    - 包含必要的注释
    - 类型安全
    """,
    cli_name="gemini",
    continuation_id=session_id
)

**输出：** 完整的前端代码文件

---

Phase 4: 质量检查（强制，双重验证）

**目标：** 确保代码质量达到发布标准

**操作（强制双轮）：**

**第 1 轮：codereview 工作流验证**

review_round1 = codereview(
    code=code,
    review_type="full",  # 全面审查
    focus_on="frontend",  # 前端特定检查
    standards="项目前端规范"
)

**第 2 轮：codex CLI 深度分析**

# 启动 codex CLI
codex_session = clink(
    prompt="启动 codex CLI 进行代码审查",
    cli_name="codex",
    role="codereviewer"
)

# 深度分析
review_round2 = clink(
    prompt=f"""
    深度审查以下前端代码：
    {code}

    重点关注：
    1. React/Vue 最佳实践
    2. 性能优化（Lazy Loading、Memoization）
    3. 可访问性（a11y）
    4. 安全性（XSS、CSRF）
    5. 类型安全
    """,
    cli_name="codex",
    continuation_id=codex_session["continuation_id"]
)

**质量闸门（必须通过）：**

• 代码质量评分 ≥ 85%
• 无 Critical/High 级别问题
• 类型检查通过
• 测试覆盖率 ≥ coverage_target（从 router 继承）

**如不合格：**

# Gemini 修复（最多 3 轮）
for i in range(3):
    if review["quality_score"] >= 85:
        break

    code = clink(
        prompt=f"修复以下问题：\n{review['issues']}",
        cli_name="gemini",
        continuation_id=session_id
    )

    review = codereview(code)

**可选增强（Gemini 2.5 Pro 建议）：**

# 静态分析 Linting
npm run lint
npm run type-check

**输出：** 质量检查报告 + 修复后的代码

---

Phase 5: 文档生成

**目标：** 更新项目文档

**操作：**

docs = simple_gemini(
    prompt="""
    更新 PROJECTWIKI.md，包括：

    1. 新增组件文档
    2. API 使用示例
    3. 组件 Props 说明

    **4. 架构图更新（Mermaid）- G4 合规要求：**
       - 更新组件依赖关系图（使用 flowchart）
       - 更新数据流图（使用 sequenceDiagram）
       - 标注新增组件的位置和关系
       - 清理过时的架构节点
       - 提供节点 ID ↔ 代码路径映射表

       示例：
       \```mermaid
       flowchart TD
           App[App] --> LoginForm[LoginForm 组件]
           LoginForm --> AuthService[认证服务]
           AuthService --> API[Backend API]
       \```

    5. CHANGELOG.md 更新（遵循 Keep a Changelog 格式）
    6. 建立