design-ask

Name: design-ask
Author: ommakes

20stars0forks

How to install design-ask?

ommakes/skills/design-ask

$npx -y skills add ommakes/Skills --skill design-ask

Installs into the current project.

Summary

Unpacks poorly written Jira or Azure DevOps tickets into design-relevant framing. Use this skill whenever a designer pastes in a ticket description, acceptance criteria, or any product/engineering requirement and wants to understand what the actual design work is. Trigger when so

Files · 1

View on GitHub

SKILL.md

1	# Design Ask
2
3	Helps designers cut through poorly written tickets to understand what design work is actually being asked for, what's missing, and what questions to ask before starting.
4
5	---
6
7	## Your job
8
9	When a designer pastes in a ticket, you are not designing anything. You are doing triage. Your job is to surface:
10
11	1. What the ticket is actually asking for
12	2. What's missing or ambiguous
13	3. Whether the ticket is prescribing a solution instead of describing a need
14	4. What design work is required and at what scope
15	5. What questions the designer should ask before touching anything
16
17	Be direct. Don't pad the output. If something is unclear, say it's unclear. If a ticket is underbaked, call it that.
18
19	---
20
21	## Output format
22
23	Always produce output in this exact structure. Use the headers as written.
24
25	---
26
27	### The real ask
28
29	In 2-3 sentences, describe what the user or business actually needs here — stripped of implementation language. Ignore any prescribed UI solutions for now. If the ticket is so vague you can't determine this, say so clearly and explain what's missing.
30
31	---
32
33	### Type of design work
34
35	Pick the most accurate category and explain briefly why. If multiple apply, list them in order of likely effort.
36
37	- Content only — Labels, copy, error messages, tooltips. No structural change.
38	- Single screen / state — One view needs to be added or significantly changed.
39	- Linear flow — Multiple steps, no branching or conditions.
40	- Branching flow — Two or more paths, conditional logic, or decision points.
41	- System / pattern — A new component, interaction pattern, or behavior that will recur across the product.
42	- Unclear — Not enough information to determine scope.
43
44	Also answer: Should multiple design variants be explored before committing to one direction? Give a yes/no and a reason.
45
46	---
47
48	### Known requirements
49
50	List only what is explicitly stated in the ticket. These are things the designer should treat as constraints until told otherwise. Keep this tight — if it's not in the ticket, it doesn't go here.
51
52	---
53
54	### Inferred context ⚠️
55
56	List things the ticket implies but doesn't state. Label each one as inferred so it's clear these are assumptions, not facts. A designer should validate these before relying on them.
57
58	---
59
60	### Prescription alert 🚩
61
62	If the ticket specifies UI components, copy, layout, or interaction patterns as requirements, flag each one here.
63
64	For each item, write:
65	- Prescribed: What the ticket says
66	- What it probably means: The underlying user need or design decision being made
67	- Risk: What gets lost if you just build what's prescribed without questioning it
68	- Question to ask: A specific question to bring back to the PM or stakeholder
69
70	If there are no prescription issues, write "None detected."
71
72	---
73
74	### Constraints and context
75
76	Call out anything that affects design freedom:
77
78	- Is development already underway or already scoped? If so, what's likely off the table?
79	- Is there a timebox that limits how much exploration is realistic?
80	- Are there known system or platform limitations implied by the ticket?
81	- Does this touch an existing pattern or flow that design would need to account for?
82
83	If none of these are evident in the ticket, say so.
84
85	---
86
87	### Open questions (bring these to the PM)
88
89	A numbered list of specific questions the designer should get answered before starting. Write them so the designer could paste them directly into a Slack message or Jira comment. No vague questions — each one should be answerable with a clear response.
90
91	Order them: highest-impact unknowns first.
92
93	---
94
95	### Design readiness verdict
96
97	One of three ratings, with a brief explanation:
98
99	- Ready to start — Enough context to begin. Known unknowns are low-risk.
100	- Start with caution — Some important gaps, but work can begin on safe parts while answers are gathered.
101	- *

People who liked this also viewed

6 picks

Type

design-ask

20stars0forks

View on GitHub

How to install design-ask?

ommakes/skills/design-ask

$npx -y skills add ommakes/Skills --skill design-ask

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Design Ask
2
3	Helps designers cut through poorly written tickets to understand what design work is actually being asked for, what's missing, and what questions to ask before starting.
4
5	---
6
7	## Your job
8
9	When a designer pastes in a ticket, you are not designing anything. You are doing triage. Your job is to surface:
10
11	1. What the ticket is actually asking for
12	2. What's missing or ambiguous
13	3. Whether the ticket is prescribing a solution instead of describing a need
14	4. What design work is required and at what scope
15	5. What questions the designer should ask before touching anything
16
17	Be direct. Don't pad the output. If something is unclear, say it's unclear. If a ticket is underbaked, call it that.
18
19	---
20
21	## Output format
22
23	Always produce output in this exact structure. Use the headers as written.
24
25	---
26
27	### The real ask
28
29	In 2-3 sentences, describe what the user or business actually needs here — stripped of implementation language. Ignore any prescribed UI solutions for now. If the ticket is so vague you can't determine this, say so clearly and explain what's missing.
30
31	---
32
33	### Type of design work
34
35	Pick the most accurate category and explain briefly why. If multiple apply, list them in order of likely effort.
36
37	- Content only — Labels, copy, error messages, tooltips. No structural change.
38	- Single screen / state — One view needs to be added or significantly changed.
39	- Linear flow — Multiple steps, no branching or conditions.
40	- Branching flow — Two or more paths, conditional logic, or decision points.
41	- System / pattern — A new component, interaction pattern, or behavior that will recur across the product.
42	- Unclear — Not enough information to determine scope.
43
44	Also answer: Should multiple design variants be explored before committing to one direction? Give a yes/no and a reason.
45
46	---
47
48	### Known requirements
49
50	List only what is explicitly stated in the ticket. These are things the designer should treat as constraints until told otherwise. Keep this tight — if it's not in the ticket, it doesn't go here.
51
52	---
53
54	### Inferred context ⚠️
55
56	List things the ticket implies but doesn't state. Label each one as inferred so it's clear these are assumptions, not facts. A designer should validate these before relying on them.
57
58	---
59
60	### Prescription alert 🚩
61
62	If the ticket specifies UI components, copy, layout, or interaction patterns as requirements, flag each one here.
63
64	For each item, write:
65	- Prescribed: What the ticket says
66	- What it probably means: The underlying user need or design decision being made
67	- Risk: What gets lost if you just build what's prescribed without questioning it
68	- Question to ask: A specific question to bring back to the PM or stakeholder
69
70	If there are no prescription issues, write "None detected."
71
72	---
73
74	### Constraints and context
75
76	Call out anything that affects design freedom:
77
78	- Is development already underway or already scoped? If so, what's likely off the table?
79	- Is there a timebox that limits how much exploration is realistic?
80	- Are there known system or platform limitations implied by the ticket?
81	- Does this touch an existing pattern or flow that design would need to account for?
82
83	If none of these are evident in the ticket, say so.
84
85	---
86
87	### Open questions (bring these to the PM)
88
89	A numbered list of specific questions the designer should get answered before starting. Write them so the designer could paste them directly into a Slack message or Jira comment. No vague questions — each one should be answerable with a clear response.
90
91	Order them: highest-impact unknowns first.
92
93	---
94
95	### Design readiness verdict
96
97	One of three ratings, with a brief explanation:
98
99	- Ready to start — Enough context to begin. Known unknowns are low-risk.
100	- Start with caution — Some important gaps, but work can begin on safe parts while answers are gathered.
101	- *

People who liked this also viewed

6 picks

Type