w-01-heavy-task-workflow

name	W-01-heavy-task-workflow
description	Orchestrate the full heavy-task lifecycle, maintain the root task contracts, present Creation naming options, ask D-01 and D-02 questions one by one, and route work to the phase-local skills.

W-01 Heavy Task Workflow

This skill is the thin orchestration contract for the full heavy-task workflow. It stays focused on developer interaction, root-artifact ownership, routing to the phase-local skills, and checkpoint transitions rather than re-embedding detailed phase instructions.

Workflow Files

1. workflow/P-00-creation.md
2. workflow/P-01-research.md
3. workflow/P-02-synthesis.md
4. workflow/P-03-design.md
5. workflow/P-04-planning.md
6. workflow/P-05-implementation.md
7. workflow/P-06-closure.md

Supporting Templates

1. templates/task-structure.md
2. templates/requirement-change-candidates-template.md

Orchestrator Responsibilities

The orchestrator should:

1. stay in direct discussion with the developer
2. during Creation, present task-folder naming options and wait for explicit developer selection before scaffolding
3. ask D-01 and D-02 questions one by one and wait for explicit answers
4. maintain task.md, requirements.md, architecture.md, requirement_change_candidates.md, architecture_open_questions.md, and each phase progress.md
   • decision, progress, issue, and history logs in those artifacts are append-only; preserve superseded entries and add later entries that override, reject, or clarify them
5. route work to the appropriate phase-local skill instead of absorbing every phase locally
6. trigger R-01-adversarial-review at the defined checkpoints
7. route factual current-state findings through C-01-findings-capture and C-05-create-or-update-onboarding-files when allowed
8. ensure durable implementation discoveries are captured through C-05-create-or-update-onboarding-files during implementation when stable, or at latest in the immediate closure pass, so later sessions do not need to rediscover them

When To Use

Use this workflow when the task spans multiple files, crosses component or repository boundaries, needs durable phase artifacts, or is likely to continue across sessions.

Delegation Model

1. Phase workflow docs own phase behavior, phase ordering, gates, and artifact expectations.
2. Phase-local skills own the work products inside their subphase folders.
3. This entrypoint owns orchestration, cross-phase state, and developer interaction.
4. Checkpoint review stays independent through R-01-adversarial-review.

Root Artifact Ownership

The orchestrator is the sole writer of the root contracts, staging artifacts, and phase progress trackers:

1. task.md
2. requirements.md
3. architecture.md
4. requirement_change_candidates.md
5. architecture_open_questions.md
6. P-XX-<phase>/progress.md

Where these artifacts contain decision, progress, issue, or history logs, the logs are append-only. Do not delete or rewrite earlier entries to make the current state look cleaner; add a later entry that supersedes, corrects, rejects, or clarifies the earlier one.

Context Recovery

When resuming after context compression or a new session:

1. Read task.md to recover the active phase and current objective.
2. Read the active phase progress.md.
3. Load additional task artifacts only when the active phase requires them.

Before continuing, confirm that task.md still reflects the latest approved developer intent.

Invariants

1. The orchestrator stays in direct discussion with the developer.
2. Requirement and architecture approvals remain explicit developer actions.
3. Root contracts stay separate from phase-owned working artifacts.
4. Planning remains scheduling-only.
5. Implementation runs through the sequential I-01-implementation package.
6. Durable current-state findings are documented through C-05-create-or-update-onboarding-files during the task rather than left only in chat history.

Relationship To Other Instructions

This skill extends the repository instructions and agent definitions. It does not replace them.