development-lifecycle-router-maintainer

Name: development-lifecycle-router-maintainer
Author: Undertone0809

247stars30forks

How to install development-lifecycle-router-maintainer?

undertone0809/rudder/development-lifecycle-router-maintainer

$npx -y skills add Undertone0809/rudder --skill development-lifecycle-router-maintainer

Installs into the current project.

Summary

Use when a Rudder development request has an unclear lifecycle stage or owner: requirements, advisor analysis, UI design, implementation, verification, review, release, recovery, runtime contracts, performance, component lab, handoff, or named-skill optimization.

Files · 1

View on GitHub

SKILL.md

1	# Development Lifecycle Router Maintainer
2
3	Use this skill as a routing layer: choose the current lifecycle stage, name the
4	exit bar, and hand off to the smallest capable maintainer skill or normal coding
5	workflow.
6
7	The reason this skill exists is to prevent two expensive mistakes:
8
9	- jumping from a complaint into implementation before the correct stage is known
10	- calling a stage complete without the product proof or reviewer evidence that
11	the user's request actually requires
12
13	Keep this file thin. Load the reference files below only when the current route
14	needs them.
15
16	## Reference Map
17
18	- `references/route-selection.md`: stage classifier, narrow-skill routing,
19	meta-request precedence, and skill-optimization boundaries.
20	- `references/verification-review.md`: verifier gates, terminal product proof,
21	spawned reviewer policy, reviewer lenses, agent prompt templates, and evidence
22	ledger.
23	- `references/special-routes.md`: recovery, component lab, performance
24	benchmark, runtime/provider contracts, and hard real-local validation.
25	- `references/handoff-git.md`: git safety, final handoff shape, acceptance
26	blockers, and common route templates.
27
28	## Fast Start
29
30	Before editing files, running long checks, spawning reviewers, or committing:
31
32	1. Inspect `git status --short --branch`.
33	2. Classify the current stage.
34	3. State the selected route and downstream owner in one concise update.
35	4. Name the artifact or proof required to leave the current stage.
36	5. For development work, state the full loop before editing:
37	implementation, writer checks, verifier, final reviewers, reconciliation, and
38	handoff. Development work enters `spawn-required` mode by default; the user
39	does not need to separately ask for subagents, review, or verification.
40	6. Decide which references are needed for this route and read only those.
41
42	For obvious narrow requests, do not expand a lifecycle plan. Say the route,
43	load the narrow skill, and execute it.
44
45	## Non-Use Gate
46
47	Use the narrow maintainer directly when all of these are true:
48
49	- the prompt names a concrete surface, run, PR, release, screenshot, data path,
50	or local runtime problem
51	- the next useful artifact is obvious for that surface
52	- the task does not need cross-stage sequencing, reviewer orchestration, or
53	destructive recovery judgment before the narrow work can begin
54
55	Keep ownership in this router only when it adds value by choosing a stage,
56	resolving ambiguity, sequencing multiple stages, or protecting a high-risk
57	handoff.
58
59	## Core Rule
60
61	Route first, then execute.
62
63	State the lifecycle stage and acceptance bar before implementation. Any routed
64	development task enters `spawn-required` mode by default. This applies when the
65	task changes user-visible, agent-visible, Desktop, release, runtime, CLI,
66	workflow, or product behavior, even if the user only says "fix",
67	"optimize", or "推进". The normal implementation sandwich is:
68
69	```text
70	writer implementation
71	-> writer basic checks
72	-> optional lightweight pre-review
73	-> spawn availability probe if needed
74	-> spawned verifier black-box acceptance
75	-> spawned final reviewer gate
76	-> handoff / commit / push
77	```
78
79	Pre-review is only for catching obvious diff, startup, safety, scope, or test
80	readiness problems before verifier time is spent. It is not the final reviewer
81	gate. Final review follows verifier `PASS` so reviewers can inspect the diff,
82	tests, handoff, and verifier evidence together.
83
84	Separate verification from review:
85
86	- verification asks whether the product path meets the requirement from the
87	user's side
88	- review asks whether the diff, architecture, scope, tests, proof, and handoff
89	are trustworthy
90
91	For development routes, do not treat the loop as optional just because the user
92	said "fix", "优化", "推进", or omitted the word review. User-visible,
93	agent-visible, Desktop, release, runtime, CLI, workflow, and Rudder
94	changes need the verifier plus final reviewer loop before complete handoff. If a
95	route truly does not need that loop, say why it is `not applicable` rather than
96	silently skipping it.
97
98	`spawn-required` means:
99
100	- after writer checks, probe the available spawn/subagent mechanism before
101	declaring verifier or reviewers unavailable
102	- if spawning works, create the verifier and final reviewer agents and wait for
103	their verdicts before complete handoff
104	- if spawning is unavailable, record the failed probe as
105	`blocked: spawned verifier/reviewer unavailable`
106	- do not claim complete handoff, commit/push readiness, or review pass from
107	author-run tests, CI, screenshots, self-review, or serial personas alone
108
109	## Stage Classifier
110
111	Choose one primary stage. If multiple stages are present, choose the earliest
112	bloc

People who liked this also viewed

6 picks

Type

development-lifecycle-router-maintainer

247stars30forks

View on GitHub

How to install development-lifecycle-router-maintainer?

undertone0809/rudder/development-lifecycle-router-maintainer

$npx -y skills add Undertone0809/rudder --skill development-lifecycle-router-maintainer

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Development Lifecycle Router Maintainer
2
3	Use this skill as a routing layer: choose the current lifecycle stage, name the
4	exit bar, and hand off to the smallest capable maintainer skill or normal coding
5	workflow.
6
7	The reason this skill exists is to prevent two expensive mistakes:
8
9	- jumping from a complaint into implementation before the correct stage is known
10	- calling a stage complete without the product proof or reviewer evidence that
11	the user's request actually requires
12
13	Keep this file thin. Load the reference files below only when the current route
14	needs them.
15
16	## Reference Map
17
18	- `references/route-selection.md`: stage classifier, narrow-skill routing,
19	meta-request precedence, and skill-optimization boundaries.
20	- `references/verification-review.md`: verifier gates, terminal product proof,
21	spawned reviewer policy, reviewer lenses, agent prompt templates, and evidence
22	ledger.
23	- `references/special-routes.md`: recovery, component lab, performance
24	benchmark, runtime/provider contracts, and hard real-local validation.
25	- `references/handoff-git.md`: git safety, final handoff shape, acceptance
26	blockers, and common route templates.
27
28	## Fast Start
29
30	Before editing files, running long checks, spawning reviewers, or committing:
31
32	1. Inspect `git status --short --branch`.
33	2. Classify the current stage.
34	3. State the selected route and downstream owner in one concise update.
35	4. Name the artifact or proof required to leave the current stage.
36	5. For development work, state the full loop before editing:
37	implementation, writer checks, verifier, final reviewers, reconciliation, and
38	handoff. Development work enters `spawn-required` mode by default; the user
39	does not need to separately ask for subagents, review, or verification.
40	6. Decide which references are needed for this route and read only those.
41
42	For obvious narrow requests, do not expand a lifecycle plan. Say the route,
43	load the narrow skill, and execute it.
44
45	## Non-Use Gate
46
47	Use the narrow maintainer directly when all of these are true:
48
49	- the prompt names a concrete surface, run, PR, release, screenshot, data path,
50	or local runtime problem
51	- the next useful artifact is obvious for that surface
52	- the task does not need cross-stage sequencing, reviewer orchestration, or
53	destructive recovery judgment before the narrow work can begin
54
55	Keep ownership in this router only when it adds value by choosing a stage,
56	resolving ambiguity, sequencing multiple stages, or protecting a high-risk
57	handoff.
58
59	## Core Rule
60
61	Route first, then execute.
62
63	State the lifecycle stage and acceptance bar before implementation. Any routed
64	development task enters `spawn-required` mode by default. This applies when the
65	task changes user-visible, agent-visible, Desktop, release, runtime, CLI,
66	workflow, or product behavior, even if the user only says "fix",
67	"optimize", or "推进". The normal implementation sandwich is:
68
69	```text
70	writer implementation
71	-> writer basic checks
72	-> optional lightweight pre-review
73	-> spawn availability probe if needed
74	-> spawned verifier black-box acceptance
75	-> spawned final reviewer gate
76	-> handoff / commit / push
77	```
78
79	Pre-review is only for catching obvious diff, startup, safety, scope, or test
80	readiness problems before verifier time is spent. It is not the final reviewer
81	gate. Final review follows verifier `PASS` so reviewers can inspect the diff,
82	tests, handoff, and verifier evidence together.
83
84	Separate verification from review:
85
86	- verification asks whether the product path meets the requirement from the
87	user's side
88	- review asks whether the diff, architecture, scope, tests, proof, and handoff
89	are trustworthy
90
91	For development routes, do not treat the loop as optional just because the user
92	said "fix", "优化", "推进", or omitted the word review. User-visible,
93	agent-visible, Desktop, release, runtime, CLI, workflow, and Rudder
94	changes need the verifier plus final reviewer loop before complete handoff. If a
95	route truly does not need that loop, say why it is `not applicable` rather than
96	silently skipping it.
97
98	`spawn-required` means:
99
100	- after writer checks, probe the available spawn/subagent mechanism before
101	declaring verifier or reviewers unavailable
102	- if spawning works, create the verifier and final reviewer agents and wait for
103	their verdicts before complete handoff
104	- if spawning is unavailable, record the failed probe as
105	`blocked: spawned verifier/reviewer unavailable`
106	- do not claim complete handoff, commit/push readiness, or review pass from
107	author-run tests, CI, screenshots, self-review, or serial personas alone
108
109	## Stage Classifier
110
111	Choose one primary stage. If multiple stages are present, choose the earliest
112	bloc

People who liked this also viewed

6 picks

Type