design

Creates and maintains a repo-local DESIGN.md as the source of truth for UI/UX decisions.

Updated Feb 1, 2024
One-click install
npx skills add https://github.com/ogiboy/portfolio-app --skill design-ogiboy
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: design
Source: https://github.com/ogiboy/portfolio-app/tree/main/.codex/skills/design
Command: npx skills add https://github.com/ogiboy/portfolio-app --skill design-ogiboy

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? UI/UX and frontend decisions often get made ad hoc and lost, leaving implementers and reviewers without a documented design contract. This Skill discovers existing design evidence in a repository, interviews for missing product context, and produces a canonical DESIGN.md that grounds all future frontend work. ## Core Features & Use Cases - Design Evidence Discovery: Scans the repo for existing design docs, components, theme tokens, screenshots, and accessibility constraints before writing anything. - Structured Interview: Asks focused questions only for context the repo cannot answer, or records assumptions and open questions when autonomous progress is preferred. - Canonical DESIGN.md Template: Creates or refreshes a DESIGN.md with required sections covering brand, personas, information architecture, visual language, components, accessibility, responsive behavior, and interaction states. - Use Case: Before starting a new frontend feature, run the design workflow to consolidate scattered UI decisions into a single DESIGN.md that implementation and review can cite. ## Quick Start Ask the AI to use the design skill to audit this repository's UI and create a DESIGN.md design source of truth.

Frequently Asked Questions about design

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I create a design document for my repository?

Run the design workflow, which first inspects existing docs, components, theme tokens, and screenshots, then interviews for missing product context. It produces a DESIGN.md at the repo root with sections for brand, personas, visual language, accessibility, and open questions.

What sections should a DESIGN.md design brief include?

The required structure covers source of truth status, brand, product goals, personas, information architecture, design principles, visual language, components, accessibility, responsive behavior, interaction states, content voice, implementation constraints, and open questions.

When should I use a design brief workflow versus visual screenshot matching?

Use the design workflow when you need a durable design contract before implementation begins. Use a visual-reference tool like visual-ralph only when matching an approved screenshot or live URL, since DESIGN.md governs decisions rather than pixel fidelity.

Can the design workflow run without user input?

Yes. If the user cannot answer interview questions, the workflow proceeds autonomously by recording explicit assumptions and listing unresolved items as open questions in DESIGN.md instead of blocking.

What are the limitations of a DESIGN.md source of truth?

DESIGN.md documents design decisions but does not perform pixel-diff verification or visual fidelity scoring. It also does not apply to pure backend or infrastructure work with no user-facing design consequences.