القائمة
Analyze existing product screens, UI code, design artifacts, and visual references to synthesize a semantic design system into DESIGN.md files.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use when designing, specifying, implementing, or reviewing a modular system built around Pi Coding Agent / Pi Agent as an embedded agent engine. Trigger for Pi Agent docking, createAgentSession, custom tools, SessionManager, ResourceLoader, ExtensionRunner, Pi events, OpenClaw-style harnesses, plugin ecosystems, web chat channels, MCP/tool adapters, system prompt stewardship, policy layers, or minimal runtimes around packages/coding-agent.
Use this skill when a user asks to graph, map, or visualize a codebase/workspace with Graphify and inspect the generated graphify-out/graph.html, graphify-out/graph.json, or graphify-out/GRAPH_REPORT.md artifacts.
Use the Pibo local auth gateway, both on the host and inside Docker workers. Use this when you need authenticated access to the Chat Web App without configuring Google OAuth, when you want to test against a local gateway on a developer laptop, or when you are working inside a Docker worker and need a fast authenticated session.
Defines how Pibo specs are written, structured, reviewed, and split into proposals, capability specs, phase specs, designs, and tasks. Use this whenever the user asks to create, review, rewrite, compare, or implement a spec; mentions requirements, acceptance criteria, scope, roadmap, proposal, design plan, tasks, OpenSpec, Spec Kit, GSD, or spec-driven development; or asks where project documentation should live.
Plan, create, run, monitor, and review Ralph implementation loops with reusable Docker workers, git worktrees, PRD batches, stop policies, maxIterations, progress files, commits, and safe agent instructions. Use whenever the user wants to start a Ralph job, run an implementation loop, prepare autonomous PRD execution, monitor Ralph, debug Ralph job behavior, or capture the standard Ralph loop workflow.
Use this skill for Pibo Docker Compute System work, isolated implementation, worker worktrees, Chat Web or gateway testing, worker dev auth, browser/CDP validation, resource cleanup, and when coordinating Docker worker use with the github-server-flow strategy.
| name | design-md |
| description | Analyze existing product screens, UI code, design artifacts, and visual references to synthesize a semantic design system into DESIGN.md files. |
| allowed-tools | ["Read","Write","web_fetch","stitch*:*"] |
You are an expert Design Systems Lead. Your goal is to analyze provided visual and technical assets and synthesize a semantic design system into a file named DESIGN.md.
This skill helps create DESIGN.md files that serve as the source of truth for generating, implementing, and reviewing new screens that align with an existing design language.
The core output is a semantic design system: it translates code, screenshots, prototypes, or existing UI into clear visual descriptions supported by precise values such as hex colors, spacing patterns, typography rules, and component behavior.
Use this skill for any project with enough visual evidence to infer a design language. The source can be a running app, screenshots, HTML/CSS, React/Vue/Svelte components, Tailwind classes, Figma/Stitch output, design mockups, or a hand-written prototype.
Create or update DESIGN.md so future work can reproduce the same visual language without re-analyzing the original UI.
The document must answer:
Use the available source material. Prefer local project assets before external retrieval.
When working in a repository, inspect likely design sources:
DESIGN.md if it already existsREADME.md, docs, specs, and design notesUseful searches:
rg --files -g '*.{css,scss,less,html,tsx,jsx,ts,js,vue,svelte,md}'
rg -n "theme|color|background|border|rounded|shadow|font|spacing|className|tailwind"
If screenshots or local images are provided, inspect them as visual references. Extract atmosphere, density, layout, hierarchy, geometry, color relationships, and interaction affordances.
If a hosted design reference is provided, fetch only the relevant page or asset. Use official or user-provided URLs. Extract visual and code patterns without copying unrelated content.
If the source is a Stitch project, Figma export, or another design tool, use the available tool or exported assets to retrieve screen metadata, screenshots, and HTML/CSS. Stitch is one possible source, not a requirement.
For Stitch specifically, if MCP tools are available and a project id or URL is provided:
Skip this section entirely when the project is not using Stitch.
Identify:
If there is no external project id, use a clear local identifier such as local-reference-[project-name].
Evaluate the visual source and describe the overall mood and product philosophy. Use precise adjectives such as:
Explain why the UI feels that way: density, colors, typography, borders, shadows, rhythm, imagery, iconography, and interaction style.
Identify key colors and give each a semantic name.
For each color, include:
Do not describe colors only as "blue" or "gray." Prefer names like "Terminal Cyan (#11a4d4)" or "Deep Muted Teal-Navy (#294056)".
Group colors by function when possible:
Convert technical shape values into visual language.
Examples:
rounded-full means circular or pill-shaped.rounded-sm means tiny softened corners.rounded-lg means gently rounded corners.rounded-none means sharp, squared-off geometry.Document:
Explain how the UI creates layers:
State whether elevation should be quiet, dramatic, tactile, or mostly absent.
Capture:
Explain how type communicates hierarchy and how text should sound inside the UI.
Document reusable styling for the components that define the product.
Common categories:
For each component type, describe shape, color, spacing, borders, typography, hover/focus states, and any distinctive behavior.
Document:
This section should tell a future designer or agent how to build a new screen in the same visual language.
Use this structure unless the user asks for a different one:
# Design System: [Project Title]
**Project ID:** [Project ID or local reference identifier]
## 1. Visual Theme & Atmosphere
[Description of mood, density, aesthetic philosophy, and product feeling.]
## 2. Color Palette & Roles
[Colors by descriptive name, exact hex code, and functional role.]
## 3. Typography Rules
[Font family, size hierarchy, weight usage, letter spacing, case, and monospaced usage.]
## 4. Component Stylings
* **Buttons:** [Shape, colors, states, behavior.]
* **Cards/Containers:** [Roundness, background, borders, depth.]
* **Inputs/Forms:** [Stroke style, background, focus state.]
## 5. Layout Principles
[Whitespace, margins, grids, panels, responsive behavior, alignment.]
For richer products, add sections such as:
## 6. Motion And Interaction## 7. Applying This System Across The App## 8. Accessibility And Contrast## 9. Anti-Patterns