Workflow router
Skill wakqasahmed/ai-engineering-workflow-skills/skills/engineering/workflow-router
Canonical AI engineering workflow skills, aggregated by wakqasahmed/skills
npx -y skills add wakqasahmed/ai-engineering-workflow-skills --skill workflow-routerAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
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.
SKILL.md
3.5 KB, as published. Nobody here has run it
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.
Idea to staging
Vague or multi-issue request
- Vague, broad, or decision-heavy request:
clarify-work→define-done→decompose-to-issuesonly when it cannot fit one independently verifiable issue. - Transition rationale: clarify creates a safe boundary; define-done makes success testable; decomposition protects independent delivery.
Concrete single behavior change
- Concrete single behavior change: define done →
tddtest-first change → simplify 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-workfor unclear scope;define-donefor acceptance criteria;decompose-to-issuesfor a multi-issue plan;review-gatebefore merge;handoverat a context boundary.- Use
subagent-pipelineonly 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 existingAGENTS.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.