design

Name: design
Author: Codagent-AI

28stars1forks

How to install design?

codagent-ai/agent-skills/design

$npx -y skills add Codagent-AI/agent-skills --skill design

Installs into the current project.

Summary

Creates design artifacts through collaborative brainstorming of approaches, architecture, and trade-offs. Use when the user says "design this", "create a design", "brainstorm approaches", or "write a design doc".

Files · 1

View on GitHub

SKILL.md

1	# Design
2
3	## Overview
4
5	Help turn specs into fully formed technical designs through natural collaborative dialogue.
6
7	Start by reading all spec files in the change's `specs/` directory to understand settled requirements, then brainstorm architecture by asking questions one at a time. Once the architecture is clear, present the design and get user approval. When writing the design doc, also apply any spec edits identified during the conversation.
8
9	<HARD-GATE>
10	Do NOT invoke any implementation skill, write any code, scaffold any project, or take any implementation action until you have presented a design and the user has approved it. Use the appropriate tool for asking the user a question or requesting input to get this approval. This applies to EVERY project regardless of perceived simplicity.
11	</HARD-GATE>
12
13	## Anti-Pattern: "This Is Too Simple To Need A Design"
14
15	Every project goes through this process. A todo list, a single-function utility, a config change — all of them. "Simple" projects are where unexamined assumptions cause the most wasted work. The design can be short (a few sentences for truly simple projects), but you MUST present it and get approval.
16
17	## Anti-Pattern: Asking About Requirements
18
19	The spec stage has already settled what the system should do. Do NOT ask questions about behaviors, boundaries, error conditions, or edge cases — those are for the spec skill. Focus exclusively on architecture, patterns, and technical trade-offs.
20
21	If you discover a gap in the specs during the design conversation, surface it as a spec implication ("This decision means we need a new scenario in spec Y") rather than re-opening the requirement discussion.
22
23	## Checklist
24
25	You MUST create a task for each of these items and complete them in order:
26
27	1. Read all spec files — read every file in the change's `specs/` directory before asking any architecture questions. Skip any you just wrote in this session.
28	2. Explore project context — read the specific files, modules, and interfaces that the spec requirements will touch. Skip areas you already explored during earlier steps in this session.
29	3. Ask clarifying questions — one at a time, about architecture, patterns, and technical trade-offs only
30	4. Track spec implications — when an architectural decision reveals a new requirement or changes a scenario, note it
31	5. Propose 2-3 approaches — with trade-offs and a recommendation
32	6. Present design — in sections scaled to their complexity, get user approval after each section
33	7. Write the design document and apply spec edits — write `design.md` in the change directory, then edit any spec files identified during the conversation
34
35	## Process Flow
36
37	```dot
38	digraph design {
39	"Read all spec files" [shape=box];
40	"Explore project context" [shape=box];
41	"Ask clarifying questions" [shape=box];
42	"Propose 2-3 approaches" [shape=box];
43	"Present design sections" [shape=box];
44	"User approves design?" [shape=diamond];
45	"Write design doc + apply spec edits" [shape=box];
46
47	"Read all spec files" -> "Explore project context";
48	"Explore project context" -> "Ask clarifying questions";
49	"Ask clarifying questions" -> "Propose 2-3 approaches";
50	"Propose 2-3 approaches" -> "Present design sections";
51	"Present design sections" -> "User approves design?";
52	"User approves design?" -> "Present design sections" [label="no, revise"];
53	"User approves design?" -> "Write design doc + apply spec edits" [label="yes"];
54	}
55	```
56
57	## The Process
58
59	Reading the specs:
60	- If specs were written earlier in this session, re-read only to confirm exact wording
61	- Otherwise, read all `specs/*/.md` files in the change directory
62	- Understand the settled requirements and any `<!-- deferred-to-design: ... -->` markers
63	- Deferred markers are explicit invitations to complete or revise those scenarios once you have architectural context
64
65	Understanding the context:
66	- Focus on the specific files, modules, and interfaces that the spec requirements will touch
67	- Skip areas you already explored in earlier steps of this session
68	- Use the spec files as the authoritative source of requirements
69
70	Asking clarifying questions:
71	- Follow the `codagent:ask-questions` skill for how to ask questions (tool to use, batching strategy, question quality)
72	- Focus on: technical approach, architecture, patterns, trade-offs, constraints
73	- Prefer multiple-choice questions when possible, but open-ended is fine too
74	- Do NOT ask about what the system should do — that is settled in the specs
75	- Ask targeted architecture questions after reading specs and exploring relevant code, unless the specs and codebase make the implementation approach obvious and low-risk. Questions should cover choices th

People who liked this also viewed

6 picks

Type

web-design-guidelinesReview UI code for Web Interface Guidelines compliance. Use when asked to "review my UI", "check accessibility", "audit design", "review UX", or "check my site against best practices".SkillsJul 2026483k29k
lark-slides飞书幻灯片：创建和编辑幻灯片。创建演示文稿、读取幻灯片内容、管理幻灯片页面（创建、删除、读取、局部替换）。当用户需要创建或编辑幻灯片、读取或修改单个页面时使用。当用户给出 doubao.com 的 /slides/ URL/token 时，也应直接使用本 skill，不要因为域名不是飞书而回退到 WebFetch；路由依据是 URL 路径模式和 token，而不是域名。不负责：云文档内容编辑（走 SkillsJul 2026332k16k
design-taste-frontendTaste-Skill - gives your AI good taste. stops the AI from generating boring, generic slop SkillsJul 2026280k66k
ui-ux-pro-maxUI/UX design intelligence for web and mobile. Searchable local database with 84 styles, 192 color palettes, 74 font pairings, 192 product types, 98 UX guidelines, 104 icon entries, 16 GSAP motion presSkillsJul 2026280k109k
caveman-helpQuick-reference card for all caveman modes, skills, and commands. One-shot display, not a persistent mode. Trigger: /caveman-help, "caveman help", "what caveman commands", "how do I use caveman".SkillsJul 2026249k92k
codebase-designShared vocabulary for designing deep modules. Use when the user wants to design or improve a module's interface, find deepening opportunities, decide where a seam goes, make code more testable or AI-nSkillsJul 2026225k182k

design

28stars1forks

View on GitHub

How to install design?

codagent-ai/agent-skills/design

$npx -y skills add Codagent-AI/agent-skills --skill design

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Design
2
3	## Overview
4
5	Help turn specs into fully formed technical designs through natural collaborative dialogue.
6
7	Start by reading all spec files in the change's `specs/` directory to understand settled requirements, then brainstorm architecture by asking questions one at a time. Once the architecture is clear, present the design and get user approval. When writing the design doc, also apply any spec edits identified during the conversation.
8
9	<HARD-GATE>
10	Do NOT invoke any implementation skill, write any code, scaffold any project, or take any implementation action until you have presented a design and the user has approved it. Use the appropriate tool for asking the user a question or requesting input to get this approval. This applies to EVERY project regardless of perceived simplicity.
11	</HARD-GATE>
12
13	## Anti-Pattern: "This Is Too Simple To Need A Design"
14
15	Every project goes through this process. A todo list, a single-function utility, a config change — all of them. "Simple" projects are where unexamined assumptions cause the most wasted work. The design can be short (a few sentences for truly simple projects), but you MUST present it and get approval.
16
17	## Anti-Pattern: Asking About Requirements
18
19	The spec stage has already settled what the system should do. Do NOT ask questions about behaviors, boundaries, error conditions, or edge cases — those are for the spec skill. Focus exclusively on architecture, patterns, and technical trade-offs.
20
21	If you discover a gap in the specs during the design conversation, surface it as a spec implication ("This decision means we need a new scenario in spec Y") rather than re-opening the requirement discussion.
22
23	## Checklist
24
25	You MUST create a task for each of these items and complete them in order:
26
27	1. Read all spec files — read every file in the change's `specs/` directory before asking any architecture questions. Skip any you just wrote in this session.
28	2. Explore project context — read the specific files, modules, and interfaces that the spec requirements will touch. Skip areas you already explored during earlier steps in this session.
29	3. Ask clarifying questions — one at a time, about architecture, patterns, and technical trade-offs only
30	4. Track spec implications — when an architectural decision reveals a new requirement or changes a scenario, note it
31	5. Propose 2-3 approaches — with trade-offs and a recommendation
32	6. Present design — in sections scaled to their complexity, get user approval after each section
33	7. Write the design document and apply spec edits — write `design.md` in the change directory, then edit any spec files identified during the conversation
34
35	## Process Flow
36
37	```dot
38	digraph design {
39	"Read all spec files" [shape=box];
40	"Explore project context" [shape=box];
41	"Ask clarifying questions" [shape=box];
42	"Propose 2-3 approaches" [shape=box];
43	"Present design sections" [shape=box];
44	"User approves design?" [shape=diamond];
45	"Write design doc + apply spec edits" [shape=box];
46
47	"Read all spec files" -> "Explore project context";
48	"Explore project context" -> "Ask clarifying questions";
49	"Ask clarifying questions" -> "Propose 2-3 approaches";
50	"Propose 2-3 approaches" -> "Present design sections";
51	"Present design sections" -> "User approves design?";
52	"User approves design?" -> "Present design sections" [label="no, revise"];
53	"User approves design?" -> "Write design doc + apply spec edits" [label="yes"];
54	}
55	```
56
57	## The Process
58
59	Reading the specs:
60	- If specs were written earlier in this session, re-read only to confirm exact wording
61	- Otherwise, read all `specs/*/.md` files in the change directory
62	- Understand the settled requirements and any `<!-- deferred-to-design: ... -->` markers
63	- Deferred markers are explicit invitations to complete or revise those scenarios once you have architectural context
64
65	Understanding the context:
66	- Focus on the specific files, modules, and interfaces that the spec requirements will touch
67	- Skip areas you already explored in earlier steps of this session
68	- Use the spec files as the authoritative source of requirements
69
70	Asking clarifying questions:
71	- Follow the `codagent:ask-questions` skill for how to ask questions (tool to use, batching strategy, question quality)
72	- Focus on: technical approach, architecture, patterns, trade-offs, constraints
73	- Prefer multiple-choice questions when possible, but open-ended is fine too
74	- Do NOT ask about what the system should do — that is settled in the specs
75	- Ask targeted architecture questions after reading specs and exploring relevant code, unless the specs and codebase make the implementation approach obvious and low-risk. Questions should cover choices th

People who liked this also viewed

6 picks

Type