| 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:
- Explicit user request in the current conversation.
- Approved active non-release spec for implementation scope.
AGENTS.md for always-on authority, branch/spec gates, and router pointers.- Task-relevant
.codex/skills/*/SKILL.md for detailed workflow rules.
- GitHub Issues for backlog items, lightweight ideas, and pre-spec intake.
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:
- Fetch the Issue body, labels, state, and current discussion.
- Treat the live prompt as highest authority, then the approved active spec,
then the Issue as backlog or pre-spec context.
- Identify the task shape from the prompt plus Issue context and load the
smallest matching skill set from the decision order.
- If the work is non-trivial implementation, create or select an approved
non-release spec before editing code.
- 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.
