agent-work-reviewer-maintainer

Name: agent-work-reviewer-maintainer
Author: Undertone0809

247stars30forks

How to install agent-work-reviewer-maintainer?

undertone0809/rudder/agent-work-reviewer-maintainer

$npx -y skills add Undertone0809/rudder --skill agent-work-reviewer-maintainer

Installs into the current project.

Summary

Use when reviewing Rudder agent work, Codex sessions, PRs, commits, UI, releases, regressions, proposals, or agent outcomes for product correctness, evidence quality, scope, architecture, and handoff trust.

Files · 1

View on GitHub

SKILL.md

1	# Agent Work Reviewer Maintainer
2
3	Review completed or in-progress Rudder agent work. This is a reviewer workflow,
4	not an implementation workflow.
5
6	The core question is:
7
8	> Did the agent solve the right product problem, with the right object model,
9	> complete behavior, credible validation, and a clean handoff?
10
11	Reviewer is not the same role as verifier. Reviewer may inspect the running
12	product when that is needed for judgment, but its durable responsibility is to
13	judge the diff, architecture, scope, test strategy, handoff safety, and the
14	credibility of acceptance evidence. For black-box acceptance of final product
15	behavior, use `product-acceptance-verifier-maintainer`.
16
17	Default to Chinese when the user asks in Chinese. Keep the verdict early and
18	ground every judgment in evidence.
19
20	## Use When
21
22	Use this skill when the user asks to review:
23
24	- a Codex session, Rudder agent run, task, or transcript
25	- a local branch, commit, diff, pull request, or implementation
26	- a product proposal, plan doc, feature spec, or UI direction
27	- a release verification, Desktop install path, npm publish, or canary/stable
28	handoff
29	- a screenshot, browser state, visual interaction, or workflow that "feels
30	wrong"
31
32	Common trigger phrases:
33
34	- "review 一下 codex session id ..."
35	- "as a 专业产品经理 review"
36	- "第一性原理思考一下"
37	- "作为 reviewer"
38	- "这个实现是不是产品上对"
39	- "这个 PR 本地跑起来看一下有没有问题"
40	- "这次 release 验证做完了吗"
41	- "我觉得这个功能之前有，现在没了"
42
43	## Do Not Use When
44
45	Do not use this skill for:
46
47	- fixing the findings during the same reviewer pass, unless the user explicitly
48	asks to implement fixes
49	- generic line-by-line code review where product judgment is irrelevant
50	- debugging a failed Rudder agent run root cause only; use the run transcript
51	debugging workflow first, then return here for product/workflow judgment
52	- summarizing logs without verdict or acceptance criteria
53
54	If the user asks to fix findings after the review, switch to normal
55	implementation mode and follow repository validation, commit, and push rules.
56
57	### Read-Only Guard
58
59	Reviewer mode is read-only by default. Do not edit files, stage changes,
60	restore files, commit, push, start destructive cleanup, or "just fix" findings
61	while reviewing unless the user explicitly changes the task from review to
62	implementation.
63
64	If the user says "do not implement", "review only", or assigns a reviewer role,
65	that instruction is binding for the whole reviewer pass. Use tools only to
66	inspect evidence.
67
68	Direct UI inspection with Browser, Desktop, or Computer Use is still reviewer
69	work when it only observes or exercises low-risk local/dev flows. If a realistic
70	scenario requires mutating Rudder data, prefer an isolated dev org, disposable
71	test records, or an existing preview instance, and report what was created or
72	changed. Do not delete data, publish, submit external communication, install
73	software, change system settings, or perform other risky UI actions without the
74	appropriate user confirmation.
75
76	## Evidence Packet
77
78	Never start with opinion. Build the smallest evidence packet that can support a
79	real judgment.
80
81	### 1. Identify The Target
82
83	Resolve what is being reviewed:
84
85	- Codex session id or prefix
86	- Rudder run id or transcript
87	- PR number or URL
88	- branch name, commit hash, staged/unstaged diff
89	- plan doc, proposal, screenshot, or browser URL
90	- release version, tag, workflow run, npm dist-tag, or Desktop asset set
91
92	If the user is vague, infer from current branch, recent commits, open browser
93	state, or named files before asking.
94
95	### 2. Collect Task Intent
96
97	For Codex sessions, search:
98
99	```bash
100	rg "<session-id-or-prefix>" ~/.codex/session_index.jsonl ~/.codex/sessions ~/.codex/archived_sessions
101	```
102
103	Extract real user requests and corrections. Ignore injected `AGENTS.md`,
104	environment context, skill bodies, and system/developer text.
105
106	For branches, PRs, commits, or diffs, inspect:
107
108	```bash
109	git status --short --branch
110	git log --oneline --decorate -12
111	git diff --stat
112	git diff
113	git show --stat <commit>
114	git show <commit>
115	```
116
117	For commit or session reviews, also compare the changed-file set against the
118	stated task. Classify every surprising file as one of:
119
120	- required for the requested behavior
121	- test, docs, or contract evidence for the requested behavior
122	- pre-existing unrelated dirty work
123	- unrelated change mixed into the reviewed commit or handoff
124
125	Unrelated changes mixed into a product fix are review findings, not cleanup
126	details. If they change skills, release state, generated files, dependencies,
127	or broad runtime behavior outside the task, usually treat that as at least a
128	`conditional accept` blocker until the scope is split or justified.
129
130	For PRs, read the PR description, changed files, review comments, and CI status
131	when available.
132
133	### 3. Read Product Context
134
135	For

People who liked this also viewed

6 picks

Type

agent-work-reviewer-maintainer

247stars30forks

View on GitHub

How to install agent-work-reviewer-maintainer?

undertone0809/rudder/agent-work-reviewer-maintainer

$npx -y skills add Undertone0809/rudder --skill agent-work-reviewer-maintainer

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Agent Work Reviewer Maintainer
2
3	Review completed or in-progress Rudder agent work. This is a reviewer workflow,
4	not an implementation workflow.
5
6	The core question is:
7
8	> Did the agent solve the right product problem, with the right object model,
9	> complete behavior, credible validation, and a clean handoff?
10
11	Reviewer is not the same role as verifier. Reviewer may inspect the running
12	product when that is needed for judgment, but its durable responsibility is to
13	judge the diff, architecture, scope, test strategy, handoff safety, and the
14	credibility of acceptance evidence. For black-box acceptance of final product
15	behavior, use `product-acceptance-verifier-maintainer`.
16
17	Default to Chinese when the user asks in Chinese. Keep the verdict early and
18	ground every judgment in evidence.
19
20	## Use When
21
22	Use this skill when the user asks to review:
23
24	- a Codex session, Rudder agent run, task, or transcript
25	- a local branch, commit, diff, pull request, or implementation
26	- a product proposal, plan doc, feature spec, or UI direction
27	- a release verification, Desktop install path, npm publish, or canary/stable
28	handoff
29	- a screenshot, browser state, visual interaction, or workflow that "feels
30	wrong"
31
32	Common trigger phrases:
33
34	- "review 一下 codex session id ..."
35	- "as a 专业产品经理 review"
36	- "第一性原理思考一下"
37	- "作为 reviewer"
38	- "这个实现是不是产品上对"
39	- "这个 PR 本地跑起来看一下有没有问题"
40	- "这次 release 验证做完了吗"
41	- "我觉得这个功能之前有，现在没了"
42
43	## Do Not Use When
44
45	Do not use this skill for:
46
47	- fixing the findings during the same reviewer pass, unless the user explicitly
48	asks to implement fixes
49	- generic line-by-line code review where product judgment is irrelevant
50	- debugging a failed Rudder agent run root cause only; use the run transcript
51	debugging workflow first, then return here for product/workflow judgment
52	- summarizing logs without verdict or acceptance criteria
53
54	If the user asks to fix findings after the review, switch to normal
55	implementation mode and follow repository validation, commit, and push rules.
56
57	### Read-Only Guard
58
59	Reviewer mode is read-only by default. Do not edit files, stage changes,
60	restore files, commit, push, start destructive cleanup, or "just fix" findings
61	while reviewing unless the user explicitly changes the task from review to
62	implementation.
63
64	If the user says "do not implement", "review only", or assigns a reviewer role,
65	that instruction is binding for the whole reviewer pass. Use tools only to
66	inspect evidence.
67
68	Direct UI inspection with Browser, Desktop, or Computer Use is still reviewer
69	work when it only observes or exercises low-risk local/dev flows. If a realistic
70	scenario requires mutating Rudder data, prefer an isolated dev org, disposable
71	test records, or an existing preview instance, and report what was created or
72	changed. Do not delete data, publish, submit external communication, install
73	software, change system settings, or perform other risky UI actions without the
74	appropriate user confirmation.
75
76	## Evidence Packet
77
78	Never start with opinion. Build the smallest evidence packet that can support a
79	real judgment.
80
81	### 1. Identify The Target
82
83	Resolve what is being reviewed:
84
85	- Codex session id or prefix
86	- Rudder run id or transcript
87	- PR number or URL
88	- branch name, commit hash, staged/unstaged diff
89	- plan doc, proposal, screenshot, or browser URL
90	- release version, tag, workflow run, npm dist-tag, or Desktop asset set
91
92	If the user is vague, infer from current branch, recent commits, open browser
93	state, or named files before asking.
94
95	### 2. Collect Task Intent
96
97	For Codex sessions, search:
98
99	```bash
100	rg "<session-id-or-prefix>" ~/.codex/session_index.jsonl ~/.codex/sessions ~/.codex/archived_sessions
101	```
102
103	Extract real user requests and corrections. Ignore injected `AGENTS.md`,
104	environment context, skill bodies, and system/developer text.
105
106	For branches, PRs, commits, or diffs, inspect:
107
108	```bash
109	git status --short --branch
110	git log --oneline --decorate -12
111	git diff --stat
112	git diff
113	git show --stat <commit>
114	git show <commit>
115	```
116
117	For commit or session reviews, also compare the changed-file set against the
118	stated task. Classify every surprising file as one of:
119
120	- required for the requested behavior
121	- test, docs, or contract evidence for the requested behavior
122	- pre-existing unrelated dirty work
123	- unrelated change mixed into the reviewed commit or handoff
124
125	Unrelated changes mixed into a product fix are review findings, not cleanup
126	details. If they change skills, release state, generated files, dependencies,
127	or broad runtime behavior outside the task, usually treat that as at least a
128	`conditional accept` blocker until the scope is split or justified.
129
130	For PRs, read the PR description, changed files, review comments, and CI status
131	when available.
132
133	### 3. Read Product Context
134
135	For

People who liked this also viewed

6 picks

Type