Workflow Router
Use this as the entry point; downstream skills own their detailed instructions.
Route
Classify the request, choose only the matching sequence below, and state each transition rationale in one line. Do not add steps from another route unless its trigger is present. In an unfamiliar repository, perform repository reconnaissance first (inspect structure, README/CONTRIBUTING, build/test framework, CI, recent git log, and existing patterns per AI_ENGINEERING_WORKFLOW.md).
Idea to staging
Vague but issue-sized request
- Vague or decision-heavy request that clarification resolves into one independently verifiable issue:
clarify-work → define-done.
- Transition rationale: clarify creates a safe boundary; define-done makes success testable; a single bounded issue needs no decomposition or durable spec.
Broad or multi-issue request
- Broad request that will not fit one independently verifiable issue even after clarification (several independent slices, unsettled cross-cutting decisions, a durable spec the team will reference across issues):
clarify-work → to-prd → decompose-to-issues.
- Transition rationale: clarify creates a safe boundary;
to-prd drafts and publishes the durable spec the multi-issue breakdown depends on; decomposition protects independent delivery.
Concrete single behavior change
- Concrete single behavior change: define done →
test-driven-development test-first change → code-simplification on the changed code → review-gate → staging PR.
- Transition rationale: the request is already bounded, so clarification and decomposition add no value; tests prove behavior before review.
Claimed non-trivial GitHub issue
- Sequence:
subagent-pipeline → CI → staging PR.
- Transition rationale: a claimed non-trivial GitHub issue has an issue-sized boundary, so the pipeline supplies independent implementation, review, and CI evidence.
Bug or regression
- Sequence: diagnose → regression test → smallest fix →
review-gate.
- Transition rationale: reproduce and isolate before changing code; retain the failing case as proof; review checks regressions after the fix.
Release
- Sequence:
release-gate.
- Transition rationale: release needs a reviewed artifact, target, health signal, and rollback path rather than a new implementation workflow.
Human-held blocker
- Sequence:
hitl-blocker.
- Transition rationale: missing credentials, DNS, billing, permissions, or approval require a visible owner and verification command, not repeated automation.
Standalone tools
clarify-work for unclear scope; define-done for acceptance criteria on a single bounded issue; to-prd for a durable spec a multi-issue plan will reference; decompose-to-issues for a multi-issue plan; review-gate before merge; handover at a context boundary.- Use
subagent-pipeline only for a claimed non-trivial GitHub issue. Its CI gate ends with the appropriate staging PR.
Run-once setup
When invoked as workflow-router setup, inspect before proposing anything:
- Tracker: GitHub remotes, issue/PR templates, and local tracker files.
- Delivery: target branch from remote/default-branch configuration and existing CI workflows.
- Labels: existing issue labels and any documented label vocabulary.
- Project context:
docs/ layout, ADRs, and existing AGENTS.md, CLAUDE.md, or equivalent instructions.
- Verification: test commands, runtime/container instructions, and test-storage constraints.
Report detected conventions and gaps, then show a file-by-file proposed edit or command. Ask for approval before writing any instruction, config, label, or tracker change. Never overwrite or replace existing instructions; add only an approved, conflict-free change, or report the conflict for a human decision.
Setup output
Return: detected tracker; target branch; labels; docs/instruction files; test/runtime command; proposed changes; and Approval required: yes/no. yes is mandatory whenever a change is proposed.
1---2name: workflow-router3description: Routes a software-work request to the smallest applicable delivery workflow and records repository conventions once. Use when a user asks what engineering workflow to follow, wants help starting a change, needs a release or blocker path, or says setup workflow.4---56# Workflow Router78Use this as the entry point; downstream skills own their detailed instructions.910## Route1112Classify the request, choose only the matching sequence below, and state each transition rationale in one line. Do not add steps from another route unless its trigger is present. In an unfamiliar repository, perform repository reconnaissance first (inspect structure, README/CONTRIBUTING, build/test framework, CI, recent git log, and existing patterns per `AI_ENGINEERING_WORKFLOW.md`).1314### Idea to staging1516#### Vague but issue-sized request1718- Vague or decision-heavy request that clarification resolves into one independently verifiable issue: `clarify-work` → `define-done`.19- Transition rationale: clarify creates a safe boundary; define-done makes success testable; a single bounded issue needs no decomposition or durable spec.2021#### Broad or multi-issue request2223- Broad request that will not fit one independently verifiable issue even after clarification (several independent slices, unsettled cross-cutting decisions, a durable spec the team will reference across issues): `clarify-work` → `to-prd` → `decompose-to-issues`.24- Transition rationale: clarify creates a safe boundary; `to-prd` drafts and publishes the durable spec the multi-issue breakdown depends on; decomposition protects independent delivery.2526#### Concrete single behavior change2728- Concrete single behavior change: define done → `test-driven-development` test-first change → `code-simplification` on the changed code → `review-gate` → staging PR.29- Transition rationale: the request is already bounded, so clarification and decomposition add no value; tests prove behavior before review.3031#### Claimed non-trivial GitHub issue3233- Sequence: `subagent-pipeline` → CI → staging PR.34- Transition rationale: a claimed non-trivial GitHub issue has an issue-sized boundary, so the pipeline supplies independent implementation, review, and CI evidence.3536### Bug or regression3738- Sequence: diagnose → regression test → smallest fix → `review-gate`.39- Transition rationale: reproduce and isolate before changing code; retain the failing case as proof; review checks regressions after the fix.4041### Release4243- Sequence: `release-gate`.44- Transition rationale: release needs a reviewed artifact, target, health signal, and rollback path rather than a new implementation workflow.4546### Human-held blocker4748- Sequence: `hitl-blocker`.49- Transition rationale: missing credentials, DNS, billing, permissions, or approval require a visible owner and verification command, not repeated automation.5051### Standalone tools5253- `clarify-work` for unclear scope; `define-done` for acceptance criteria on a single bounded issue; `to-prd` for a durable spec a multi-issue plan will reference; `decompose-to-issues` for a multi-issue plan; `review-gate` before merge; `handover` at a context boundary.54- Use `subagent-pipeline` only for a claimed non-trivial GitHub issue. Its CI gate ends with the appropriate staging PR.5556## Run-once setup5758When invoked as `workflow-router setup`, inspect before proposing anything:59601. Tracker: GitHub remotes, issue/PR templates, and local tracker files.612. Delivery: target branch from remote/default-branch configuration and existing CI workflows.623. Labels: existing issue labels and any documented label vocabulary.634. Project context: `docs/` layout, ADRs, and existing `AGENTS.md`, `CLAUDE.md`, or equivalent instructions.645. Verification: test commands, runtime/container instructions, and test-storage constraints.6566Report detected conventions and gaps, then show a file-by-file proposed edit or command. Ask for approval before writing any instruction, config, label, or tracker change. Never overwrite or replace existing instructions; add only an approved, conflict-free change, or report the conflict for a human decision.6768## Setup output6970Return: detected tracker; target branch; labels; docs/instruction files; test/runtime command; proposed changes; and `Approval required: yes/no`. `yes` is mandatory whenever a change is proposed.
wakqasahmed