SuperAPI AI Directory

soia-dev-design-explorer

Design & creation

View repository

Updated 10-16 08:46

About this skill

soia-dev-design-explorer

This is a public design artifact workflow wrapper layer. It uses the Open Design atomic operations provided by soia-dev-open-design-ops as its foundation, converging high-fidelity design exploration into explicit inputs, controlled outputs, and reproducible verification; it does not replace product specifications or production implementation.

Client-readable description

What this skill can do

The client wants The skill will do The client can see
High-fidelity prototype / deck / animation Collect goals, canvas size, content, and assets, and generate step by step with Open Design Artifact paths, previews, gaps, and verification evidence
style exploration Generate 2–4 comparable directions so users do not have to choose blindly from text alone Direction differences, real visuals, and recommendation rationale
design review Tiered review of existing pages or screenshots Conclusions, severity, and prioritized fix actions

Not for routine front-end implementation, CSS bug fixes, low-fidelity wireframes, or PRD writing.

How clients use it

Provide:

  1. Delivery type:prototype / deck / animation / style-exploration / review;
  2. Platform and canvas size;
  3. Audience, purpose, and success criteria;
  4. Real content and assets;
  5. User-provided brand guidelines (files, URLs, or an explicit statement of "none");
  6. Output category and path;
  7. Open Design checkout path; when integrating a design system, also provide the project path or DESIGN.md。

When requirements are vague, first offer 2–3 mutually exclusive form options. When brand information is insufficient, use a neutral exploration direction and mark placeholders; do not guess brand colors from memory.

Dependencies and installation

Install this skill and its hard dependencies:

npx skills add soia-team/soia-open-skills -g -a '*' -s soia-dev-design-explorer -y
npx skills add soia-team/soia-open-skills -g -a '*' -s soia-dev-open-design-ops -y

Open Design's checkout, Node/pnpm prerequisites, private configuration, daemon ports, and security boundaries are all maintained by soia-dev-open-design-ops . This skill does not embed or install Open Design; when the atomic layer is unavailable, stop the design generation path, return its installation or repair recommendations, and do not call local substitutes Open Design deliverables.

For design systems, prefer the official trio:manifest.json、DESIGN.md、tokens.css. Existing user projects can use DESIGN.md-only compatible integration; it must be registered by the atomic layer's CLI/App import-local , and user project paths must not be copied or guessed.

Brand guidelines are not a skill dependency. Clients may provide brand guidelines, logos, color palettes, fonts, screenshots, and copy rules; when not provided, explicitly record the gap.

Logs and completion receipts

完成:<产物或评审结果>。

日志摘要:
- type/platform: <类型与画幅>
- open-design: <环境/daemon/设计系统或目录检查结果,不输出秘密>
- inputs: <品牌/内容/素材完整度>
- created/updated: <产物路径>
- skipped/failed: <数量和原因>

验证:<浏览器、截图、导出打开或交互检查>
问题与下一步:<placeholder、缺素材或无>

Trigger conditions

  • Build a high-fidelity HTML prototype or interactive demo;
  • Create HTML slides, animations, presentation video assets, or design variants;
  • Provide direction recommendations, reviews, or revision suggestions for existing visual drafts;
  • The user explicitly mentions soia-dev-design-explorer、Open Design、prototype or "visual direction".

Boundaries

  • Outputs are design explorations or reviews and do not automatically become production code, business contracts, or product specifications.
  • Modifying existing files, overwriting exports, publishing, or writing to remote locations requires preview and confirmation first.
  • Do not load or assume any organization-internal workspace, governance directory, brand skill, or file-writing rules.
  • Do not modify the upstream source code of the Open Design checkout; only perform controlled operations through atomic-layer scripts or the upstream CLI/App.

Minimal Workflow

Step 1. Lock Down the Task Shape

Select only one primary shape at a time:

  • prototype: clickable page or flow;
  • deck: HTML slides or exported presentation deck;
  • animation: timeline animation and optional MP4/GIF;
  • style-exploration: 2–4 comparable visual directions;
  • review: structured design review.

Step 2. Check Input Completeness

Before generation, list available / missing / placeholder:

  • real copy and data;
  • logo, product images, screenshots, fonts;
  • brand guidelines provided by the user;
  • target platform, aspect ratio, and accessibility requirements;
  • output purpose, audience, and success criteria.

If missing assets would significantly affect the result, ask first. If placeholders are allowed, they must be marked in the artifact and receipt.

Step 3. Invoke the Open Design atomic layer

First use soia-dev-open-design-ops to check the environment and daemon; process liveness must not be used as a substitute for directory availability checks:

# 从已安装 skill 调用(任意工作目录)
python3 ~/.agents/skills/soia-dev-open-design-ops/scripts/check_env.py
python3 ~/.agents/skills/soia-dev-open-design-ops/scripts/daemon_ctl.py status
python3 ~/.agents/skills/soia-dev-open-design-ops/scripts/daemon_ctl.py health

# 在 soia-open-skills 仓库根目录开发时
python3 skills/soia-dev-open-design-ops/scripts/check_env.py
python3 skills/soia-dev-open-design-ops/scripts/daemon_ctl.py status
python3 skills/soia-dev-open-design-ops/scripts/daemon_ctl.py health

check_env.py must return status=ok;health must use /api/skills returning an array as evidence. If the checkout, Node/pnpm is missing, or the daemon is unavailable, stop and fix it according to the suggestions given by the atomic layer.

When integrating design rules, first check whether the user-provided project has the formal trio; if not, use the user project's DESIGN.md as compatible input, and let the atomic layer's design-systems import-local integrate it. To query functional skills, use list_skills.py; to query rendering templates, use the Open Design App's "Start from" or GET /api/design-templates. The two catalogs must not be conflated.

Step 4. Choose the Output Destination by the Five Categories

Classify first, then write files:

Category Examples in this skill Destination
A Temporary One-time previews, intermediate screenshots, temporary renders User-specified DESIGN_EXPLORER_TEMP_ROOT; otherwise ${TMPDIR}/soia-dev-design-explorer/<slug>/,TMPDIR : if not set, ask first
B Audit Records of high-impact actions such as publishing, overwriting, and remote writes User-specified DESIGN_EXPLORER_STATE_ROOT or ${XDG_STATE_HOME}/soia-dev-design-explorer/; if not configured, ask first
C Deliverable HTML, PPTX, PDF, MP4, GIF, final screenshots The delivery directory explicitly specified by the user; do not default to writing to cwd or Downloads
D Product feature as log Design records explicitly stipulated by the target product Only obey the target project's public/local rules; do not create conventions from this skill
E Pure stdout Short reviews that do not need to be kept on file Do not write to disk

Before writing to C/D categories or overwriting existing files, show the absolute destination, current state, and expected file list. Category A cannot masquerade as a final deliverable.

Step 5. Generation and Iteration

  • Make the smallest visible version first, then expand;
  • For style exploration, first produce 2–4 substantially different directions;
  • For prototypes, first ensure the critical path is clickable, then polish the visuals;
  • For reviews, first give the conclusion and issue severity levels, then give fix suggestions;
  • All brand choices must be evidenced by user assets or citable public brand materials;
  • When generating, continuing a session, or exporting through the Open Design App/CLI, follow the stable entry points of the atomic layer; do not construct undocumented API payloads.

Step 6. Verification

Perform at least one verification commensurate with the delivery type:

  • Open in a browser and check key viewports;
  • Playwright/Open Design verification script screenshots;
  • Exported files can be opened, page count/duration meets expectations;
  • Key interactions of the prototype are clickable;
  • The review covers strengths, severity-ranked issues, and the top 3 highest-priority actions.

Only claim checks that were actually run. A passing preview does not equal production implementation acceptance.

Reference files

  • Execution checklist:references/execution-checklist.md