# Map Work

> 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.

- Skill: `leihuang23/map-work` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add leihuang23/map-work`
- Raw SKILL.md: https://api.skillmd.com/api/skills/leihuang23/map-work/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- License: Apache-2.0
- Author: leihuang23 (https://skillmd.com/u/leihuang23)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/leihuang23/map-work

---


# Map Work

Plan for independently verifiable progress, not layers of unfinished infrastructure.

## Workflow

1. Read the approved spec and its verification plan.
2. Inspect the codebase enough to locate real change boundaries and dependencies.
3. Identify the thinnest walking skeleton that crosses the necessary boundaries.
4. Decompose work into vertical tasks. Each task must change an observable behavior or remove a named delivery risk.
5. Add explicit dependencies only when work truly cannot proceed independently.
6. Attach proof requirements, rollback notes, and affected surfaces.
7. Check coverage: every acceptance example maps to one or more tasks, and every task maps back to scope.

## Task contract

```yaml
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.