Map Work
Plan for independently verifiable progress, not layers of unfinished infrastructure.
Workflow
- Read the approved spec and its verification plan.
- Inspect the codebase enough to locate real change boundaries and dependencies.
- Identify the thinnest walking skeleton that crosses the necessary boundaries.
- Decompose work into vertical tasks. Each task must change an observable behavior or remove a named delivery risk.
- Add explicit dependencies only when work truly cannot proceed independently.
- Attach proof requirements, rollback notes, and affected surfaces.
- Check coverage: every acceptance example maps to one or more tasks, and every task maps back to scope.
Task contract
id: EW-001
title: outcome-oriented imperative
user_value: observable behavior or risk retired
spec_refs: [acceptance-example-1]
depends_on: []
scope:
in: []
out: []
implementation_notes: []
proof:
- test, command, screenshot, log, or review artifact
rollback: safe reversal
done_when: externally checkable conditions
Planning rules
- Prefer one end-to-end walking skeleton before horizontal layers.
- Keep refactors separate unless they are required for the behavior.
- Expose unknowns as spike tasks with a time-box and decision artifact, not as vague implementation tickets.
- Avoid “implement backend,” “add tests,” or “do frontend” tasks that cannot be accepted independently.
- Include documentation, migration, observability, accessibility, and cleanup in the task that creates the obligation.
- Never write to an external ticket system without explicit authorization. Local planning does not grant authority to create or modify external tickets.
Output
Write .workshop/plans/<slug>.md with a dependency graph, task contracts, acceptance coverage matrix, critical path, parallelizable work, and open risks.
The evidence packet reports the plan path, walking skeleton, number of tasks, critical path, spec coverage, unresolved dependencies, and whether external tickets were created or only proposed.
1---2name: map-work3description: Decompose an approved specification into dependency-aware tickets or executable tasks, each delivering a thin vertical outcome with its own proof. Use for implementation planning and ticket tracking. Do not use to invent requirements or replace a missing spec.4license: Apache-2.05---67# Map Work89Plan for independently verifiable progress, not layers of unfinished infrastructure.1011## Workflow12131. Read the approved spec and its verification plan.142. Inspect the codebase enough to locate real change boundaries and dependencies.153. Identify the thinnest walking skeleton that crosses the necessary boundaries.164. Decompose work into vertical tasks. Each task must change an observable behavior or remove a named delivery risk.175. Add explicit dependencies only when work truly cannot proceed independently.186. Attach proof requirements, rollback notes, and affected surfaces.197. Check coverage: every acceptance example maps to one or more tasks, and every task maps back to scope.2021## Task contract2223```yaml24id: EW-00125title: outcome-oriented imperative26user_value: observable behavior or risk retired27spec_refs: [acceptance-example-1]28depends_on: []29scope:30 in: []31 out: []32implementation_notes: []33proof:34 - test, command, screenshot, log, or review artifact35rollback: safe reversal36done_when: externally checkable conditions37```3839## Planning rules4041- Prefer one end-to-end walking skeleton before horizontal layers.42- Keep refactors separate unless they are required for the behavior.43- Expose unknowns as spike tasks with a time-box and decision artifact, not as vague implementation tickets.44- Avoid “implement backend,” “add tests,” or “do frontend” tasks that cannot be accepted independently.45- Include documentation, migration, observability, accessibility, and cleanup in the task that creates the obligation.46- Never write to an external ticket system without explicit authorization. Local planning does not grant authority to create or modify external tickets.4748## Output4950Write `.workshop/plans/<slug>.md` with a dependency graph, task contracts, acceptance coverage matrix, critical path, parallelizable work, and open risks.5152The evidence packet reports the plan path, walking skeleton, number of tasks, critical path, spec coverage, unresolved dependencies, and whether external tickets were created or only proposed.
leihuang23