# Progress Board > Maintains a visible, counted, one-line task board for ambient progress awareness. Use when running any multi-step task (3+ steps), when switching lanes, when the user asks for status, or when a long background op runs alongside foreground work. - Skill: `jcdavis131/progress-board` (Agent Skill) - Install (CLI): `npx skillmds@latest add jcdavis131/progress-board` - Raw SKILL.md: https://api.skillmd.com/api/skills/jcdavis131/progress-board/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Productivity - Author: jcdavis131 (https://skillmd.com/u/jcdavis131) - Updated: 2026-09-21 - Page: https://skillmd.com/skills/jcdavis131/progress-board --- # Progress Board The user should never have to ask "how's it going". A persistent, counted board in your responses gives ambient awareness at zero interaction cost. ## The board shape ``` N tasks (A done, B in progress, C open) ◼ # in progress ◻ # open … ``` - Counts up top: `N tasks (A done, B in progress, C open)`. The delta from last turn is the real signal. - Glyphs: `◼` in progress · `◻` open · `☑` done. Pick one set and stick with it. - Collapse the tail: `… +K pending` when the board would exceed ~6 visible lines. ## Naming rule — deliverables, not verbs Bad (ambiguous "done"): - `Look at the data pipeline` - `Fix routing` Good (unambiguous "done"): - `Build packages/data-ingest data-collection pipeline (OSS stack + fallbacks)` - `Wire /v1/runs + /v1/data-ingest routers into api` A task is done when the named artifact exists and behaves as the parenthetical constrains it. If you can't phrase the task as a noun + scope + (constraint), the task isn't well-defined yet — refine before adding it to the board. ## When to show the board - At the end of a turn where you started or finished a task. - When the user asks "what's the status" (then keep showing it on subsequent turns). - When you're about to switch lanes — the board makes the switch legible. ## When NOT to show the board - Single-step tasks — a board for one item is noise. - Pure conversational turns with no task progress. - After every single trivial sub-step — the board tracks user-visible tasks, not internal ticks. ## Update discipline - Move a task to `done` only when the artifact exists and you've verified it (smoke-import passed, test green, file written, command succeeded). Not when you've "finished thinking about it". - `in progress` rule: one **active foreground** `◼` at a time. A second `◼` is allowed only when it represents a **backgrounded long-running operation** (a multi-minute build, a long test run, a deploy) that you've parked while doing other work. Two active foreground `◼` means you're context-switching — pick one. When the background op finishes, immediately mark it done or re-foreground it; don't leave a stale `◼`. - If a task grows a sub-board, split it into its own task rather than nesting. ## Phased variant — for a large feature When a single task is large enough that "done" is far away, break it into numbered phases, each with a concrete deliverable, in dependency order, with the last phase explicitly the verify+report gate: ``` Phase 1: → Phase 2: Phase 3: Phase 4: Verify, task done, readiness report ``` Rules: - **Numbered phases** — the unit is a phase, not a sub-step. - **Each phase has a named deliverable**, often a file path (`docs/reviews/ui-ux-engagement-audit.md`). A phase without a deliverable isn't a phase; it's a sub-step. - **Dependency order** — audit → design → build → verify. A reviewer can read top-to-bottom and the story makes sense. - **The last phase is the gate** — "Verify, task done, readiness report". The validate gate is built into the plan, not an afterthought. - **One `◼` per phase at a time** (with the backgrounded-op exception above). Use the phased board for features spanning multiple phases; use the flat board for ordinary multi-task work.