codex-session-product-reviewer-maintainer

Name: codex-session-product-reviewer-maintainer
Author: Undertone0809

247stars30forks

How to install codex-session-product-reviewer-maintainer?

undertone0809/rudder/codex-session-product-reviewer-maintainer

$npx -y skills add Undertone0809/rudder --skill codex-session-product-reviewer-maintainer

Installs into the current project.

Summary

Use when reviewing a local Codex session, task, thread, or commit as a product manager or first-principles reviewer for product correctness, scope, behavior, validation, and whether the task solved the right user problem.

Files · 1

View on GitHub

SKILL.md

1	# Codex Session Product Reviewer Maintainer
2
3	This skill reviews a completed or in-progress Codex task from a product
4	manager's point of view. It is a reviewer workflow, not an implementation
5	workflow.
6
7	The core question is:
8
9	> Did this session solve the right product problem, with the right scope,
10	> behavior, and validation?
11
12	Use it to turn a vague request like "review this Codex session as a PM" into a
13	grounded product review based on the session transcript, actual code changes,
14	tests, plan docs, and repository product standards.
15
16	## Use When
17
18	Use this skill when the user asks to:
19
20	- review a Codex session id, task, thread, or run as a product manager
21	- evaluate whether another agent's implementation was product-correct
22	- apply first-principles thinking to a shipped task
23	- judge whether a proposal or implementation solved the right user problem
24	- produce a reviewer-style accept / conditional accept / reject
25	- translate fuzzy dissatisfaction into explicit product critique
26
27	Common trigger phrases:
28
29	- "review 一下 codex session id ..."
30	- "as a 专业的产品经理 review"
31	- "第一性原理思考一下"
32	- "作为 reviewer"
33	- "PM review this task"
34	- "这个 session 做得怎么样"
35	- "这个实现是不是产品上对"
36
37	## Do Not Use When
38
39	Do not use this skill for:
40
41	- generic code review where the user mainly wants bugs and line comments
42	- debugging a failed Rudder agent run transcript
43	- creating a new product idea or brainstorming from scratch
44	- implementing the fixes found during review, unless the user explicitly asks
45	- summarizing a session without judgment
46	- judging only from the final assistant message when local evidence is
47	available
48
49	If the user asks for code correctness review, use a code-review workflow.
50	If the user asks why a Rudder agent run failed, use the run transcript debugging
51	workflow first.
52
53	## Inputs
54
55	Required:
56
57	- A Codex session id, commit hash, PR, branch, or clearly identified task to
58	review.
59
60	Optional:
61
62	- The review lens, such as PM, first principles, design, workflow, release, or
63	founder mode.
64	- A desired output style, such as short verdict, detailed memo, or findings
65	only.
66
67	## Evidence Collection
68
69	Never start with opinion. Build the evidence packet first.
70
71	1. Locate the Codex session.
72	- Search `~/.codex/session_index.jsonl`, `~/.codex/sessions/*/.jsonl`,
73	and `~/.codex/archived_sessions/*.jsonl` for the session id or prefix.
74	- Confirm the session title, timestamp, cwd, branch, and final assistant
75	message.
76	- If the session cannot be found, say that and review only the artifacts the
77	user provided.
78
79	2. Extract the real user request and corrections.
80	- Ignore injected `AGENTS.md`, environment context, skill bodies, and system
81	text.
82	- Capture each meaningful user prompt, especially mid-task corrections such
83	as scope changes, product constraints, or "also consider..." feedback.
84
85	3. Extract what the agent actually did.
86	- Summarize proposals, plans, implementation steps, changed files, commands,
87	validation results, commits, and pushes.
88	- Use `git show`, `git diff`, plan docs, tests, and relevant source files
89	when a commit or file path is mentioned.
90	- Distinguish committed changes from unrelated dirty worktree changes.
91	- Compare the changed-file set with the user's actual request. Flag
92	unrelated files or commits mixed into the task, especially skill renames,
93	dependency/version churn, generated artifacts, release files, or broad
94	runtime changes inside a narrow product/UI fix.
95
96	4. Read the relevant product context.
97	- Start with `doc/product/GOAL.md`, `doc/product/PRODUCT.md`, `doc/product/README.md` plus relevant `doc/product/domains/**`,
98	and `doc/engineering/DESIGN.md` when the task affects product behavior or UI.
99	- Read the task's plan doc if one exists.
100	- For release, desktop, plugin, database, or CLI work, follow the relevant
101	AGENTS.md doc route.
102
103	5. Check validation evidence.
104	- Record which focused tests, full checks, E2E tests, builds, screenshots,
105	or browser checks actually passed.
106	- Treat "attempted but timed out" as unverified, not as passed.
107	- For visible UI changes, look for real visual verification of the non-empty
108	and edge-case states, not only empty states.
109
110	## First-Principles Review Frame
111
112	Use this frame before writing the verdict:
113
114	1. User job
115	- What real user or operator problem was this task supposed to solve?
116	- Was the original request a symptom of a deeper workflow or information
117	architecture issue?
118
119	2. Object model
120	- What is the product object really? View, navigation shortcut, workflow
121	state, preference, project artifact, run, issue, or setting?
122	- Did the implementation model it as the correct kind of object?
123
124	3.

People who liked this also viewed

6 picks

Type

codex-session-product-reviewer-maintainer

247stars30forks

View on GitHub

How to install codex-session-product-reviewer-maintainer?

undertone0809/rudder/codex-session-product-reviewer-maintainer

$npx -y skills add Undertone0809/rudder --skill codex-session-product-reviewer-maintainer

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Codex Session Product Reviewer Maintainer
2
3	This skill reviews a completed or in-progress Codex task from a product
4	manager's point of view. It is a reviewer workflow, not an implementation
5	workflow.
6
7	The core question is:
8
9	> Did this session solve the right product problem, with the right scope,
10	> behavior, and validation?
11
12	Use it to turn a vague request like "review this Codex session as a PM" into a
13	grounded product review based on the session transcript, actual code changes,
14	tests, plan docs, and repository product standards.
15
16	## Use When
17
18	Use this skill when the user asks to:
19
20	- review a Codex session id, task, thread, or run as a product manager
21	- evaluate whether another agent's implementation was product-correct
22	- apply first-principles thinking to a shipped task
23	- judge whether a proposal or implementation solved the right user problem
24	- produce a reviewer-style accept / conditional accept / reject
25	- translate fuzzy dissatisfaction into explicit product critique
26
27	Common trigger phrases:
28
29	- "review 一下 codex session id ..."
30	- "as a 专业的产品经理 review"
31	- "第一性原理思考一下"
32	- "作为 reviewer"
33	- "PM review this task"
34	- "这个 session 做得怎么样"
35	- "这个实现是不是产品上对"
36
37	## Do Not Use When
38
39	Do not use this skill for:
40
41	- generic code review where the user mainly wants bugs and line comments
42	- debugging a failed Rudder agent run transcript
43	- creating a new product idea or brainstorming from scratch
44	- implementing the fixes found during review, unless the user explicitly asks
45	- summarizing a session without judgment
46	- judging only from the final assistant message when local evidence is
47	available
48
49	If the user asks for code correctness review, use a code-review workflow.
50	If the user asks why a Rudder agent run failed, use the run transcript debugging
51	workflow first.
52
53	## Inputs
54
55	Required:
56
57	- A Codex session id, commit hash, PR, branch, or clearly identified task to
58	review.
59
60	Optional:
61
62	- The review lens, such as PM, first principles, design, workflow, release, or
63	founder mode.
64	- A desired output style, such as short verdict, detailed memo, or findings
65	only.
66
67	## Evidence Collection
68
69	Never start with opinion. Build the evidence packet first.
70
71	1. Locate the Codex session.
72	- Search `~/.codex/session_index.jsonl`, `~/.codex/sessions/*/.jsonl`,
73	and `~/.codex/archived_sessions/*.jsonl` for the session id or prefix.
74	- Confirm the session title, timestamp, cwd, branch, and final assistant
75	message.
76	- If the session cannot be found, say that and review only the artifacts the
77	user provided.
78
79	2. Extract the real user request and corrections.
80	- Ignore injected `AGENTS.md`, environment context, skill bodies, and system
81	text.
82	- Capture each meaningful user prompt, especially mid-task corrections such
83	as scope changes, product constraints, or "also consider..." feedback.
84
85	3. Extract what the agent actually did.
86	- Summarize proposals, plans, implementation steps, changed files, commands,
87	validation results, commits, and pushes.
88	- Use `git show`, `git diff`, plan docs, tests, and relevant source files
89	when a commit or file path is mentioned.
90	- Distinguish committed changes from unrelated dirty worktree changes.
91	- Compare the changed-file set with the user's actual request. Flag
92	unrelated files or commits mixed into the task, especially skill renames,
93	dependency/version churn, generated artifacts, release files, or broad
94	runtime changes inside a narrow product/UI fix.
95
96	4. Read the relevant product context.
97	- Start with `doc/product/GOAL.md`, `doc/product/PRODUCT.md`, `doc/product/README.md` plus relevant `doc/product/domains/**`,
98	and `doc/engineering/DESIGN.md` when the task affects product behavior or UI.
99	- Read the task's plan doc if one exists.
100	- For release, desktop, plugin, database, or CLI work, follow the relevant
101	AGENTS.md doc route.
102
103	5. Check validation evidence.
104	- Record which focused tests, full checks, E2E tests, builds, screenshots,
105	or browser checks actually passed.
106	- Treat "attempted but timed out" as unverified, not as passed.
107	- For visible UI changes, look for real visual verification of the non-empty
108	and edge-case states, not only empty states.
109
110	## First-Principles Review Frame
111
112	Use this frame before writing the verdict:
113
114	1. User job
115	- What real user or operator problem was this task supposed to solve?
116	- Was the original request a symptom of a deeper workflow or information
117	architecture issue?
118
119	2. Object model
120	- What is the product object really? View, navigation shortcut, workflow
121	state, preference, project artifact, run, issue, or setting?
122	- Did the implementation model it as the correct kind of object?
123
124	3.

People who liked this also viewed

6 picks

Type