Announce: "Using workflow-creator to design/audit/improve a structured workflow."

Load workflow-creator's own constraints (auto-discovered + applies-to-filtered — surfaces the wc-* behavioral rules at load time, complementing the wc-constraint-check.py post-edit hook):

!uv run python3 ${CLAUDE_SKILL_DIR}/../../scripts/load-constraints.py workflow-creator

Detect mode from user request, then follow the corresponding process below:

Mode 1 (Create) — "create/design a workflow", "break a task into phases"
Mode 2 (Audit) — "audit/score a workflow"
Mode 3 (Improve) — "improve a workflow", audit-fix loop, "migrate a fan-out phase to an ultracode workflow" (a migration is an improvement — see ${CLAUDE_SKILL_DIR}/references/dynamic-workflow-migration.md)

Note on workflow-creator's Structure:

workflow-creator is a meta-tool that CREATES workflows. It is exempt from certain requirements it enforces on workflows it creates:

Two entry points: workflow-creator has one entry with mode detection (not a multi-phase workflow). Workflows it creates MUST have two entry points.
Single responsibility per phase: workflow-creator has 3 modes (toolkit, not workflow). Workflows it creates MUST have single-responsibility phases.
Skill Dependencies (cross-file phase chaining): workflow-creator is a single SKILL.md, so it has no next-phase Read() chain. Its structural equivalent is stronger: the wc-step-gate-guard.py hook + the STATE.md step-chain enforce step ordering at the tool-call layer (a skipped step is blocked, not merely un-chained). Workflows it creates with multiple phase files MUST still wire phase-to-phase Read() transitions.
Iteration topology labels (P09): workflow-creator's own steps are a fixed sequence, not a per-phase topology menu, so they carry no [one-shot|serial|parallel] label. Workflows it creates MUST assign a topology per phase.