# Delivery Router

> 面向交付与产品工作的总入口路由器。用于在端到端交付、产品发现、方案生成、需求定义、PRD/tech spec、方案批判、测试用例与最终验证之间选择最合适的技能；当用户要“把事情做成”但尚未明确是 discovery、proposal、planning、implementation 还是 verification 时优先使用。

- Skill: `ocean326/delivery-router` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add ocean326/delivery-router`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ocean326/delivery-router/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Product & Planning
- Author: ocean326 (https://skillmd.com/u/ocean326)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/ocean326/delivery-router

---


# Delivery Router

Use this as the public front door for delivery and product work.
Treat it as a thin category router, not a second delivery manager.

Its main job is to decide whether the task needs:

- an end-to-end owner
- discovery
- proposal generation
- requirements and prioritization
- critique
- test planning
- a verification gate

## Use This Router For

- vague feature or project requests
- bugfixes or refactors that need product, design, implementation, and verification coordination
- requests that say “take this from idea to delivery”
- cases where the user knows the desired outcome but not the best delivery lane

## Do Not Use This Router For

- pure architecture or system-boundary work
  - use `architect-router`
- AI research workflow decisions
  - use `research-router`
- prompt optimization, docs lookup, or PersonalBrain attachment
  - use `knowledge-router`
- remote execution topology or explicit subagent orchestration
  - use `execution-router`

## Routing Table

1. `delivery-conductor`
   Use when the task needs one owner across discovery, planning, implementation, testing, and verification, or when the thread should be resumed and pushed toward a verified outcome.

2. `brainstorming`
   Use when the request is creative, underdefined, or benefits from ideation before planning or implementation.

3. `proposal-synthesis`
   Use when the user wants several complete candidate proposals, a recommended direction, or a critique-ready proposal packet from a still-open design space.

4. `business-analyst`
   Use for product discovery, stakeholder questions, competitive analysis, user needs, problem framing, and product briefs.

5. `product-manager`
   Use for PRDs, tech specs, acceptance criteria, feature prioritization, epics, and user-story breakdown.

6. `product-requirements`
   Use when the user wants an interactive, question-driven requirements pass that converges toward a high-quality PRD.

7. `proposal-critique-refine`
   Use when a coherent proposal already exists and now needs critique, stress testing, or bounded refinement.

8. `test-cases`
   Use when the main missing artifact is structured test coverage derived from requirements.

9. `verification-before-completion`
   Use when the work is already near done and the highest-value move is an honest verification gate before any completion claim, handoff, commit, or PR.

10. `bmad-orchestrator`
   Use when the request is explicitly about BMAD workflow setup, workflow status, or phase routing inside that system.

## Decision Rules

1. If the task needs one end-to-end owner, route to `delivery-conductor`.
2. If the task is blocked by not knowing what to build or why, route to `brainstorming` or `business-analyst`.
3. If the user needs several complete proposal options before critique, route to `proposal-synthesis`.
4. If the problem is mostly requirements quality, route to `product-manager` or `product-requirements`.
5. If a proposal exists and needs sharper judgment, route to `proposal-critique-refine`.
6. If the artifact gap is test coverage, route to `test-cases`.
7. If the work mostly exists and evidence is the weak point, route to `verification-before-completion`.

When in doubt, prefer `delivery-conductor` over piecing together a fragile chain of narrow skills.

## Direct-Entry Exceptions

Skip this router and use the specialist directly when:

- the user explicitly says `Use $delivery-conductor`
- the task is clearly one-lane, such as “写一个 PRD” or “给我测试用例”
- the user explicitly wants multiple complete proposal options before critique
- the user already has a stable proposal and only wants critique
- the task is already in final verification mode

## Output Contract

Always return:

- task type
- selected lane
- why the lane fits better than the nearby alternatives
- the next concrete action
- whether this should stay one-lane or be handed to `delivery-conductor`

## Guardrails

- do not force every product task through `delivery-conductor`
- do not turn pure implementation work into unnecessary product process
- do not send architecture-heavy work into product planning first
- if the real blocker is outside delivery scope, hand off cleanly instead of pretending this router owns it

## Example Triggers

- `Use $delivery-router to pick the right product or delivery skill for this feature request.`
- `使用 $delivery-router 看看这个需求该先 discovery、先写 PRD，还是直接交给 delivery-conductor。`
- `Use $delivery-router to decide whether this bugfix needs end-to-end ownership or just a focused planning skill.`