game-design-kpi-coverage-audit

Name: game-design-kpi-coverage-audit
Author: Stanestane

34stars3forks

How to install game-design-kpi-coverage-audit?

stanestane/game-design-skills-bundle/game-design-kpi-coverage-audit

$npx -y skills add Stanestane/game-design-skills-bundle --skill game-design-kpi-coverage-audit

Installs into the current project.

Summary

Audit a game feature, roadmap candidate, UX improvement, support system, connective-tissue feature, or quality-of-life change for KPI coverage bias and measurement blind spots. Use when a team is overvaluing only directly attributable metrics, neglecting foundational work that is

Files · 1

View on GitHub

SKILL.md

1	# Game Design KPI Coverage Audit
2
3	Check whether the evaluation framework is seeing the whole value of the feature, or only the parts that are easy to measure.
4
5	Use this skill when a feature is being judged mainly through directly attributable KPIs and you suspect that measurement logic is biasing the team toward flashy, self-contained systems while undervaluing connective tissue, UX, quality-of-life, enabling systems, or long-term structural work.
6
7	Read `references/value-types.md` when identifying what kind of value the feature creates.
8	Read `references/blind-spot-patterns.md` when diagnosing common KPI-coverage failures.
9	Read `references/recommendation-patterns.md` when deciding how to justify or evaluate hard-to-measure work.
10
11	## What to produce
12
13	Produce:
14	1. Feature read - what the proposal is and what role it plays
15	2. Current KPI framing - what the team is measuring or expecting to measure
16	3. Coverage diagnosis - what value is covered versus ignored by those KPIs
17	4. Blind spots - what may be neglected because it is hard to measure directly
18	5. Risk of mis-prioritization - what bad decisions may result from the current framing
19	6. Evaluation recommendation - how the feature should be justified, monitored, or compared more fairly
20
21	## Process
22
23	### 1. Identify the role of the feature
24	Clarify whether the proposal is mainly:
25	- a standalone engagement feature
26	- a monetization feature
27	- a progression layer
28	- a UX improvement
29	- connective tissue between systems
30	- quality-of-life work
31	- support infrastructure for future features
32	- a clarity, pacing, or usability improvement
33
34	### 2. Identify the current KPI story
35	Ask:
36	- what metric is the team using to justify this feature?
37	- is it tied to revenue, retention, engagement, conversion, economy balance, sentiment, or something else?
38	- is the KPI direct, indirect, speculative, or absent?
39
40	### 3. Audit KPI coverage
41	Check whether the metric framing captures the actual value of the work.
42	Look for value types such as:
43	- direct monetization
44	- direct engagement lift
45	- retention support
46	- reduced friction
47	- improved comprehension
48	- stronger connective tissue between systems
49	- future feature enablement
50	- long-term sustainability
51	- reduced support burden or balancing burden
52
53	### 4. Identify blind spots
54	Common signs:
55	- the feature is dismissed because it cannot move one headline KPI on its own
56	- direct-revenue features are always favored over structural health
57	- UX work is treated as optional because it lacks clean attribution
58	- foundational work is postponed until crisis
59	- enabling systems are undervalued because they mostly improve the performance of other features
60
61	### 5. Judge prioritization risk
62	Ask:
63	- what happens if this feature is judged only by direct KPI lift?
64	- is the team likely to underinvest in maintenance, UX, clarity, infrastructure, or connective tissue?
65	- could the current framework systematically reward short-term visible wins over long-term health?
66
67	### 6. Recommend better evaluation
68	Possible moves:
69	- use a mixed scorecard instead of one KPI
70	- classify the feature as enabling or connective work rather than forcing a fake direct KPI
71	- evaluate via downstream support of other systems
72	- allocate protected capacity for high-value, hard-to-measure work
73	- compare opportunity cost honestly rather than pretending everything must tie to one direct metric
74
75	## Response structure
76
77	### Feature Read
78	- ...
79
80	### Current KPI Framing
81	- ...
82
83	### Coverage Diagnosis
84	- ...
85
86	### Blind Spots
87	- ...
88
89	### Risk of Mis-Prioritization
90	- ...
91
92	### Recommendation
93	- ...
94
95	## Fast mode
96	- What is this feature actually for?
97	- What KPI is being used to justify it?
98	- What important value is not being captured by that KPI?
99	- What bad prioritization decision could this cause?
100	- How should the team evaluate it more fairly?
101
102	## Style rules
103	- Do not dismiss KPIs; diagnose their limits.
104	- Do not invent fake measurable certainty for support work.
105	- Distinguish direct value from enabling value.
106	- Prefer fairer framing over anti-metrics rhetoric.
107	- Be specific about how blind spots distort roadmap decisions.
108
109	## Working principle
110
111	Teams often prioritize what they can measure cleanly, not what matters most.
112	Use this skill to expose where KPI logic is too narrow for the actual design value on the table.

People who liked this also viewed

6 picks

Type

game-design-kpi-coverage-audit

34stars3forks

View on GitHub

How to install game-design-kpi-coverage-audit?

stanestane/game-design-skills-bundle/game-design-kpi-coverage-audit

$npx -y skills add Stanestane/game-design-skills-bundle --skill game-design-kpi-coverage-audit

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Game Design KPI Coverage Audit
2
3	Check whether the evaluation framework is seeing the whole value of the feature, or only the parts that are easy to measure.
4
5	Use this skill when a feature is being judged mainly through directly attributable KPIs and you suspect that measurement logic is biasing the team toward flashy, self-contained systems while undervaluing connective tissue, UX, quality-of-life, enabling systems, or long-term structural work.
6
7	Read `references/value-types.md` when identifying what kind of value the feature creates.
8	Read `references/blind-spot-patterns.md` when diagnosing common KPI-coverage failures.
9	Read `references/recommendation-patterns.md` when deciding how to justify or evaluate hard-to-measure work.
10
11	## What to produce
12
13	Produce:
14	1. Feature read - what the proposal is and what role it plays
15	2. Current KPI framing - what the team is measuring or expecting to measure
16	3. Coverage diagnosis - what value is covered versus ignored by those KPIs
17	4. Blind spots - what may be neglected because it is hard to measure directly
18	5. Risk of mis-prioritization - what bad decisions may result from the current framing
19	6. Evaluation recommendation - how the feature should be justified, monitored, or compared more fairly
20
21	## Process
22
23	### 1. Identify the role of the feature
24	Clarify whether the proposal is mainly:
25	- a standalone engagement feature
26	- a monetization feature
27	- a progression layer
28	- a UX improvement
29	- connective tissue between systems
30	- quality-of-life work
31	- support infrastructure for future features
32	- a clarity, pacing, or usability improvement
33
34	### 2. Identify the current KPI story
35	Ask:
36	- what metric is the team using to justify this feature?
37	- is it tied to revenue, retention, engagement, conversion, economy balance, sentiment, or something else?
38	- is the KPI direct, indirect, speculative, or absent?
39
40	### 3. Audit KPI coverage
41	Check whether the metric framing captures the actual value of the work.
42	Look for value types such as:
43	- direct monetization
44	- direct engagement lift
45	- retention support
46	- reduced friction
47	- improved comprehension
48	- stronger connective tissue between systems
49	- future feature enablement
50	- long-term sustainability
51	- reduced support burden or balancing burden
52
53	### 4. Identify blind spots
54	Common signs:
55	- the feature is dismissed because it cannot move one headline KPI on its own
56	- direct-revenue features are always favored over structural health
57	- UX work is treated as optional because it lacks clean attribution
58	- foundational work is postponed until crisis
59	- enabling systems are undervalued because they mostly improve the performance of other features
60
61	### 5. Judge prioritization risk
62	Ask:
63	- what happens if this feature is judged only by direct KPI lift?
64	- is the team likely to underinvest in maintenance, UX, clarity, infrastructure, or connective tissue?
65	- could the current framework systematically reward short-term visible wins over long-term health?
66
67	### 6. Recommend better evaluation
68	Possible moves:
69	- use a mixed scorecard instead of one KPI
70	- classify the feature as enabling or connective work rather than forcing a fake direct KPI
71	- evaluate via downstream support of other systems
72	- allocate protected capacity for high-value, hard-to-measure work
73	- compare opportunity cost honestly rather than pretending everything must tie to one direct metric
74
75	## Response structure
76
77	### Feature Read
78	- ...
79
80	### Current KPI Framing
81	- ...
82
83	### Coverage Diagnosis
84	- ...
85
86	### Blind Spots
87	- ...
88
89	### Risk of Mis-Prioritization
90	- ...
91
92	### Recommendation
93	- ...
94
95	## Fast mode
96	- What is this feature actually for?
97	- What KPI is being used to justify it?
98	- What important value is not being captured by that KPI?
99	- What bad prioritization decision could this cause?
100	- How should the team evaluate it more fairly?
101
102	## Style rules
103	- Do not dismiss KPIs; diagnose their limits.
104	- Do not invent fake measurable certainty for support work.
105	- Distinguish direct value from enabling value.
106	- Prefer fairer framing over anti-metrics rhetoric.
107	- Be specific about how blind spots distort roadmap decisions.
108
109	## Working principle
110
111	Teams often prioritize what they can measure cleanly, not what matters most.
112	Use this skill to expose where KPI logic is too narrow for the actual design value on the table.

People who liked this also viewed

6 picks

Type