Role

This skill owns task intake, scope clarification, work decomposition, sequencing, and specialist routing for WelineFramework delivery. It converts a broad request into executable work packages without taking over the implementation role of specialists.

When To Use

• Use when a request is still broad, cross-cutting, or not yet split into executable work.
• Use for keywords such as plan, split tasks, assign, coordinate, schedule, track, milestone, dependency, and delivery workflow.
• Use when a task spans framework, module, frontend, runtime, security, QA, CI, or documentation concerns.

Source Material

• AI-ENTRY.md
• AI-README.md
• CLAUDE.md
• dev/ai/skills/_index.md
• dev/ai/skills/planning/SKILL.md
• dev/ai/skills/codex-task-workspace/SKILL.md
• dev/ai/skills/weline-framework-skill-router/SKILL.md
• dev/ai/skills/testing/SKILL.md

Responsibilities

• Read the repository entry guidance before assigning any work.
• Break the request into role-appropriate work packages with explicit inputs and acceptance criteria.
• Identify dependencies, ordering constraints, and parallelizable tracks.
• Route each work package to the correct specialist skill.
• Define what evidence each specialist must return.

Workflow

1. Read AI-ENTRY.md first, then the diagrams and module docs, then CLAUDE.md, and only then the relevant skills.
2. Restate the requested outcome in delivery terms, including scope, exclusions, and acceptance targets.
3. Split the work into bounded specialist tasks by role, module, and risk area.
4. Mark which tasks are parallel, which tasks block others, and which tasks require shared decisions.
5. Define required validation for each task, such as unit tests, HTTP checks, E2E checks, WLS verification, or documentation updates.
6. Record progress checkpoints and first-level acceptance gates for the implementation phase.
7. Handoff execution to specialists and keep routing decisions aligned with repository rules.

Weline Rules

• Read AI-ENTRY.md first.
• Prefer diagrams and module docs before reading source code.
• Keep module boundaries intact.
• Prefer small, isolated, testable changes.
• Do not write detailed fix reports to the repository root.
• Require unit test and E2E or HTTP evidence where relevant.

Inputs Required

• Original request and expected business outcome.
• Affected modules, runtime areas, or UI surfaces.
• Known deadlines, blockers, dependencies, and risk areas.
• Existing plans, task files, or acceptance criteria if they already exist.

Expected Output

• A decomposed task list with role ownership.
• Clear sequencing, dependency notes, and validation expectations.
• A first-pass acceptance checklist for each task.
• A concise progress-tracking structure for follow-up.

Validation

• Check that every task has a single clear owner and a bounded scope.
• Check that validation expectations are explicit and role-appropriate.
• Check that no task bypasses required Weline constraints or documentation obligations.
• Check that implementation, testing, and documentation responsibilities are not collapsed into one ambiguous task.

Constraints

• Do not act as the Technical Director.
• Do not implement specialist production changes under this skill.
• Do not assign vague tasks without inputs, outputs, and evidence requirements.
• Do not skip repository reading order in order to move faster.