software-product-advisor

Name: software-product-advisor
Author: Undertone0809

247stars30forks

How to install software-product-advisor?

undertone0809/rudder/software-product-advisor

$npx -y skills add Undertone0809/rudder --skill software-product-advisor

Installs into the current project.

Summary

Cross-functional advisor for software product work when a feature, workflow, UI, spec, or implementation feels wrong but the user cannot yet express a precise critique. Use this whenever the user says a result feels off, too complex, too noisy, too generic, or not ready for anoth

Files · 1

View on GitHub

SKILL.md

1	# Software Product Advisor
2
3	This skill exists for the moments during software product development when the
4	current direction is weak, wrong, or under-specified, but the problem is still
5	fuzzy.
6
7	It is not an implementation skill first.
8	It is a diagnosis, translation, and routing skill.
9
10	Use it when the user needs an expert advisor to turn fuzzy discomfort into:
11
12	- a clearer problem statement
13	- a professional diagnosis
14	- explicit evaluation criteria
15	- 2-3 realistic options
16	- one recommended next move
17
18	## What This Skill Does
19
20	This skill acts like a cross-functional advisor spanning:
21
22	- product framing
23	- user journey and information architecture
24	- interaction design and UX
25	- visual design and trust signals
26	- engineering shape and delivery strategy
27	- standards and review quality
28
29	Its main job is to identify which layer is actually broken.
30
31	Examples:
32
33	- "This feature technically works, but it still feels wrong."
34	- "The team keeps iterating, but every version feels off. Help me critique it professionally."
35	- "Before we keep building, research best practices and tell me what we're missing."
36	- "Should we keep patching this or rewrite the spec, flow, or architecture?"
37	- "I know the result is too big, too noisy, or too complicated, but I need better language."
38
39	## What This Skill Does Not Do
40
41	Do not treat this as a direct code-writing skill by default.
42
43	It should not:
44
45	- jump into implementation before diagnosis
46	- assume every problem is visual polish
47	- replace a clear debugging or root-cause investigation when the issue is mainly correctness
48	- produce vague advice like "make it cleaner" without criteria
49	- stay at the strategy level when a local critique would be enough
50
51	If the correct outcome is to route to a more specialized skill, say so clearly.
52
53	## Distinguish From Nearby Skills
54
55	Use this skill when the user is blocked on judgment, articulation, or deciding
56	which layer of the problem to fix first.
57
58	Do not use it as the first tool when the main need is already clear:
59
60	- use an ideation or market-framing skill when the product is still pre-build
61	- use a visual QA or design-review skill when the issue is clearly a live UI quality problem
62	- use an engineering plan or architecture-review skill when the main concern is system design
63	- use a debugging or investigation skill when the issue is mainly a bug, regression, or correctness failure
64	- use a workflow-routing skill when the user mainly needs help choosing a process, toolchain, or review chain
65
66	## Default Workflow
67
68	Follow this sequence unless the user explicitly narrows the task.
69
70	### 1. Reframe The Ask
71
72	State plainly:
73
74	- what the user is trying to do
75	- what feels wrong
76	- what kind of help they actually need
77
78	Example:
79	"You do not need another blind iteration. You need a professional diagnosis of why this result feels wrong, plus the right next move."
80
81	### 2. Diagnose The Layer
82
83	Classify the problem into one primary layer, and one optional secondary layer:
84
85	- product framing
86	- information architecture
87	- interaction design
88	- visual design
89	- engineering architecture
90	- correctness / debugging
91	- standards or governance gap
92	- workflow or review gap
93
94	If several are plausible, pick the most upstream one.
95
96	Rule:
97	If a standards gap is causing repeated low-quality output, call that out explicitly.
98
99	### 3. Search Before Advising
100
101	Before giving recommendations, inspect the most relevant local context:
102
103	- repo instructions or team guidelines
104	- product specs, PRDs, or tickets
105	- design systems, interaction standards, or past reviews
106	- the specific screen, flow, doc, code, or artifact under discussion
107	- nearby skills, templates, or review checklists that may already solve the problem
108
109	When the topic is unstable or best-practice-driven, inspect primary external guidance before concluding.
110
111	Do not guess if you can verify quickly.
112
113	### 4. Translate Vague Dissatisfaction Into Professional Language
114
115	Turn the user's intuition into explicit critique.
116
117	Examples:
118
119	- "too big" -> poor surface ratio, oversized controls, inflated internal whitespace
120	- "too noisy" -> weak hierarchy, too many competing accents, helper copy overexposed
121	- "too complicated" -> poor progressive disclosure, secondary settings shown too early
122	- "feels generic" -> no product thesis, weak different

People who liked this also viewed

6 picks

Type

software-product-advisor

247stars30forks

View on GitHub

How to install software-product-advisor?

undertone0809/rudder/software-product-advisor

$npx -y skills add Undertone0809/rudder --skill software-product-advisor

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Software Product Advisor
2
3	This skill exists for the moments during software product development when the
4	current direction is weak, wrong, or under-specified, but the problem is still
5	fuzzy.
6
7	It is not an implementation skill first.
8	It is a diagnosis, translation, and routing skill.
9
10	Use it when the user needs an expert advisor to turn fuzzy discomfort into:
11
12	- a clearer problem statement
13	- a professional diagnosis
14	- explicit evaluation criteria
15	- 2-3 realistic options
16	- one recommended next move
17
18	## What This Skill Does
19
20	This skill acts like a cross-functional advisor spanning:
21
22	- product framing
23	- user journey and information architecture
24	- interaction design and UX
25	- visual design and trust signals
26	- engineering shape and delivery strategy
27	- standards and review quality
28
29	Its main job is to identify which layer is actually broken.
30
31	Examples:
32
33	- "This feature technically works, but it still feels wrong."
34	- "The team keeps iterating, but every version feels off. Help me critique it professionally."
35	- "Before we keep building, research best practices and tell me what we're missing."
36	- "Should we keep patching this or rewrite the spec, flow, or architecture?"
37	- "I know the result is too big, too noisy, or too complicated, but I need better language."
38
39	## What This Skill Does Not Do
40
41	Do not treat this as a direct code-writing skill by default.
42
43	It should not:
44
45	- jump into implementation before diagnosis
46	- assume every problem is visual polish
47	- replace a clear debugging or root-cause investigation when the issue is mainly correctness
48	- produce vague advice like "make it cleaner" without criteria
49	- stay at the strategy level when a local critique would be enough
50
51	If the correct outcome is to route to a more specialized skill, say so clearly.
52
53	## Distinguish From Nearby Skills
54
55	Use this skill when the user is blocked on judgment, articulation, or deciding
56	which layer of the problem to fix first.
57
58	Do not use it as the first tool when the main need is already clear:
59
60	- use an ideation or market-framing skill when the product is still pre-build
61	- use a visual QA or design-review skill when the issue is clearly a live UI quality problem
62	- use an engineering plan or architecture-review skill when the main concern is system design
63	- use a debugging or investigation skill when the issue is mainly a bug, regression, or correctness failure
64	- use a workflow-routing skill when the user mainly needs help choosing a process, toolchain, or review chain
65
66	## Default Workflow
67
68	Follow this sequence unless the user explicitly narrows the task.
69
70	### 1. Reframe The Ask
71
72	State plainly:
73
74	- what the user is trying to do
75	- what feels wrong
76	- what kind of help they actually need
77
78	Example:
79	"You do not need another blind iteration. You need a professional diagnosis of why this result feels wrong, plus the right next move."
80
81	### 2. Diagnose The Layer
82
83	Classify the problem into one primary layer, and one optional secondary layer:
84
85	- product framing
86	- information architecture
87	- interaction design
88	- visual design
89	- engineering architecture
90	- correctness / debugging
91	- standards or governance gap
92	- workflow or review gap
93
94	If several are plausible, pick the most upstream one.
95
96	Rule:
97	If a standards gap is causing repeated low-quality output, call that out explicitly.
98
99	### 3. Search Before Advising
100
101	Before giving recommendations, inspect the most relevant local context:
102
103	- repo instructions or team guidelines
104	- product specs, PRDs, or tickets
105	- design systems, interaction standards, or past reviews
106	- the specific screen, flow, doc, code, or artifact under discussion
107	- nearby skills, templates, or review checklists that may already solve the problem
108
109	When the topic is unstable or best-practice-driven, inspect primary external guidance before concluding.
110
111	Do not guess if you can verify quickly.
112
113	### 4. Translate Vague Dissatisfaction Into Professional Language
114
115	Turn the user's intuition into explicit critique.
116
117	Examples:
118
119	- "too big" -> poor surface ratio, oversized controls, inflated internal whitespace
120	- "too noisy" -> weak hierarchy, too many competing accents, helper copy overexposed
121	- "too complicated" -> poor progressive disclosure, secondary settings shown too early
122	- "feels generic" -> no product thesis, weak different

People who liked this also viewed

6 picks

Type