advisor-review-loop-maintainer

Name: advisor-review-loop-maintainer
Author: Undertone0809

247stars30forks

How to install advisor-review-loop-maintainer?

undertone0809/rudder/advisor-review-loop-maintainer

$npx -y skills add Undertone0809/rudder --skill advisor-review-loop-maintainer

Installs into the current project.

Summary

Use when Rudder development work needs first-principles advisor analysis plus independent reviewer rounds: proposals, UI/product decisions, architecture, release readiness, workflow changes, agent outcomes, explicit acceptance gates, repeated review, or “没有通过 review 返工”.

Files · 1

View on GitHub

SKILL.md

1	# Advisor Review Loop Maintainer
2
3	This skill chains existing Rudder maintainer practices:
4
5	- `build-advisor`: turn fuzzy dissatisfaction or a high-stakes request into a
6	grounded scenario analysis, requirement map, options, and recommended plan.
7	- `agent-work-reviewer-maintainer`: independently judge whether the result
8	solved the right product problem with sufficient behavior, evidence, and
9	validation.
10	- `product-acceptance-verifier-maintainer`: when the loop evaluates delivered
11	product behavior rather than a proposal artifact, prove black-box acceptance
12	before final review.
13
14	Use this skill when the work should not be accepted after one author pass. The
15	goal is to create a reviewable proposal or implementation, expose it to
16	independent pressure, revise it, and only hand off once the remaining risk is
17	explicit.
18
19	## When to Use
20
21	Use this skill for Rudder development tasks where the user asks for any of:
22
23	- Build Advisor followed by reviewer agents
24	- first-principles product, scenario, or requirement analysis that must pass
25	independent reviewers, repeated review rounds, or an explicit acceptance gate
26	- deep corner-case coverage before implementation or handoff
27	- two review iterations before the final answer
28	- "no pass, keep reworking" behavior
29	- review of a plan, skill, workflow, feature, UI, architecture, release
30	verification, or completed agent task where correctness depends on product
31	judgment and an acceptance gate
32
33	Do not use this skill for a narrow bug fix, simple command, ordinary code
34	review, direct release execution, or a generic first-principles advisory task
35	where the correct specialized skill can execute directly.
36
37	If the user explicitly names this skill for a narrow screenshot-driven UI fix
38	but does not ask for reviewer agents, repeated rounds, "no pass then rework",
39	or an acceptance gate, use the lightweight route:
40
41	1. Do a short advisor check to confirm the UI problem and non-goals.
42	2. Hand the implementation to `rudder-ui-polish-maintainer` discipline.
43	3. Report that this was a lightweight advisor route, not a full reviewer loop.
44
45	Do not spend a full two-reviewer loop on small color, spacing, label, icon,
46	badge, menu-position, or redundant-wrapper fixes unless the user explicitly
47	asks for that review bar.
48
49	## Inputs
50
51	Resolve these before starting:
52
53	- Target artifact: proposal, plan doc, skill, code diff, PR, commit, release,
54	UI state, transcript, or workflow.
55	- Requested mode: proposal-only, implementation, review-only, or
56	proposal-then-implementation. Treat "给你 new worktree", "自己做实验",
57	"把这个问题解决", "try harder", or equivalent escalation after prior advice as
58	experiment/implementation mode unless the user explicitly says proposal-only.
59	- Evidence source: repo files, docs, screenshots, logs, traces, commits,
60	branches, PRs, eval outputs, or user-provided artifacts.
61	- Review bar: what must be true before the result can be accepted.
62
63	If the user is explicit, infer reasonable defaults and proceed. Ask only when
64	the target artifact or requested mode cannot be determined safely.
65
66	Respect `review-only` strictly. In review-only mode, produce the advisor frame,
67	review findings, verdicts, and smallest changes needed, but do not edit files,
68	rewrite the artifact, or continue into implementation unless the user
69	explicitly asks for rework after seeing the findings.
70
71	When the user escalates from architecture discussion to a new worktree or asks
72	the agent to experiment and solve the issue, stop repeating the advisory answer.
73	Reclassify the loop as `proposal-then-implementation` or direct
74	`implementation`:
75
76	- rebuild branch and dirty state in the provided worktree
77	- identify the falsifiable hypothesis from the advisor pass
78	- run the smallest experiment that can prove or disprove it
79	- implement the fix only after the experiment points to a concrete change
80	- review the actual diff and validation evidence, not the earlier proposal
81	- commit and push only scoped files for the solved task
82
83	When the conversation resumes after a `turn_aborted`, `/goal`, or a long-running
84	implementation checkpoint, rebuild the current state before continuing:
85
86	- inspect branch and dirty state
87	- identify partial commits, merge/conflict state, and running verification
88	- restate the remaining task list and proof still missing
89
90	Do not assume the previous turn finished cleanly just because the next user
91	message says to continue.
92
93	## Default Workflow
94
95	### 1. Build the evidence packet
96
97	Collect the smallest set of evidence that can support real judgment:
98
99	- repo instructions and relevant docs
100	- current branch, dirty state, commits, PRs, or target files
101	- existing plans, specs, screenshots, traces,

People who liked this also viewed

6 picks

Type

advisor-review-loop-maintainer

247stars30forks

View on GitHub

How to install advisor-review-loop-maintainer?

undertone0809/rudder/advisor-review-loop-maintainer

$npx -y skills add Undertone0809/rudder --skill advisor-review-loop-maintainer

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Advisor Review Loop Maintainer
2
3	This skill chains existing Rudder maintainer practices:
4
5	- `build-advisor`: turn fuzzy dissatisfaction or a high-stakes request into a
6	grounded scenario analysis, requirement map, options, and recommended plan.
7	- `agent-work-reviewer-maintainer`: independently judge whether the result
8	solved the right product problem with sufficient behavior, evidence, and
9	validation.
10	- `product-acceptance-verifier-maintainer`: when the loop evaluates delivered
11	product behavior rather than a proposal artifact, prove black-box acceptance
12	before final review.
13
14	Use this skill when the work should not be accepted after one author pass. The
15	goal is to create a reviewable proposal or implementation, expose it to
16	independent pressure, revise it, and only hand off once the remaining risk is
17	explicit.
18
19	## When to Use
20
21	Use this skill for Rudder development tasks where the user asks for any of:
22
23	- Build Advisor followed by reviewer agents
24	- first-principles product, scenario, or requirement analysis that must pass
25	independent reviewers, repeated review rounds, or an explicit acceptance gate
26	- deep corner-case coverage before implementation or handoff
27	- two review iterations before the final answer
28	- "no pass, keep reworking" behavior
29	- review of a plan, skill, workflow, feature, UI, architecture, release
30	verification, or completed agent task where correctness depends on product
31	judgment and an acceptance gate
32
33	Do not use this skill for a narrow bug fix, simple command, ordinary code
34	review, direct release execution, or a generic first-principles advisory task
35	where the correct specialized skill can execute directly.
36
37	If the user explicitly names this skill for a narrow screenshot-driven UI fix
38	but does not ask for reviewer agents, repeated rounds, "no pass then rework",
39	or an acceptance gate, use the lightweight route:
40
41	1. Do a short advisor check to confirm the UI problem and non-goals.
42	2. Hand the implementation to `rudder-ui-polish-maintainer` discipline.
43	3. Report that this was a lightweight advisor route, not a full reviewer loop.
44
45	Do not spend a full two-reviewer loop on small color, spacing, label, icon,
46	badge, menu-position, or redundant-wrapper fixes unless the user explicitly
47	asks for that review bar.
48
49	## Inputs
50
51	Resolve these before starting:
52
53	- Target artifact: proposal, plan doc, skill, code diff, PR, commit, release,
54	UI state, transcript, or workflow.
55	- Requested mode: proposal-only, implementation, review-only, or
56	proposal-then-implementation. Treat "给你 new worktree", "自己做实验",
57	"把这个问题解决", "try harder", or equivalent escalation after prior advice as
58	experiment/implementation mode unless the user explicitly says proposal-only.
59	- Evidence source: repo files, docs, screenshots, logs, traces, commits,
60	branches, PRs, eval outputs, or user-provided artifacts.
61	- Review bar: what must be true before the result can be accepted.
62
63	If the user is explicit, infer reasonable defaults and proceed. Ask only when
64	the target artifact or requested mode cannot be determined safely.
65
66	Respect `review-only` strictly. In review-only mode, produce the advisor frame,
67	review findings, verdicts, and smallest changes needed, but do not edit files,
68	rewrite the artifact, or continue into implementation unless the user
69	explicitly asks for rework after seeing the findings.
70
71	When the user escalates from architecture discussion to a new worktree or asks
72	the agent to experiment and solve the issue, stop repeating the advisory answer.
73	Reclassify the loop as `proposal-then-implementation` or direct
74	`implementation`:
75
76	- rebuild branch and dirty state in the provided worktree
77	- identify the falsifiable hypothesis from the advisor pass
78	- run the smallest experiment that can prove or disprove it
79	- implement the fix only after the experiment points to a concrete change
80	- review the actual diff and validation evidence, not the earlier proposal
81	- commit and push only scoped files for the solved task
82
83	When the conversation resumes after a `turn_aborted`, `/goal`, or a long-running
84	implementation checkpoint, rebuild the current state before continuing:
85
86	- inspect branch and dirty state
87	- identify partial commits, merge/conflict state, and running verification
88	- restate the remaining task list and proof still missing
89
90	Do not assume the previous turn finished cleanly just because the next user
91	message says to continue.
92
93	## Default Workflow
94
95	### 1. Build the evidence packet
96
97	Collect the smallest set of evidence that can support real judgment:
98
99	- repo instructions and relevant docs
100	- current branch, dirty state, commits, PRs, or target files
101	- existing plans, specs, screenshots, traces,

People who liked this also viewed

6 picks

Type