brief

Name: brief
Author: educlopez

312installs8forks

How to install brief?

educlopez/ui-craft/brief

$npx -y skills add educlopez/ui-craft --skill brief

Installs into the current project.

Summary

Write or update the project's durable design brief at .ui-craft/brief.md. Invoke when the user asks for brief on their UI, or mentions 'brief' alongside design / UI / frontend work.

Files · 1

View on GitHub

SKILL.md

1	<!-- HARNESS MIRROR — do not edit here. Canonical source: skills/ or commands/. After editing source, copy into cli/assets/<harness>/ and repo-root harness mirrors. -->
2
3	Context: this sub-skill is one lens of the broader `ui-craft` skill. If the `ui-craft` skill is also installed, read its SKILL.md first for Discovery + Anti-Slop + Craft Test, then apply the specific lens below.
4
5	Load `references/brief.md` for the brief format before proceeding.
6
7	## Step 1: Detect existing brief
8
9	Check whether `.ui-craft/brief.md` exists. Use Read or ls on `.ui-craft/`.
10
11	If it exists: load its contents. If the target the user described names a specific update ("update principles", "shift target user", "add out of scope"), focus the session there and skip unchanged sections. Otherwise summarize what's in the brief and ask: "What do you want to change?"
12
13	If it doesn't exist: proceed to Step 2. Also check the repo root for a `DESIGN.md` or `design-tokens.json` (an ecosystem convention some teams already maintain) — if present, read it and pre-fill the brief's answers from it instead of re-asking; note the source. The brief complements an existing design contract, never contradicts it.
14
15	## Step 2: Draft a new brief (absent case)
16
17	Walk the user through the five required sections in a single pass. Ask ONE compact question per section. Do not open five separate prompts unless the user asks for depth.
18
19	Compact prompt template:
20
21	> "To write your design brief I need five things — answer as tersely as you like, I'll fill in structure:
22	> 1. Product purpose — what does it do, in one sentence?
23	> 2. Primary user — who, by role and context?
24	> 3. Principles — what does this product believe? Give me three to five stances it takes. (If you don't have these yet, say so — I'll run the principles workshop.)
25	> 4. Success metric — what does 'the user succeeded on this surface' look like in observable behavior?
26	> 5. Out of scope — three to five things this surface deliberately does NOT do."
27
28	Principles workshop case: if the user says "I don't have principles yet" or gives vague answers ("make it good", "keep it simple"), do NOT fabricate principles from vague input. Load `references/principles-catalog.md` first. The catalog has 42 worked example principles across 8 product categories — use them as conversation seeds, not as templates to adopt literally. Show 2-3 from the closest category to the user's product, then ask which resonate or which they'd flip. Then run the principles workshop from `references/brief.md` as a focused sub-flow: ask for three past design decisions that were debated, then derive candidate principles from the patterns. Refuse to accept platitudes — push back and prompt for substance.
29
30	Parsing long input: if the user provides a product description or PRD, parse it into the five sections rather than re-asking for information already given. State what you extracted and ask for confirmation or corrections.
31
32	Thin answers: if an answer is too vague to constrain a design decision, ask one targeted follow-up. Maximum two follow-ups per section before flagging it as incomplete and moving on.
33
34	## Step 3: Show before writing
35
36	Always show the proposed brief in full before writing the file. Ask: "Does this look right, or anything to adjust?"
37
38	Do not write until confirmed.
39
40	## Step 4: Write the file
41
42	Create `.ui-craft/` if it doesn't exist. Write the confirmed content to `.ui-craft/brief.md`.
43
44	The file must contain all five sections with the exact headings from `references/brief.md`. No omissions.
45
46	## Step 5: After writing
47
48	Tell the user the file is at `.ui-craft/brief.md`. Suggest committing it:
49
50	> "Commit `.ui-craft/brief.md` to the repo — it's documentation, not config. The agent reads it every session."
51
52	Do not auto-commit. Per project rules, commits require explicit user instruction.
53
54	## Constraints
55
56	- All five sections are required. If one is genuinely unknown, write it as a dated placeholder with `[TO DEFINE — YYYY-MM-DD]` so the gap is visible.
57	- The brief is append-mostly on updates. Never delete past content — mark deprecated with date and reason.
58	- No brand names, product examples, or generic SaaS language inside the user's brief. The brief describes their product, not the template.

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

brief

312installs8forks

View on GitHub

How to install brief?

educlopez/ui-craft/brief

$npx -y skills add educlopez/ui-craft --skill brief

Installs into the current project.

Summary

Write or update the project's durable design brief at .ui-craft/brief.md. Invoke when the user asks for brief on their UI, or mentions 'brief' alongside design / UI / frontend work.

Files · 1

View on GitHub

SKILL.md

1	<!-- HARNESS MIRROR — do not edit here. Canonical source: skills/ or commands/. After editing source, copy into cli/assets/<harness>/ and repo-root harness mirrors. -->
2
3	Context: this sub-skill is one lens of the broader `ui-craft` skill. If the `ui-craft` skill is also installed, read its SKILL.md first for Discovery + Anti-Slop + Craft Test, then apply the specific lens below.
4
5	Load `references/brief.md` for the brief format before proceeding.
6
7	## Step 1: Detect existing brief
8
9	Check whether `.ui-craft/brief.md` exists. Use Read or ls on `.ui-craft/`.
10
11	If it exists: load its contents. If the target the user described names a specific update ("update principles", "shift target user", "add out of scope"), focus the session there and skip unchanged sections. Otherwise summarize what's in the brief and ask: "What do you want to change?"
12
13	If it doesn't exist: proceed to Step 2. Also check the repo root for a `DESIGN.md` or `design-tokens.json` (an ecosystem convention some teams already maintain) — if present, read it and pre-fill the brief's answers from it instead of re-asking; note the source. The brief complements an existing design contract, never contradicts it.
14
15	## Step 2: Draft a new brief (absent case)
16
17	Walk the user through the five required sections in a single pass. Ask ONE compact question per section. Do not open five separate prompts unless the user asks for depth.
18
19	Compact prompt template:
20
21	> "To write your design brief I need five things — answer as tersely as you like, I'll fill in structure:
22	> 1. Product purpose — what does it do, in one sentence?
23	> 2. Primary user — who, by role and context?
24	> 3. Principles — what does this product believe? Give me three to five stances it takes. (If you don't have these yet, say so — I'll run the principles workshop.)
25	> 4. Success metric — what does 'the user succeeded on this surface' look like in observable behavior?
26	> 5. Out of scope — three to five things this surface deliberately does NOT do."
27
28	Principles workshop case: if the user says "I don't have principles yet" or gives vague answers ("make it good", "keep it simple"), do NOT fabricate principles from vague input. Load `references/principles-catalog.md` first. The catalog has 42 worked example principles across 8 product categories — use them as conversation seeds, not as templates to adopt literally. Show 2-3 from the closest category to the user's product, then ask which resonate or which they'd flip. Then run the principles workshop from `references/brief.md` as a focused sub-flow: ask for three past design decisions that were debated, then derive candidate principles from the patterns. Refuse to accept platitudes — push back and prompt for substance.
29
30	Parsing long input: if the user provides a product description or PRD, parse it into the five sections rather than re-asking for information already given. State what you extracted and ask for confirmation or corrections.
31
32	Thin answers: if an answer is too vague to constrain a design decision, ask one targeted follow-up. Maximum two follow-ups per section before flagging it as incomplete and moving on.
33
34	## Step 3: Show before writing
35
36	Always show the proposed brief in full before writing the file. Ask: "Does this look right, or anything to adjust?"
37
38	Do not write until confirmed.
39
40	## Step 4: Write the file
41
42	Create `.ui-craft/` if it doesn't exist. Write the confirmed content to `.ui-craft/brief.md`.
43
44	The file must contain all five sections with the exact headings from `references/brief.md`. No omissions.
45
46	## Step 5: After writing
47
48	Tell the user the file is at `.ui-craft/brief.md`. Suggest committing it:
49
50	> "Commit `.ui-craft/brief.md` to the repo — it's documentation, not config. The agent reads it every session."
51
52	Do not auto-commit. Per project rules, commits require explicit user instruction.
53
54	## Constraints
55
56	- All five sections are required. If one is genuinely unknown, write it as a dated placeholder with `[TO DEFINE — YYYY-MM-DD]` so the gap is visible.
57	- The brief is append-mostly on updates. Never delete past content — mark deprecated with date and reason.
58	- No brand names, product examples, or generic SaaS language inside the user's brief. The brief describes their product, not the template.

People who liked this also viewed

6 picks

Type