Skip to main content
Generalhashgraph-online

dev-design-context

Use as a one-time design setup for UI, product, landing-page, or brand-heavy work. Scans the project for design context, asks only the UX questions that cannot be inferred, then writes persistent design guidelines to .design-context.md. Does not implement features or review code.

Stars
336
Source
hashgraph-online/awesome-codex-plugins
Updated
2026-05-27
Slug
hashgraph-online--awesome-codex-plugins--dev-design-context
View on GitHubRaw SKILL.md

// install — copy + paste into any project

mkdir -p .claude/skills && curl -fsSL https://raw.githubusercontent.com/hashgraph-online/awesome-codex-plugins/HEAD/plugins/Jason-chen-coder/dev-skills/skills/dev-design-context/SKILL.md -o .claude/skills/dev-design-context.md

Drops the SKILL.md into .claude/skills/dev-design-context.md. Works with Claude Code, Cursor, and any agent that loads SKILL.md files from .claude/skills/.

Dev Design Context

Gather design context for this project, then persist it so future UI work starts with the same visual and product direction.

This skill is for one-time setup or major design-direction resets. It does not write application code, generate mockups, or review implementation diffs.


Trigger routing

Use this skill when the user wants Codex / Claude Code to learn a project's design direction before building UI.

Trigger phrases include:

  • dev-design-context
  • setup design context
  • 设计上下文
  • 设计规范
  • 先建立设计方向
  • gather design context
  • persistent design guidelines

Output goes to .design-context.md in the project root.

Step 0 — Load baseline

执行前先加载 references/dev-baseline.md。以下行为准则在本 skill 全程生效:不假设最小代码外科手术式改动可验证成功标准

baseline 与本 skill 的关联点:

  • 不假设 —— 先扫描真实代码和资产,再问问题;不要让用户重复回答代码里已经能看到的信息。
  • 最小代码 —— 只写 .design-context.md 的设计上下文,不要顺手改组件、CSS 或产品文案。
  • 外科手术式改动 —— 如果 .design-context.md 已存在,只更新 ## Design Context 相关内容。
  • 可验证成功标准 —— 结束前明确写出设计原则已经落在哪个文件,并总结未来设计工作应遵守的 3-5 条原则。

Step 1 — Explore the codebase

Before asking questions, scan the project to discover what can be inferred:

  • README and docs: project purpose, target audience, and stated goals
  • Package / config files: tech stack, dependencies, and design libraries
  • Existing components: layout patterns, spacing, typography, component conventions
  • Brand assets: logos, favicons, image assets, and already-defined color values
  • Design tokens / CSS variables: color palettes, font stacks, spacing scales, radii, motion values
  • Style guides or brand docs: any explicit product, content, or visual direction

Summarize what you learned and what remains unclear before asking the user anything.

Step 2 — Ask UX-focused questions

Ask the user directly to clarify only what cannot be inferred from the codebase. Keep questions focused and avoid long questionnaires.

Users and purpose

  • Who uses this? What is their context when using it?
  • What job are they trying to get done?
  • What emotions should the interface evoke, such as confidence, calm, delight, urgency, or precision?

Brand and personality

  • How would you describe the brand personality in 3 words?
  • Are there reference sites or apps that capture the right feel? What specifically works about them?
  • What should this explicitly not look like? Are there anti-references?

Aesthetic preferences

  • Are there strong preferences for visual direction, such as minimal, bold, editorial, technical, playful, or organic?
  • Should it support light mode, dark mode, or both?
  • Are there colors that must be used or avoided?

Accessibility and inclusion

  • Are there specific accessibility requirements, such as a WCAG level or known user needs?
  • Are there constraints around reduced motion, color blindness, contrast, or other accommodations?

Skip questions where the answer is already clear from the codebase exploration.

Step 3 — Write design context

Synthesize the codebase findings and the user's answers into this section:

## Design Context

### Users
[Who they are, their context, and the job to be done]

### Brand Personality
[Voice, tone, 3-word personality, and emotional goals]

### Aesthetic Direction
[Visual tone, references, anti-references, theme, color, and motion direction]

### Design Principles
[3-5 principles derived from the codebase and conversation that should guide all design decisions]

Write this section to .design-context.md in the project root. If the file already exists, update the ## Design Context section in place instead of duplicating it.

Then ask the user whether they also want the same Design Context appended to .github/copilot-instructions.md. If yes, append or update that section there as well.

Confirm completion and summarize the key design principles that will guide future UI work.


Multi-Agent Profile

Recommended agent_type: explorer

Use when:

  • The main agent needs design-system or UI convention discovery before UI work.
  • The project has existing components, styles, assets, or brand cues to inspect.
  • The sub-agent can summarize findings without implementing UI changes.

Do:

  • Explore README, assets, styles, components, tokens, and existing screens.
  • Separate codebase facts from assumptions.
  • Ask only UX questions that cannot be inferred.
  • Follow the explorer boundaries in ../../docs/multi-agent-policy.md.

Do not:

  • Implement UI.
  • Rewrite product copy or CSS outside .design-context.md.
  • Invent brand direction when the project already provides evidence.

Output:

  • Codebase design facts
  • Unknowns that require user input
  • Proposed design principles
  • Files inspected