workflow-routing

name	workflow-routing
description	Choose the correct rankingdepadel.club Codex workflow, source hierarchy, and next skill without loading every skill. Use when task routing, planning depth, source authority, ChatGPT handoff, pre-spec handling, audit choice, or workflow ownership is unclear.

Workflow Routing

Use this skill as the detailed dispatcher for Codex workflow decisions. It chooses the next workflow; it does not replace the task skill that owns the work.

Source Hierarchy

Apply sources in this order:

1. Explicit user request in the current conversation.
2. Approved active non-release spec for implementation scope.
3. AGENTS.md for always-on authority, branch/spec gates, and router pointers.
4. Task-relevant .codex/skills/*/SKILL.md for detailed workflow rules.
5. GitHub Issues for backlog items, lightweight ideas, and pre-spec intake.
6. docs/HARNESS.md for validation commands, CI expectations, release gates, and harness execution guidance only.

If sources conflict, surface the conflict and follow the higher-authority source. Do not treat Issue text or pre-spec drafts as approved implementation scope, shipped artifacts, or repository truth.

Decision Order

Use the first row that matches the primary task. Then load only the smallest set of owner skills needed for the next action.

Default to loading $context-budget-review before spec, planning, and audit work unless the requested action is small and simple. It sets the context mode; it does not replace the owner skill chosen below.

Priority	Task shape	Skill
1	Close cycle, reconcile changelog/specs, commit, push, or release	$development-cycle-closure
2	Diagnose broken behavior, exceptions, regressions, flaky/no-repro failures, or performance issues	$debug
3	Create, revise, or adapt a repo-local Codex skill	$write-a-skill
4	Maintain router docs, project instructions, Markdown policy, source hierarchy, or governance boundaries	$governance-maintenance
5	Reduce context bloat or review progressive-disclosure risk	$context-budget-review
6	Audit Django views, one template, or governance workflow quality	See Audit Routing
7	Resolve ambiguity, pressure-test decisions, or plan before specs/implementation	See Planning Routing
8	Convert an approved PRD into thin implementation specs	$prd-to-specs
9	Implement product/code work, enforce active specs, or choose audit gates	$sdd-workflow
10	Design tests, TDD loops, or brittle assertion fixes	$test-design

Planning Routing

• For non-small planning, load $context-budget-review first, then the owner planning skill.
• Use $sdd-grill-me for ambiguity reduction, architecture decisions, pressure-testing, or decision-complete pre-implementation planning.
• Use $phased-prd when the work is multi-phase, has multiple viable options, or needs durable product/process intent before specs.
• Use $prd-to-specs only after the user approves a PRD breakdown.
• For small local docs, governance, or repository-guidance edits, use the owner skill directly without creating a new active spec.

Audit Routing

• For non-small audits, load $context-budget-review first, then the owner audit skill.
• Use $audit for Django view behavior, security, ORM, reuse, or maintainability.
• Use $template-presentation-audit for one-template presentation, cascade, responsive, or computed-style risks.
• Use $governance-markdown-auditor for duplicated workflow policy, unclear ownership, or governance-system quality.

Planning Depth

• Small local docs, governance, or repository-guidance edits may proceed without a new active spec.
• Small and simple spec, planning, or audit requests may skip $context-budget-review.
• Non-trivial implementation must use the active approved non-release spec; PRD-backed work follows the owning PRD's approved spec order.
• If the request is too broad for one spec or has unresolved product, architecture, sequencing, or rollout choices, plan first.
• If repo facts can answer a question cheaply, inspect the repo before asking.
• Ask only questions that affect scope, behavior, UX, data flow, validation, or rollout risk.

Issue-Started Work

When the prompt names a GitHub Issue number or URL:

1. Fetch the Issue body, labels, state, and current discussion.
2. Treat the live prompt as highest authority, then the approved active spec, then the Issue as backlog or pre-spec context.
3. Identify the task shape from the prompt plus Issue context and load the smallest matching skill set from the decision order.
4. If the work is non-trivial implementation, create or select an approved non-release spec before editing code.
5. Keep the Issue linked in the spec or implementation summary when it defines the request.

If the Issue is rough, incomplete, or conflicts with current repo facts, use Codex clarification/planning before implementation. Do not treat labels, priority, or free-form Issue text as permission to skip branch, spec, validation, or release gates.

ChatGPT And Pre-Specs

ChatGPT may be used before Codex for pre-spec drafting, architecture discussion, technology alternatives, and ambiguity reduction. Store durable handoff context in GitHub Issues, not repository scratch files.

Issues may be rough ideas, free-form notes, screenshots, or detailed pre-spec Markdown. They do not require a template. Use lightweight labels when helpful: type labels feature, fix, change; priority labels P1-now, P2-next, P3-later; and area labels such as governance, UI/UX, backend, release, tests, or docs.

The implementation flow is:

GitHub Issue -> Codex CLI clarification/planning -> formal SDD spec under /specs -> implementation -> validation -> CHANGELOG.md -> deploy -> close Issue.

Ownership Boundaries

• AGENTS.md: compact router only.
• .codex/skills/workflow-routing/: detailed workflow choice and source hierarchy.
• Other skills: detailed task execution in their owned domains.
• docs/HARNESS.md: validation commands, CI expectations, release gates, and harness execution guidance only.
• docs/PROJECT_INSTRUCTIONS.md: ChatGPT-facing planning brief and pre-spec handoff boundaries only.
• GitHub Issues: backlog and informal pre-spec storage only.

When a workflow rule appears in more than one place, keep the most detailed version in the owning skill and reduce the other file to a pointer.