product-acceptance-verifier-maintainer

Name: product-acceptance-verifier-maintainer
Author: Undertone0809

247stars30forks

How to install product-acceptance-verifier-maintainer?

undertone0809/rudder/product-acceptance-verifier-maintainer

$npx -y skills add Undertone0809/rudder --skill product-acceptance-verifier-maintainer

Installs into the current project.

Summary

Use when implemented Rudder feature, UI, workflow, Desktop, CLI, runtime, release, or regression work needs black-box acceptance verification against user requirements and the running product surface.

Files · 1

View on GitHub

SKILL.md

1	# Product Acceptance Verifier Maintainer
2
3	Verify delivered Rudder work from the requirement side. This is an acceptance
4	workflow, not a code-review or implementation workflow.
5
6	The core question is:
7
8	> Does the running product do what the user asked, on the real surface where the
9	> result is consumed?
10
11	Default to Chinese when the user asks in Chinese. Keep the conclusion early and
12	ground it in observed behavior.
13
14	## Role Boundary
15
16	Verifier is black-box by default:
17
18	- Start from the user request, acceptance criteria, product contracts, and
19	user-visible or agent-visible workflow.
20	- Run commands, start local services, use Browser or Computer Use, inspect
21	logs, query APIs, and read database state when needed.
22	- Create disposable dev data when necessary for proof, and record the mutation
23	ledger.
24	- Do not edit files, stage changes, commit, push, or fix the bug you find.
25	- Do not perform a general diff review unless it is needed to identify the
26	correct product surface or acceptance criteria.
27
28	If acceptance fails, report the failure and stop. The writer or parent workflow
29	owns fixes and reruns.
30
31	## Use When
32
33	Use this skill for:
34
35	- final verification after a feature, bug fix, UI change, Desktop change,
36	runtime/CLI change, release, or regression fix
37	- user corrections such as "你真的跑过了吗", "我验收结果", "功能上真的好了?"
38	- checking whether a code-reviewed change still misses the requested outcome
39	- rerunning failed acceptance paths after a writer fixes them
40	- black-box verification of product behavior before final handoff
41
42	Do not use this skill for:
43
44	- pure code review, architecture critique, or PR hygiene; use
45	`agent-work-reviewer-maintainer`
46	- unclear requirements before there is an implemented artifact; use the
47	lifecycle router, advisor, or requirements stage first
48	- fixing acceptance failures during the same verifier pass
49	- release publishing actions; verify release state only after the release owner
50	has produced artifacts or asks for acceptance verification
51
52	## Inputs
53
54	Build a compact acceptance packet before running checks:
55
56	- user request and any later corrections
57	- explicit acceptance criteria, or the missing criteria that block judgment
58	- non-goals and changed scope
59	- current product contracts under `doc/product/**` when product logic matters
60	- target runtime: dev web, packaged Desktop, CLI, agent runtime, release, or
61	another terminal surface
62	- related old workflows that could regress
63	- author-claimed tests, screenshots, CI, or reviewer findings, labeled as
64	supporting evidence until independently inspected
65
66	If acceptance criteria are ambiguous, return `QUESTION` with the exact missing
67	decision instead of inventing product intent.
68
69	## Verification Procedure
70
71	### 1. State the acceptance target
72
73	Name the actor, trigger, system effect, and terminal surface:
74
75	- actor: operator, agent, reviewer, CLI user, Desktop user, automation, release
76	consumer
77	- trigger: click, command, API action, heartbeat, scheduled run, install, update
78	- system effect: persisted issue state, comment, run, artifact, UI state, cost,
79	release asset, or setting
80	- terminal surface: UI route, packaged Desktop shell, CLI output, API readback,
81	run-intelligence view, npm/GitHub release state, or screenshot
82
83	Also decide whether the request requires real-environment proof. Mark the run
84	`REAL_ENV_REQUIRED` when the user explicitly asks for real/local/live
85	verification or challenges prior proof, including phrases such as "真实环境",
86	"本地真实环境", "真实的本地", "在我电脑上", "真实飞书", "飞书测试", "我验收结果",
87	"你真的跑过了吗", or "不是 mock/不是单测". For `REAL_ENV_REQUIRED`, the named
88	terminal surface is the actual local/live surface, not a substitute.
89
90	### 2. Run the product path
91
92	Use the strongest safe path available:
93
94	- UI/workflow: open the local route with Browser or Computer Use, perform the
95	user-visible action, and inspect the resulting state.
96	- Desktop: use packaged verification or Computer Use for native shell behavior,
97	menus, update prompts, profile routing, drag/drop, and local data paths.
98	- CLI/agent runtime: run the actor command or wakeup when practical, then read
99	back issue/run/comment/API/DB state and the terminal CLI/UI surface.
100	- Release: verify live npm, tag, GitHub Release, asset, workflow, and install
101	surfaces for the intended channel.
102	- Visual acceptance: inspect screenshots or the live rendered route. For
103	alignment or row rhythm, prefer DOM geometry or centerline deltas with
104	production-shaped data.
105
106	Unit tests, typecheck, build, CI, or diff review are supporting evidence. They
107	do not replace terminal product behavior when the product path can be exercised.
108
109	For `REAL_ENV_REQUIRED`, do not return `PASS` unless the real requested
110	environment was exercised successfully. Mocked services,

People who liked this also viewed

6 picks

Type

product-acceptance-verifier-maintainer

247stars30forks

View on GitHub

How to install product-acceptance-verifier-maintainer?

undertone0809/rudder/product-acceptance-verifier-maintainer

$npx -y skills add Undertone0809/rudder --skill product-acceptance-verifier-maintainer

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Product Acceptance Verifier Maintainer
2
3	Verify delivered Rudder work from the requirement side. This is an acceptance
4	workflow, not a code-review or implementation workflow.
5
6	The core question is:
7
8	> Does the running product do what the user asked, on the real surface where the
9	> result is consumed?
10
11	Default to Chinese when the user asks in Chinese. Keep the conclusion early and
12	ground it in observed behavior.
13
14	## Role Boundary
15
16	Verifier is black-box by default:
17
18	- Start from the user request, acceptance criteria, product contracts, and
19	user-visible or agent-visible workflow.
20	- Run commands, start local services, use Browser or Computer Use, inspect
21	logs, query APIs, and read database state when needed.
22	- Create disposable dev data when necessary for proof, and record the mutation
23	ledger.
24	- Do not edit files, stage changes, commit, push, or fix the bug you find.
25	- Do not perform a general diff review unless it is needed to identify the
26	correct product surface or acceptance criteria.
27
28	If acceptance fails, report the failure and stop. The writer or parent workflow
29	owns fixes and reruns.
30
31	## Use When
32
33	Use this skill for:
34
35	- final verification after a feature, bug fix, UI change, Desktop change,
36	runtime/CLI change, release, or regression fix
37	- user corrections such as "你真的跑过了吗", "我验收结果", "功能上真的好了?"
38	- checking whether a code-reviewed change still misses the requested outcome
39	- rerunning failed acceptance paths after a writer fixes them
40	- black-box verification of product behavior before final handoff
41
42	Do not use this skill for:
43
44	- pure code review, architecture critique, or PR hygiene; use
45	`agent-work-reviewer-maintainer`
46	- unclear requirements before there is an implemented artifact; use the
47	lifecycle router, advisor, or requirements stage first
48	- fixing acceptance failures during the same verifier pass
49	- release publishing actions; verify release state only after the release owner
50	has produced artifacts or asks for acceptance verification
51
52	## Inputs
53
54	Build a compact acceptance packet before running checks:
55
56	- user request and any later corrections
57	- explicit acceptance criteria, or the missing criteria that block judgment
58	- non-goals and changed scope
59	- current product contracts under `doc/product/**` when product logic matters
60	- target runtime: dev web, packaged Desktop, CLI, agent runtime, release, or
61	another terminal surface
62	- related old workflows that could regress
63	- author-claimed tests, screenshots, CI, or reviewer findings, labeled as
64	supporting evidence until independently inspected
65
66	If acceptance criteria are ambiguous, return `QUESTION` with the exact missing
67	decision instead of inventing product intent.
68
69	## Verification Procedure
70
71	### 1. State the acceptance target
72
73	Name the actor, trigger, system effect, and terminal surface:
74
75	- actor: operator, agent, reviewer, CLI user, Desktop user, automation, release
76	consumer
77	- trigger: click, command, API action, heartbeat, scheduled run, install, update
78	- system effect: persisted issue state, comment, run, artifact, UI state, cost,
79	release asset, or setting
80	- terminal surface: UI route, packaged Desktop shell, CLI output, API readback,
81	run-intelligence view, npm/GitHub release state, or screenshot
82
83	Also decide whether the request requires real-environment proof. Mark the run
84	`REAL_ENV_REQUIRED` when the user explicitly asks for real/local/live
85	verification or challenges prior proof, including phrases such as "真实环境",
86	"本地真实环境", "真实的本地", "在我电脑上", "真实飞书", "飞书测试", "我验收结果",
87	"你真的跑过了吗", or "不是 mock/不是单测". For `REAL_ENV_REQUIRED`, the named
88	terminal surface is the actual local/live surface, not a substitute.
89
90	### 2. Run the product path
91
92	Use the strongest safe path available:
93
94	- UI/workflow: open the local route with Browser or Computer Use, perform the
95	user-visible action, and inspect the resulting state.
96	- Desktop: use packaged verification or Computer Use for native shell behavior,
97	menus, update prompts, profile routing, drag/drop, and local data paths.
98	- CLI/agent runtime: run the actor command or wakeup when practical, then read
99	back issue/run/comment/API/DB state and the terminal CLI/UI surface.
100	- Release: verify live npm, tag, GitHub Release, asset, workflow, and install
101	surfaces for the intended channel.
102	- Visual acceptance: inspect screenshots or the live rendered route. For
103	alignment or row rhythm, prefer DOM geometry or centerline deltas with
104	production-shaped data.
105
106	Unit tests, typecheck, build, CI, or diff review are supporting evidence. They
107	do not replace terminal product behavior when the product path can be exercised.
108
109	For `REAL_ENV_REQUIRED`, do not return `PASS` unless the real requested
110	environment was exercised successfully. Mocked services,

People who liked this also viewed

6 picks

Type