SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillslocal-axure-workflow

local-axure-workflow

Office & productivity

View repository

Updated 10-16 00:00

About this skill

Local Axure Resource Processing Specification

Process locally exported Axure prototype resources, including theme extraction, data model identification, and page restoration.

Core Capabilities

  1. Theme Extraction and Merging: Extract design tokens from multiple pages and merge them to generate a unified theme file
  2. Data Model Identification: Identify data structures from page content and generate database files
  3. Page Restoration: Precise restoration based on screenshots, themes, and content
  4. MCP Supplement: Optionally use MCP tools to obtain online resources (such as sitemap.json containing projectUrl)

Local Resource Directory Structure

<project-dir>/
├── sitemap.json              # 站点地图
└── page-<index>-<name>/      # 页面目录
    ├── assets/
    │   ├── images/           # 图片资源
    │   └── fonts/            # 字体资源（如有）
    ├── theme.json            # 设计令牌（Top10）
    ├── content.md            # 页面内容（Markdown）
    └── screenshot.png        # 页面截图

Key File Descriptions

  • sitemap.json: Project name, page list, prototype URL (if any)
  • theme.json: Design tokens (colors, typography, spacing, radius, shadow, etc.)
  • doms.toon: DOM node mapping (TOON format, used only when precise restoration is required)
  • styles.toon: Style pool (TOON format, used only when complete styles are required)
  • content.md: Page content (Markdown format)
  • screenshot.png: Page screenshots (main basis for restoration)

Workflow

Phase 0: Locate the Resource Directory

When the user does not provide a directory path, use the listDirectory tool to find the project directory under temp/ (usually containing sitemap.json in a second-level directory). After finding it, read sitemap.json to obtain the project name and ask the user whether to process the project; if not, request the correct path.

Phase 1: Identify Resources

Verify the directory structure (check sitemap.json), parse the sitemap, and clarify user requirements (default: extract theme, identify data, generate documentation).

Phase 2: Extract Design Theme

Select 3-5 core pages (home page, login page, main feature pages), read each page's theme.json and combine with screenshot.png to analyze the visual style, merge theme data (colors, fonts, spacing, border radius, shadows), summarize the design language, and generate design specifications.

Output：src/themes/<theme-key>/(including globals.css or designToken.json(designToken.json must include the name field),DESIGN.md、index.tsx, compliant with the theme-guide.md specification)

Phase 3: Identify Data Models

Identify data-intensive pages (list pages, form pages, detail pages), read content.md to extract text content, identify data structures from table column names, form labels, and repeated patterns, and validate and merge fields across pages.

Output：src/database/<table-name>.json

  • File names use English (such as users.json）
  • tableName use Chinese (such as "用户表")

Data Table Structure (Strong Constraint): Each file must be a JSON object (do not output as a plain array), containing tableName + records。

{
  "tableName": "表名（中文）",
  "records": [
    { "id": 1, "字段1": "值1", "字段2": "值2" }
  ]
}

Minimum Consistency Rules (used to reduce errors)：

  • records must be an array; each record must contain a unique id(number or string is allowed; keep the type consistent within the same table).
  • Field names should preferably be in Chinese and consistent with the page; do not mix synonymous fields (such as choosing one of "手机号/手机号码").
  • Same field, same type; image fields use relative paths (such as images/xxx.png), do not use base64.

Phase 4: Generate project documentation

Generate a sitemap document (preserve the hierarchical structure, page names clickable) and a project overview document (basic information, design style, data model overview).

Output：src/docs/

Page restoration guide

Select the pages to restore (user-specified or choose 1-2 core pages from the sitemap).

Core method: look at the image → write code → deliver.

Core process (must be completed in full)

  1. Confirm prerequisites

    • Confirm the model supports visual recognition (if not, inform the user immediately)
    • Confirm that image content can be read directly (no conversion needed; if not supported, inform the user immediately)
    • Generate the page name (specification: lowercase letters, numbers, hyphens)

  2. Obtain screenshots

    • Local first: use the one in the page directory screenshot.png
    • If missing locally and sitemap.json contains projectUrl, MCP may be used to obtain an online screenshot (only when local is insufficient)

  3. Verify image reading capability

    • Try to read screenshot.png
    • If local images cannot be read directly(the tool does not support it or returns an error), you must:
      • Stop the process immediately
      • Inform the user: "Unable to read local images, please copy [图片绝对路径] into the dialog box and submit"
      • Wait for the user to submit the image before continuing
    • Do not assume or guess image content
    • Do not read image content via Base64 encoding

  4. Generate page code

    Auxiliary data acquisition(optional; generation is still primarily based on images):

    • Theme:theme.json(verify styles)

    • Text:content.md(verify copy)

    • Generate page code directly based on the screenshot

    • Complete internally during the code generation process:

      • Identify the layout structure (Header/Sidebar/Content, etc.)
      • Identify components (Button/Input/Table/Card, etc.)
      • Extract styles (colors, fonts, spacing, border radius, shadows, etc.)
      • Identify interactions (click, hover, state switching, etc.)

    Output files：

    • src/prototypes/<page-name>/index.tsx
    • src/prototypes/<page-name>/style.css(must include @import "tailwindcss";）
    • src/prototypes/<page-name>/components/(as needed)

    Core code standards(must be followed):

    • Variable names must be Component, use export default Component
    • For detailed specifications, see rules/development-guide.md

  5. Accept page restoration

    • Run the acceptance command:node scripts/check-app-ready.mjs /prototypes/[页面名]
    • Provide the preview URL
    • Confirm that the page's basic functions work properly (no compilation errors, accessible normally)

  6. Generate specification document

    • Generate the specification document based on the page code that has passed acceptance
    • Output file:src/prototypes/<page-name>/spec.md
    • The document content should include:
      • Page structure description
      • Component list
      • Style specifications (colors, fonts, spacing, etc.)
      • Interaction description
      • Data requirements (if any)

  7. Final Delivery

    • Inform the user that page restoration and the specification document are complete
    • Explain that secondary generation is available (fixing issues or optimizing/refactoring)

Restoration Strategy (Local Data Priority)

  1. Screenshot(highest priority): visually identify layout, colors, and spacing.
  2. Theme: apply the design tokens of theme.json .
  3. Content: use content.md to calibrate copy (does not affect layout or interaction).
  4. Node Details: use only when precise structure/positioning is needed doms.toon。
  5. Basic Design Review and Fixes: check for obvious issues according to design and frontend specifications and fix them; if a fix would change the original design intent, confirm with the user first.

Default Goal and Optional Optimization

  • Default Goal: when the user has not made additional requests, restore the visuals and layout of the screenshot/prototype as close to 1:1 pixel-perfect as possible (do not proactively "redesign").
  • Optional Optimization: if "design/interaction optimization" is also needed, please state it explicitly in the requirements; otherwise, only perform restoration and basic review fixes.

Output: page components that conform to the rules/development-guide.md specification

Online Resource Supplementation

When sitemap.json contains projectUrl, you can use the extract-axure-data skill script (located at skills/extract-axure-data/) to obtain online resources (local resources take priority; use only when insufficient or when the latest data is needed):

node skills/extract-axure-data/scripts/extract.mjs <projectUrl> --pages <target>

User Interaction Guide

Directory Validation Failed

⚠️ 未找到有效的 Axure 资源目录。
请确认目录包含 sitemap.json 和页面目录。

Requirements Confirmation

✓ 已识别资源目录，共 [X] 个页面。

默认方案：
- 从核心页面提取设计主题并生成设计规范文档
- 识别数据模型
- 生成项目文档

回复"接受"按默认方案执行，或告诉我您的具体需求。

Progress Notification

正在处理...
✓ 已解析站点地图
✓ 已提取主题数据
⏳ 正在分析数据模型...

Completion Summary

✅ 已完成！

生成的资产：
- 设计主题：src/themes/<theme-key>/
- 设计规范文档：src/themes/<theme-key>/DESIGN.md
- 数据模型：src/database/
- 项目文档：src/docs/

后续建议：
💡 我还可以为您：
- 还原页面：告诉我需要还原的页面名称
- 生成业务文档：领域模型、业务流程等

需要吗？

Key Principles

  • Proactively find the latest resources in the temp directory
  • Proactively confirm important operations
  • Provide timely progress feedback
  • Clearly summarize results
  • Provide options rather than forcing them
  • Handle errors in a friendly manner
  • Guide follow-up operations

Notes

  • TOON has a large data volume; parse only when necessary
  • Theme extraction uses 3-5 pages; the data model needs cross-page validation
  • Page restoration is based primarily on screenshots

Reference

theme-guide.md | development-guide.md