Skill Factory Router

Select one downstream workflow for Codex skill-management requests. Return the routing handoff before loading deeper instructions.

When to use

Use when the user asks to create, capture, improve, audit, refactor, install, sync, or route a Codex skill and the correct Skill Factory lane is not already certain.

Required inputs

• User request or named target skill.
• Current authority boundary: read-only routing, approved edit, install/sync, or eval execution.
• Available evidence handle when the request depends on Tessl, Plugin Eval, validation, runtime, or session artifacts.

Deliverables

• One YAML handoff with schema_version, selected_lane, mode, rationale, next_step, first_principles_check, and blocked_by.
• Expected artifacts: no source edits from the router itself; downstream lanes own review reports, eval artifacts, package outputs, and runtime evidence.

Discovery Interview

When target, lane, write authority, or validation requirement is missing, ask one plain-language question. Use discovery interview only when the ambiguity cannot be resolved from the user request.

Decision Table

For .system/skill-creator or .system/skill-installer, attach Skill Factory references or eval contracts; do not fork the system skill body.

Procedure

1. Match the request to the decision table. Explicit lane names win unless the user names multiple lanes or asks for an unsafe action.
2. If target, authority, evidence, or lane selection is ambiguous, ask one blocking discovery question.
3. For major new-skill or broad-rewrite requests, check whether the better answer is a skill, docs, script, hook, validator, rule, or direct answer.
4. Return the handoff template and stop unless the user explicitly asks this router to execute the selected lane.

Handoff Template

Return:

schema_version: 1
selected_lane: .system/skill-creator|skillify|skill-builder|skill-refactor|.system/skill-installer
mode: create|capture|harden|analyze|install
rationale: <one sentence tied to the request shape>
next_step: <specific skill or system lane to load next>
first_principles_check:
  required: true|false
  result: skill|docs|script|hook|validator|rule|answer|not_checked
blocked_by: null

Example

User: "Tessl says this skill has weak content; inspect it and validate the fix."

Return:

schema_version: 1
selected_lane: skill-builder
mode: harden
rationale: The user has an existing skill with Tessl and local audit findings.
next_step: Load skill-builder, patch the canonical target skill, then rerun strict audit and local external review.
first_principles_check:
  required: false
  result: not_checked
blocked_by: null

Constraints

• Keep routing read-only: do not edit, install, sync, publish, mutate trackers, run downstream commands, or load references before lane selection.
• Route plugin package lifecycle work to plugin-factory.
• Route system creator and installer requests to the system lanes, not forks.
• Claim environment/auth/runtime state only from current-turn evidence, and redact secrets, tokens, PII, and sensitive local paths.

Failure Mode

If no single lane fits, set blocked_by to the ambiguity and ask the smallest routing question.

Validation

Run bash Infrastructure/scripts/validation-and-linting/validate_skill_authoring_family.sh and ./bin/ask skills external-review Plugins/skill-factory/skills/skill-factory-router --audit-level compat --json.

Fail fast: stop at the first failed required gate, classify it, and do not sync, commit, publish, or install until it is fixed or explicitly blocked.

References

Load only the reference needed for the selected routing question:

• Package contract and evals: references
• Ambiguous request questions: discovery interview
• Source-repo routing policy handles: routing policy