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 product 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 Rudder 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.