development-lifecycle-router-maintainer

Development Lifecycle Router Maintainer

Use this skill as a routing layer: choose the current lifecycle stage, name the exit bar, and hand off to the smallest capable maintainer skill or normal coding workflow.

The reason this skill exists is to prevent two expensive mistakes:

• jumping from a complaint into implementation before the correct stage is known
• calling a stage complete without the product proof or reviewer evidence that the user's request actually requires

Keep this file thin. Load the reference files below only when the current route needs them.

Reference Map

• references/route-selection.md: stage classifier, narrow-skill routing, meta-request precedence, and skill-optimization boundaries.
• references/verification-review.md: verifier gates, terminal product proof, spawned reviewer policy, reviewer lenses, agent prompt templates, and evidence ledger.
• references/special-routes.md: recovery, component lab, performance benchmark, runtime/provider contracts, and hard real-local validation.
• references/handoff-git.md: git safety, final handoff shape, acceptance blockers, and common route templates.

Fast Start

Before editing files, running long checks, spawning reviewers, or committing:

1. Inspect git status --short --branch.
2. Classify the current stage.
3. State the selected route and downstream owner in one concise update.
4. Name the artifact or proof required to leave the current stage.
5. For development work, state the full loop before editing: implementation, writer checks, verifier, final reviewers, reconciliation, and handoff. Development work enters spawn-required mode by default; the user does not need to separately ask for subagents, review, or verification.
6. Decide which references are needed for this route and read only those.

For obvious narrow requests, do not expand a lifecycle plan. Say the route, load the narrow skill, and execute it.

Non-Use Gate

Use the narrow maintainer directly when all of these are true:

• the prompt names a concrete surface, run, PR, release, screenshot, data path, or local runtime problem
• the next useful artifact is obvious for that surface
• the task does not need cross-stage sequencing, reviewer orchestration, or destructive recovery judgment before the narrow work can begin

Keep ownership in this router only when it adds value by choosing a stage, resolving ambiguity, sequencing multiple stages, or protecting a high-risk handoff.

Core Rule

Route first, then execute.

State the lifecycle stage and acceptance bar before implementation. Any routed development task enters spawn-required mode by default. This applies when the task changes user-visible, agent-visible, Desktop, release, runtime, CLI, workflow, or control-plane behavior, even if the user only says "fix", "optimize", or "推进". The normal implementation sandwich is:

writer implementation
-> writer basic checks
-> optional lightweight pre-review
-> spawn availability probe if needed
-> spawned verifier black-box acceptance
-> spawned final reviewer gate
-> handoff / commit / push

Pre-review is only for catching obvious diff, startup, safety, scope, or test readiness problems before verifier time is spent. It is not the final reviewer gate. Final review follows verifier PASS so reviewers can inspect the diff, tests, handoff, and verifier evidence together.

Separate verification from review:

• verification asks whether the product path meets the requirement from the user's side
• review asks whether the diff, architecture, scope, tests, proof, and handoff are trustworthy

For development routes, do not treat the loop as optional just because the user said "fix", "优化", "推进", or omitted the word review. User-visible, agent-visible, Desktop, release, runtime, CLI, workflow, and control-plane changes need the verifier plus final reviewer loop before complete handoff. If a route truly does not need that loop, say why it is not applicable rather than silently skipping it.

spawn-required means:

• after writer checks, probe the available spawn/subagent mechanism before declaring verifier or reviewers unavailable
• if spawning works, create the verifier and final reviewer agents and wait for their verdicts before complete handoff
• if spawning is unavailable, record the failed probe as blocked: spawned verifier/reviewer unavailable
• do not claim complete handoff, commit/push readiness, or review pass from author-run tests, CI, screenshots, self-review, or serial personas alone

Stage Classifier

Choose one primary stage. If multiple stages are present, choose the earliest blocking stage.

• intake: user intent, target artifact, or mode is unclear
• requirements: problem framing, scenarios, acceptance criteria, or "do you understand?"
• advisor: first-principles diagnosis of a build, UI, workflow, trace, or proposal that feels wrong
• ui_design: interface direction, wireframe, visual hierarchy, or screenshot-based design judgment before code
• implementation: approved direction or direct fix/build request
• verification: tests, CI, E2E, screenshots, Desktop smoke, actor-run-chain, release checks, or black-box acceptance proof
• review: review, PM judgment, first-principles critique, or Codex/session/PR/commit verdict
• debug: failed run, UI path, data path, CI job, Desktop app, or local process
• release: canary/stable release, npm, Desktop assets, tags, or GitHub Release state
• handoff: final summary, validation, commit, push, residual risk, or PR
• recovery: dirty worktree, stash, interrupted run, rollback, delete/restore, or suspected old Codex work
• component_lab: UI Lab, component inventory, fixtures, or design-system coverage
• performance_benchmark: benchmark or optimize before the exact bottleneck is known
• runtime_contract: provider/runtime/tool-call/transcript/parser/CLI or agent-visible contract parity
• skill_optimization: optimize, harden, refactor, validate, benchmark, package, or improve a named skill or workflow skill

For full routing detail, read references/route-selection.md.

Narrow Routes

Prefer the smallest matching owner:

• screenshot-driven UI polish: rudder-ui-polish-maintainer
• missing, stale, suspicious, or slow page data: rudder-data-path-diagnostician-maintainer
• run transcript, stdout/stderr, recent run batch, or run-quality issue: debug-run-transcript-maintainer
• Desktop startup, packaged app, Electron shell, update, profile, local instance recovery: rudder-desktop-dev-recovery-maintainer
• release, npm, GitHub Release, Desktop assets, tags, dist-tags, install smoke: release-maintainer
• review-only session/PR/commit/proposal/UI/release outcome: agent-work-reviewer-maintainer or codex-session-product-reviewer-maintainer
• local branch preview: rudder-worktree-preview-maintainer
• GitHub PR checkout/preview/review: pr-local-preview-maintainer
• mock/demo/seed data: mock-data-maintainer
• landing screenshots: landing-proof-shots-maintainer
• stop/restart/clean local dev runtime: stop-rudder-dev-maintainer
• new or existing reusable workflow skill creation, optimization, eval, benchmark, packaging, or description tuning: skill-creator

If this router itself is the target artifact for optimization, route to skill-creator or the user-requested skill-engineering workflow. Do not run this router's normal product lifecycle except for git safety around the patch.

Skill Optimization Boundary

The newest user instruction is the routing source of truth.

If the user says a skill "needs optimization", "should be hardened", "always does the wrong thing", "I have to ask this every time", or asks to use skill-creator on a named skill, classify the turn as skill_optimization.

Treat screenshots, prior requirements, session ids, quoted logs, and prior assistant recommendations as evidence for the skill failure. They are not the active product task unless the newest user instruction says to continue that product task.

For this route:

• name the target skill and path
• extract the failed decision point
• choose the smallest durable owner: target skill body, frontmatter description, eval case, memory update, or no-op
• add or update a validation case when the behavior should change next time

Verification And Review Defaults

For user-visible, agent-visible, Desktop, release, runtime, CLI, workflow, or control-plane changes, identify the terminal product surface before calling verification complete. Use product-acceptance-verifier-maintainer for a distinct black-box acceptance pass. If the product path is too expensive or unsafe to exercise, record verifier blocked or substituted with the exact reason; do not silently skip acceptance.

Spawned verifier and reviewer gates are the default for routed development artifacts when this router owns the lifecycle. If spawning is available, the verifier should be a distinct child agent using agents/product-verifier.md or equivalent product-acceptance-verifier-maintainer instructions. Final reviewers should be child agents using the templates under agents/ or equivalent reviewer prompts, with these lenses:

• functional trust
• adversarial
• heuristic/product-systems

Do not replace spawned verifier or reviewer verdicts with self-review, serial personas, or author-claimed screenshots. If the active runtime cannot spawn agents after a real availability probe, record blocked: spawned verifier/reviewer unavailable with the probe evidence instead of claiming the loop passed.

For the full verifier/reviewer contract, read references/verification-review.md.

Execution Outline

1. Build a compact routing packet:
   • latest user request and corrections
   • git status --short --branch
   • named files, screenshots, sessions, runs, PRs, commits, or plans
   • relevant AGENTS.md route docs and nearby skill contracts
   • changed-file ownership if cleanup or recovery is involved
2. Declare route and stage exits.
3. Execute the current stage using the narrow owner or normal repo workflow.
4. Run the required verification and review gates for that route.
5. Hand off with evidence, blockers, git state, and commit/push status.

Minimal Handoff Shape

Route: ...
Stage exits: ...
Used: ...
Review: spawned reviewers / blocked / not applicable
Validation: passed / not run / not proven
Evidence: required / scenario / proven / missing or substituted
Git: commit / push
Residual risk: ...