feat: sync full workspace including web modules, docs, and configurations to Gitea

Optimized the root .gitignore to exclude virtual environments, node modules, and temp folders to ensure clean and lightweight version tracking. Co-authored-by: Cursor <cursoragent@cursor.com>
2026-06-09 18:12:25 +08:00
parent 351688006e
commit a27e3b8e43
1510 changed files with 162044 additions and 1517 deletions
--- a/axhub-make/skills/third-party/stitch-skills/design-md/SKILL.md
+++ b/axhub-make/skills/third-party/stitch-skills/design-md/SKILL.md
@@ -0,0 +1,172 @@
+---
+name: design-md
+description: Analyze Stitch projects and synthesize a semantic design system into DESIGN.md files
+allowed-tools:
+  - "stitch*:*"
+  - "Read"
+  - "Write"
+  - "web_fetch"
+---
+
+# Stitch DESIGN.md Skill
+
+You are an expert Design Systems Lead. Your goal is to analyze the provided technical assets and synthesize a "Semantic Design System" into a file named `DESIGN.md`.
+
+## Overview
+
+This skill helps you create `DESIGN.md` files that serve as the "source of truth" for prompting Stitch to generate new screens that align perfectly with existing design language. Stitch interprets design through "Visual Descriptions" supported by specific color values.
+
+## Prerequisites
+
+- Access to the Stitch MCP Server
+- A Stitch project with at least one designed screen
+- Access to the Stitch Effective Prompting Guide: https://stitch.withgoogle.com/docs/learn/prompting/
+
+## The Goal
+
+The `DESIGN.md` file will serve as the "source of truth" for prompting Stitch to generate new screens that align perfectly with the existing design language. Stitch interprets design through "Visual Descriptions" supported by specific color values.
+
+## Retrieval and Networking
+
+To analyze a Stitch project, you must retrieve screen metadata and design assets using the Stitch MCP Server tools:
+
+1. **Namespace discovery**: Run `list_tools` to find the Stitch MCP prefix. Use this prefix (e.g., `mcp_stitch:`) for all subsequent calls.
+
+2. **Project lookup** (if Project ID is not provided):
+   - Call `[prefix]:list_projects` with `filter: "view=owned"` to retrieve all user projects
+   - Identify the target project by title or URL pattern
+   - Extract the Project ID from the `name` field (e.g., `projects/13534454087919359824`)
+
+3. **Screen lookup** (if Screen ID is not provided):
+   - Call `[prefix]:list_screens` with the `projectId` (just the numeric ID, not the full path)
+   - Review screen titles to identify the target screen (e.g., "Home", "Landing Page")
+   - Extract the Screen ID from the screen's `name` field
+
+4. **Metadata fetch**: 
+   - Call `[prefix]:get_screen` with both `projectId` and `screenId` (both as numeric IDs only)
+   - This returns the complete screen object including:
+     - `screenshot.downloadUrl` - Visual reference of the design
+     - `htmlCode.downloadUrl` - Full HTML/CSS source code
+     - `width`, `height`, `deviceType` - Screen dimensions and target platform
+     - Project metadata including `designTheme` with color and style information
+
+5. **Asset download**:
+   - Use `web_fetch` or `read_url_content` to download the HTML code from `htmlCode.downloadUrl`
+   - Optionally download the screenshot from `screenshot.downloadUrl` for visual reference
+   - Parse the HTML to extract Tailwind classes, custom CSS, and component patterns
+
+6. **Project metadata extraction**:
+   - Call `[prefix]:get_project` with the project `name` (full path: `projects/{id}`) to get:
+     - `designTheme` object with color mode, fonts, roundness, custom colors
+     - Project-level design guidelines and descriptions
+     - Device type preferences and layout principles
+
+## Analysis & Synthesis Instructions
+
+### 1. Extract Project Identity (JSON)
+- Locate the Project Title
+- Locate the specific Project ID (e.g., from the `name` field in the JSON)
+
+### 2. Define the Atmosphere (Image/HTML)
+Evaluate the screenshot and HTML structure to capture the overall "vibe." Use evocative adjectives to describe the mood (e.g., "Airy," "Dense," "Minimalist," "Utilitarian").
+
+### 3. Map the Color Palette (Tailwind Config/JSON)
+Identify the key colors in the system. For each color, provide:
+- A descriptive, natural language name that conveys its character (e.g., "Deep Muted Teal-Navy")
+- The specific hex code in parentheses for precision (e.g., "#294056")
+- Its specific functional role (e.g., "Used for primary actions")
+
+### 4. Translate Geometry & Shape (CSS/Tailwind)
+Convert technical `border-radius` and layout values into physical descriptions:
+- Describe `rounded-full` as "Pill-shaped"
+- Describe `rounded-lg` as "Subtly rounded corners"
+- Describe `rounded-none` as "Sharp, squared-off edges"
+
+### 5. Describe Depth & Elevation
+Explain how the UI handles layers. Describe the presence and quality of shadows (e.g., "Flat," "Whisper-soft diffused shadows," or "Heavy, high-contrast drop shadows").
+
+## Output Guidelines
+
+- **Language:** Use descriptive design terminology and natural language exclusively
+- **Format:** Generate a clean Markdown file following the structure below
+- **Precision:** Include exact hex codes for colors while using descriptive names
+- **Context:** Explain the "why" behind design decisions, not just the "what"
+
+## Output Format (DESIGN.md Structure)
+
+```markdown
+# Design System: [Project Title]
+**Project ID:** [Insert Project ID Here]
+
+## 1. Visual Theme & Atmosphere
+(Description of the mood, density, and aesthetic philosophy.)
+
+## 2. Color Palette & Roles
+(List colors by Descriptive Name + Hex Code + Functional Role.)
+
+## 3. Typography Rules
+(Description of font family, weight usage for headers vs. body, and letter-spacing character.)
+
+## 4. Component Stylings
+* **Buttons:** (Shape description, color assignment, behavior).
+* **Cards/Containers:** (Corner roundness description, background color, shadow depth).
+* **Inputs/Forms:** (Stroke style, background).
+
+## 5. Layout Principles
+(Description of whitespace strategy, margins, and grid alignment.)
+```
+
+## Usage Example
+
+To use this skill for the Furniture Collection project:
+
+1. **Retrieve project information:**
+   ```
+   Use the Stitch MCP Server to get the Furniture Collection project
+   ```
+
+2. **Get the Home page screen details:**
+   ```
+   Retrieve the Home page screen's code, image, and screen object information
+   ```
+
+3. **Reference best practices:**
+   ```
+   Review the Stitch Effective Prompting Guide at:
+   https://stitch.withgoogle.com/docs/learn/prompting/
+   ```
+
+4. **Analyze and synthesize:**
+   - Extract all relevant design tokens from the screen
+   - Translate technical values into descriptive language
+   - Organize information according to the DESIGN.md structure
+
+5. **Generate the file:**
+   - Create `DESIGN.md` in the project directory
+   - Follow the prescribed format exactly
+   - Ensure all color codes are accurate
+   - Use evocative, designer-friendly language
+
+## Best Practices
+
+- **Be Descriptive:** Avoid generic terms like "blue" or "rounded." Use "Ocean-deep Cerulean (#0077B6)" or "Gently curved edges"
+- **Be Functional:** Always explain what each design element is used for
+- **Be Consistent:** Use the same terminology throughout the document
+- **Be Visual:** Help readers visualize the design through your descriptions
+- **Be Precise:** Include exact values (hex codes, pixel values) in parentheses after natural language descriptions
+
+## Tips for Success
+
+1. **Start with the big picture:** Understand the overall aesthetic before diving into details
+2. **Look for patterns:** Identify consistent spacing, sizing, and styling patterns
+3. **Think semantically:** Name colors by their purpose, not just their appearance
+4. **Consider hierarchy:** Document how visual weight and importance are communicated
+5. **Reference the guide:** Use language and patterns from the Stitch Effective Prompting Guide
+
+## Common Pitfalls to Avoid
+
+- ❌ Using technical jargon without translation (e.g., "rounded-xl" instead of "generously rounded corners")
+- ❌ Omitting color codes or using only descriptive names
+- ❌ Forgetting to explain functional roles of design elements
+- ❌ Being too vague in atmosphere descriptions
+- ❌ Ignoring subtle design details like shadows or spacing patterns
--- a/axhub-make/skills/third-party/stitch-skills/react-components/SKILL.md
+++ b/axhub-make/skills/third-party/stitch-skills/react-components/SKILL.md
@@ -0,0 +1,47 @@
+---
+name: react:components
+description: Converts Stitch designs into modular Vite and React components using system-level networking and AST-based validation.
+allowed-tools:
+  - "stitch*:*"
+  - "Bash"
+  - "Read"
+  - "Write"
+  - "web_fetch"
+---
+
+# Stitch to React Components
+
+You are a frontend engineer focused on transforming designs into clean React code. You follow a modular approach and use automated tools to ensure code quality.
+
+## Retrieval and networking
+1. **Namespace discovery**: Run `list_tools` to find the Stitch MCP prefix. Use this prefix (e.g., `stitch:`) for all subsequent calls.
+2. **Metadata fetch**: Call `[prefix]:get_screen` to retrieve the design JSON.
+3. **High-reliability download**: Internal AI fetch tools can fail on Google Cloud Storage domains.
+   - Use the `Bash` tool to run: `bash scripts/fetch-stitch.sh "[htmlCode.downloadUrl]" "temp/source.html"`.
+   - This script handles the necessary redirects and security handshakes.
+4. **Visual audit**: Check `screenshot.downloadUrl` to confirm the design intent and layout details.
+
+## Architectural rules
+* **Modular components**: Break the design into independent files. Avoid large, single-file outputs.
+* **Logic isolation**: Move event handlers and business logic into custom hooks in `src/hooks/`.
+* **Data decoupling**: Move all static text, image URLs, and lists into `src/data/mockData.ts`.
+* **Type safety**: Every component must include a `Readonly` TypeScript interface named `[ComponentName]Props`.
+* **Project specific**: Focus on the target project's needs and constraints. Leave Google license headers out of the generated React components.
+* **Style mapping**:
+    * Extract the `tailwind.config` from the HTML `<head>`.
+    * Sync these values with `resources/style-guide.json`.
+    * Use theme-mapped Tailwind classes instead of arbitrary hex codes.
+
+## Execution steps
+1. **Environment setup**: If `node_modules` is missing, run `npm install` to enable the validation tools.
+2. **Data layer**: Create `src/data/mockData.ts` based on the design content.
+3. **Component drafting**: Use `resources/component-template.tsx` as a base. Find and replace all instances of `StitchComponent` with the actual name of the component you are creating.
+4. **Application wiring**: Update the project entry point (like `App.tsx`) to render the new components.
+5. **Quality check**:
+    * Run `npm run validate <file_path>` for each component.
+    * Verify the final output against the `resources/architecture-checklist.md`.
+    * Start the dev server with `npm run dev` to verify the live result.
+
+## Troubleshooting
+* **Fetch errors**: Ensure the URL is quoted in the bash command to prevent shell errors.
+* **Validation errors**: Review the AST report and fix any missing interfaces or hardcoded styles.
--- a/axhub-make/skills/third-party/stitch-skills/stitch-loop/SKILL.md
+++ b/axhub-make/skills/third-party/stitch-skills/stitch-loop/SKILL.md
@@ -0,0 +1,203 @@
+---
+name: stitch-loop
+description: Teaches agents to iteratively build websites using Stitch with an autonomous baton-passing loop pattern
+allowed-tools:
+  - "stitch*:*"
+  - "chrome*:*"
+  - "Read"
+  - "Write"
+  - "Bash"
+---
+
+# Stitch Build Loop
+
+You are an **autonomous frontend builder** participating in an iterative site-building loop. Your goal is to generate a page using Stitch, integrate it into the site, and prepare instructions for the next iteration.
+
+## Overview
+
+The Build Loop pattern enables continuous, autonomous website development through a "baton" system. Each iteration:
+1. Reads the current task from a baton file (`next-prompt.md`)
+2. Generates a page using Stitch MCP tools
+3. Integrates the page into the site structure
+4. Writes the next task to the baton file for the next iteration
+
+## Prerequisites
+
+**Required:**
+- Access to the Stitch MCP Server
+- A Stitch project (existing or will be created)
+- A `DESIGN.md` file (generate one using the `design-md` skill if needed)。注意：若用户已在管理后台"设为默认主题"，则根目录会自动同步该主题的 `DESIGN.md`，优先使用根目录版本
+- A `SITE.md` file documenting the site vision and roadmap
+
+**Optional:**
+- Chrome DevTools MCP Server — enables visual verification of generated pages
+
+## The Baton System
+
+The `next-prompt.md` file acts as a relay baton between iterations:
+
+```markdown
+---
+page: about
+---
+A page describing how jules.top tracking works.
+
+**DESIGN SYSTEM (REQUIRED):**
+[Copy from DESIGN.md Section 6]
+
+**Page Structure:**
+1. Header with navigation
+2. Explanation of tracking methodology
+3. Footer with links
+```
+
+**Critical rules:**
+- The `page` field in YAML frontmatter determines the output filename
+- The prompt content must include the design system block from `DESIGN.md`
+- You MUST update this file before completing your work to continue the loop
+
+## Execution Protocol
+
+### Step 1: Read the Baton
+
+Parse `next-prompt.md` to extract:
+- **Page name** from the `page` frontmatter field
+- **Prompt content** from the markdown body
+
+### Step 2: Consult Context Files
+
+Before generating, read these files:
+
+| File | Purpose |
+|------|---------|
+| `SITE.md` | Site vision, **Stitch Project ID**, existing pages (sitemap), roadmap |
+| `DESIGN.md` | Required visual style for Stitch prompts |
+
+**Important checks:**
+- Section 4 (Sitemap) — Do NOT recreate pages that already exist
+- Section 5 (Roadmap) — Pick tasks from here if backlog exists
+- Section 6 (Creative Freedom) — Ideas for new pages if roadmap is empty
+
+### Step 3: Generate with Stitch
+
+Use the Stitch MCP tools to generate the page:
+
+1. **Discover namespace**: Run `list_tools` to find the Stitch MCP prefix
+2. **Get or create project**: 
+   - If `stitch.json` exists, use the `projectId` from it
+   - Otherwise, call `[prefix]:create_project` and save the ID to `stitch.json`
+3. **Generate screen**: Call `[prefix]:generate_screen_from_text` with:
+   - `projectId`: The project ID
+   - `prompt`: The full prompt from the baton (including design system block)
+   - `deviceType`: `DESKTOP` (or as specified)
+4. **Retrieve assets**: Call `[prefix]:get_screen` to get:
+   - `htmlCode.downloadUrl` — Download and save as `queue/{page}.html`
+   - `screenshot.downloadUrl` — Download and save as `queue/{page}.png`
+
+### Step 4: Integrate into Site
+
+1. Move generated HTML from `queue/{page}.html` to `site/public/{page}.html`
+2. Fix any asset paths to be relative to the public folder
+3. Update navigation:
+   - Find existing placeholder links (e.g., `href="#"`) and wire them to the new page
+   - Add the new page to the global navigation if appropriate
+4. Ensure consistent headers/footers across all pages
+
+### Step 4.5: Visual Verification (Optional)
+
+If the **Chrome DevTools MCP Server** is available, verify the generated page:
+
+1. **Check availability**: Run `list_tools` to see if `chrome*` tools are present
+2. **Start dev server**: Use Bash to start a local server (e.g., `npx serve site/public`)
+3. **Navigate to page**: Call `[chrome_prefix]:navigate` to open `http://localhost:3000/{page}.html`
+4. **Capture screenshot**: Call `[chrome_prefix]:screenshot` to capture the rendered page
+5. **Visual comparison**: Compare against the Stitch screenshot (`queue/{page}.png`) for fidelity
+6. **Stop server**: Terminate the dev server process
+
+> **Note:** This step is optional. If Chrome DevTools MCP is not installed, skip to Step 5.
+
+### Step 5: Update Site Documentation
+
+Modify `SITE.md`:
+- Add the new page to Section 4 (Sitemap) with `[x]`
+- Remove any idea you consumed from Section 6 (Creative Freedom)
+- Update Section 5 (Roadmap) if you completed a backlog item
+
+### Step 6: Prepare the Next Baton (Critical)
+
+**You MUST update `next-prompt.md` before completing.** This keeps the loop alive.
+
+1. **Decide the next page**: 
+   - Check `SITE.md` Section 5 (Roadmap) for pending items
+   - If empty, pick from Section 6 (Creative Freedom)
+   - Or invent something new that fits the site vision
+2. **Write the baton** with proper YAML frontmatter:
+
+```markdown
+---
+page: achievements
+---
+A competitive achievements page showing developer badges and milestones.
+
+**DESIGN SYSTEM (REQUIRED):**
+[Copy the entire design system block from DESIGN.md]
+
+**Page Structure:**
+1. Header with title and navigation
+2. Badge grid showing unlocked/locked states
+3. Progress bars for milestone tracking
+```
+
+## File Structure Reference
+
+```
+project/
+├── next-prompt.md      # The baton — current task
+├── stitch.json         # Stitch project ID (persist this!)
+├── DESIGN.md           # Visual design system (from design-md skill)
+├── SITE.md             # Site vision, sitemap, roadmap
+├── queue/              # Staging area for Stitch output
+│   ├── {page}.html
+│   └── {page}.png
+└── site/public/        # Production pages
+    ├── index.html
+    └── {page}.html
+```
+
+## Orchestration Options
+
+The loop can be driven by different orchestration layers:
+
+| Method | How it works |
+|--------|--------------|
+| **CI/CD** | GitHub Actions triggers on `next-prompt.md` changes |
+| **Human-in-loop** | Developer reviews each iteration before continuing |
+| **Agent chains** | One agent dispatches to another (e.g., Jules API) |
+| **Manual** | Developer runs the agent repeatedly with the same repo |
+
+The skill is orchestration-agnostic — focus on the pattern, not the trigger mechanism.
+
+## Design System Integration
+
+This skill works best with the `design-md` skill:
+
+1. **First time setup**: Generate `DESIGN.md` using the `design-md` skill from an existing Stitch screen
+2. **Every iteration**: Copy Section 6 ("Design System Notes for Stitch Generation") into your baton prompt
+3. **Consistency**: All generated pages will share the same visual language
+
+## Common Pitfalls
+
+- ❌ Forgetting to update `next-prompt.md` (breaks the loop)
+- ❌ Recreating a page that already exists in the sitemap
+- ❌ Not including the design system block in the prompt
+- ❌ Leaving placeholder links (`href="#"`) instead of wiring real navigation
+- ❌ Forgetting to persist `stitch.json` after creating a new project
+
+## Troubleshooting
+
+| Issue | Solution |
+|-------|----------|
+| Stitch generation fails | Check that the prompt includes the design system block |
+| Inconsistent styles | Ensure DESIGN.md is up-to-date and copied correctly |
+| Loop stalls | Verify `next-prompt.md` was updated with valid frontmatter |
+| Navigation broken | Check all internal links use correct relative paths |
--- a/axhub-make/skills/third-party/stitch-skills/stitch-main-workflow/SKILL.md
+++ b/axhub-make/skills/third-party/stitch-skills/stitch-main-workflow/SKILL.md
@@ -0,0 +1,127 @@
+---
+name: stitch-main-workflow
+description: 本项目 Stitch 主技能/总编排：先完成 spec.md，再完成并确认 Stitch 设计，最后才允许生成 index.tsx；若 Stitch MCP 不可用则立即停止。
+allowed-tools:
+  - "stitch*:*"
+  - "Read"
+  - "Write"
+  - "Bash"
+  - "web_fetch"
+  - "chrome*:*"
+---
+
+# Stitch 主流程（总编排）
+
+本技能用于把 `design-md` / `stitch-loop` / `react-components` 组织为统一流程，强制执行：
+
+1. 先完成 `spec.md`
+2. 再完成并确认 Stitch 设计
+3. 最后才允许创建或修改 `index.tsx`
+
+## 目标与硬门槛（必须满足）
+
+- **硬门槛 1**：未完成 Stitch 设计确认前，不允许创建或修改 `src/prototypes/<name>/index.tsx` 或 `src/components/<name>/index.tsx`。
+- **硬门槛 2**：如果 Stitch MCP 不可用或调用失败，必须直接反馈并停止，不进入代码生成阶段。
+
+## 环境自检（阻塞，失败即停）
+
+开始主流程前，必须先做一次 Stitch MCP 探针调用，再决定是否继续：
+
+- 可用探针示例：`list_projects` 或 `create_project`
+- 探针成功：继续执行主流程
+- 探针失败：输出以下固定反馈并停止
+
+```text
+⚠️ 当前环境未启用 Stitch MCP（无法调用 Stitch 工具），因此无法在 index.tsx 前完成 Stitch 设计。请启用 Stitch MCP 后重试。
+```
+
+## 主流程（顺序固定）
+
+### 1) 准备目标路径
+
+- 目标目录只能是：
+  - `src/prototypes/<name>/`
+  - `src/components/<name>/`
+- `<name>` 只能使用小写字母、数字、连字符（kebab-case）
+
+### 2) 先完成 `spec.md`（作为 Stitch prompt 合同）
+
+- 按 `src/docs/templates/spec-template.md` 产出 `spec.md`（本技能不重复展开模板细节）
+- `spec.md` 至少包含：
+  - 目标
+  - 模块 IA（树形结构）
+  - 关键文案语气
+  - 数据字段
+  - 响应式要点
+
+### 3) 使用 Stitch 完成“设计”并确认
+
+> **根目录 `DESIGN.md` 自动同步**：当用户在管理后台“设为默认主题”时，该主题的 `DESIGN.md` 会被自动同步到项目根目录（`/DESIGN.md`）。如果根目录存在此文件且用户没有特殊指定，应默认将其内容提交给 Stitch 作为设计规范进行生成。
+
+1. （可选）如需风格统一，先用 `design-md` 从既有 Stitch screen 生成 `DESIGN.md`；或直接使用根目录已同步的 `DESIGN.md`
+2. 使用 `generate_screen_from_text`，prompt 以 `spec.md` 为基础；若有 `DESIGN.md`（优先检查根目录），把设计系统相关内容并入 prompt
+3. 使用 `get_screen` 获取最终候选 screen 的 `screenshot` 与 `htmlCode`
+4. 如果结果不符合 `spec.md`，使用 `edit_screens` 迭代，直到满足
+5. 设计确认最小产物：
+  - `screenshot`
+  - `html`
+
+本地保存建议放在 `temp/` 或 `.drafts/`（两者都被 `.gitignore` 忽略）。
+
+### 3.5) 交互与响应式提醒（按用户需求为准，不以 Stitch 产物为准）
+
+Stitch 产物偏静态（HTML/CSS），经常会出现“截图对齐了，但交互/响应式并不等同于需求”的情况。这里不把检查做成硬门槛，但你必须遵守一个原则：
+
+- **交互与响应式的验收基准永远来自用户需求 / `spec.md`**，不要把 Stitch 输出当成“需求本身”或“默认标准”。
+
+按需做快速核对（仅在 `spec.md` 明确要求时）：
+
+- **响应式**：如果 `spec.md` 要求断点/多端适配，就检查对应设备下是否塌陷、溢出、信息层级是否仍成立。
+- **交互状态**：如果 `spec.md` 要求交互/可访问性，就核对 hover/focus/disabled 等状态与键盘可达性是否满足。
+- **动态交互**：如果需求包含弹窗、抽屉、复杂表单校验、异步加载等 Stitch 难以表达的动态行为，应在 `spec.md` 明确标注为“代码阶段补齐”，避免误判“设计已完成”。
+
+> 可选：若当前环境提供 Chrome MCP，可用它辅助做“缩放/断点切换 + 截图”验证，作为发现问题的手段即可。
+
+### 4) 回写 `spec.md`（与 Stitch 最终设计对齐）
+
+在 `spec.md` 中补齐以下字段：
+
+- Stitch `projectId`
+- Stitch `screenId`
+- 截图本地保存路径
+- HTML 本地保存路径
+- 最终模块结构确认点
+
+### 5) 最后生成 `index.tsx`（从 Stitch 设计落地）
+
+本主流程只负责编排与 gate，具体转换实现参考：
+
+- `skills/third-party/stitch-skills/react-components/SKILL.md`
+
+本项目最小必须约束（仅保留以下）：
+
+- `index.tsx` 顶部必须包含 `@name` 中文注释块（参考 `rules/development-guide.md`）
+- 组件或页面必须 `export default`（参考 `vite-plugins/axhubComponentEnforcer.ts`）
+- 使用 Tailwind 时，`style.css` 顶部必须包含 `@import "tailwindcss";`
+
+### 6) 验收（必须跑完）
+
+按目标类型执行验收脚本，结果必须为 `READY`：
+
+```bash
+node scripts/check-app-ready.mjs /prototypes/<name>
+node scripts/check-app-ready.mjs /components/<name>
+```
+
+## 技能路由指南（触发条件 -> 使用技能 -> 产出）
+
+| 触发条件 | 使用技能 | 产出 |
+|---|---|---|
+| 已有 Stitch 设计，或多页需要统一风格 | `design-md` | `DESIGN.md`，供后续 prompt 复用 |
+| 需要多页迭代、baton 编排建站 | `stitch-loop` | 循环生成多页 screen 与任务接力 |
+| 需要把 Stitch HTML/设计落地成 React 代码 | `react-components` | 组件/页面代码，并对齐 `@name`、默认导出、Tailwind 引入约束 |
+
+## 说明与非目标
+
+- 本技能不重复展开“必读规范”的详细说明，只做最小引用（默认已完成基础规范阅读）。
+- 本技能不要求额外平台接口适配约束；只要求本项目最小代码约束与验收通过。