with one click
w-02-light-task-workflow
// In-between task workflow for work that needs a durable task file, distinct implementation examples, and an approval gate but still fits a single-page implementation plan as a rule of thumb.
// In-between task workflow for work that needs a durable task file, distinct implementation examples, and an approval gate but still fits a single-page implementation plan as a rule of thumb.
[HINT] Download the complete skill directory including SKILL.md and all related files
| name | W-02-light-task-workflow |
| description | In-between task workflow for work that needs a durable task file, distinct implementation examples, and an approval gate but still fits a single-page implementation plan as a rule of thumb. |
This skill is the thin orchestration contract for the in-between case: work that needs a durable task file, an explicit approval gate, distinct implementation examples, and decision tracking, but still fits a single-page implementation plan as a rule of thumb.
workflow.mdtemplate.mdUse this workflow when:
Treat the single-page-plan test as guidance rather than a hard routing rule. Use W-01-heavy-task-workflow when the task clearly needs richer phase artifacts, broader coordination, or the light-task plan starts to sprawl beyond that compact shape.
Light-task-workflow maintains one task wrapper folder under <task-root>/, where <task-root> is returned by C-08-ar-management-resolver for the target repository. The task document is always named task.md inside that wrapper folder.
Naming follows the same convention as heavy-task-workflow:
YYMMDD_#<number>_<short-slug>/task.mdYYMMDD_<descriptive-slug>/task.mdCreate the wrapper folder at the same time the durable task artifact is created, before any C-09 worktree exists. Use template.md as the canonical scaffold. Implementation steps and substeps are tracked with checkboxes, and that checklist is the live execution state during implementation. When code changes are in scope, the task file also carries proposed code examples for each distinct change type so the developer can review the intended implementation shape before approval.
Light-task artifacts use minute-precision timestamps in YYYY-MM-DDTHH:MM format wherever they record task-local dates or times.
The agent should:
<task-root>/ for an existing active task covering the same scope before creating a new onetask.md using template.mdC-02-onboarding-drift-detection before planning against onboarding filesC-05-create-or-update-onboarding-files, and the checks listed in the C-08 resolved system/tools.md as one implementation cycleCompleted once the approved implementation cycle and any approved closeout are finishedBefore planning, check:
docs/ root for relevant local reference material when it existssystem/sources.md when they exist<onboarding-root>/ for any repo whose behavior the artifact touchesOptional supporting tools such as Confluence search, Brave search, or Context7 may still be used when the task domain needs them, but they are not mandatory here.
task.md.C-02-onboarding-drift-detection.C-05-create-or-update-onboarding-files and the listed checks in the C-08 resolved system/tools.md are run.C-05-create-or-update-onboarding-files during that implementation cycle or, if consolidation is clearer, in the immediate closeout pass right after implementation.This skill extends the repository instructions and agent definitions. It does not replace them.
Read workflow.md for the phase behavior and template.md for the task-file structure.