---
requires: scratch/garden-scan.md
produces: scratch/garden-assessment.md
---
Judge the health of each wave and the chord as a whole. Where is momentum? Where is drift?
## Orientation
Before starting, orient yourself in this branch:
- Read `scratch/` — design docs and notes for the current work live here
(`scratch/<branch>.md` is this PR's design; `scratch/questions.md` holds open
questions and assumptions).
- Read wave/PM context only when the seed names the exact wave, task, project,
or a concrete coordination question; never infer it or repair access as a
prerequisite.
- Read the repo's agent doc (`CLAUDE.md` / `AGENTS.md`) for conventions.
Write design artifacts, notes, and open questions under `scratch/`. Don't
re-derive what these already record.
## Goal
The scan is raw data. This step turns it into judgment. Which waves are
thriving? Which are stalled? Is the overall direction still right, or has
the ground shifted?
Assessment is honest. A wave that's producing PRs but shipping shallow work
isn't healthy. A wave that's blocked but blocked on the right problem might
be fine. Look past activity to actual progress toward finish lines.
## Workflow
1. **Read the scan.** `scratch/garden-scan.md` is your primary input.
2. **Assess each wave.** For each member wave, evaluate:
- **Velocity** — Is work shipping? At what rate? Accelerating or decelerating?
- **Depth** — Is the work substantive? Are finish lines actually being crossed,
or is the wave producing motion without progress?
- **Alignment** — Is the wave building what its README says it should?
Has the work drifted from the stated goals?
- **Health** — Are blocks being resolved or accumulating? Is CI green?
Are PRs aging?
- **Sequencing** — Is the wave working on the highest-leverage item?
Would reordering the remaining items change outcomes?
- **Silence** — A silent wave has no items, or its items didn't survive
coherence review. That's healthy when nothing compelling exists to build.
It's a problem when the area is changing and the wave isn't noticing.
Silent waves signal to the user: "add items here if you want work
done in this area."
- **Coherence** — Do the wave's remaining items still make sense? The
codebase evolves between garden cycles. Items can go stale: finish lines
moved, designs diverged, value diminished. Waves should reorganize
internally — this is a single beat, not a review. Flag waves
whose items look incoherent so play-chord can account for it.
3. **Assess the chord.** Look across all waves:
- **Balance** — Are waves progressing roughly in sync, or has one
raced ahead while others stall?
- **Interference** — Are waves stepping on each other? Conflicting
changes, competing for the same code, contradictory directions?
- **Gaps** — Is there work that needs doing that no wave owns?
- **Redundancy** — Are multiple waves doing equivalent work?
- **Phase fit** — Does the current phase (from the live task mix) still
make sense given what's been learned?
4. **Identify the pressure points.** What are the 1-3 things that, if
changed, would have the biggest impact on overall progress?
## Task references
When the assessment names more than one Task, preserve or refresh their rows
from `lf roadmap --wave <wave> --json` and `lf status <wave> --json`. Render
operational Task lists with the shared reference:
```markdown
[identifier · Task title](provider URL) — status; next action/owner
```
Use this ID-first form in operational lists. In prose, use
`[Task title · identifier](provider URL)` on first mention; shorten later
references when unambiguous.
Fill the link from `task.identifier` and `reference.issue_url`, and the readable
title from `task.title`. Take status from `runtime.status` or the roadmap
`section`, and next owner from `next_move.owner`. State the next action only
when supported by current evidence; leave unknown state unknown. Include an
active PR/workspace slug only when navigating that workspace is the job. In
roadmap, use `active_pr.slug`; in status, match `active_pr` to `prs[].id` and
use that PR's `slug`. Fall back to `reference.workspace.slug`. Never infer a
URL, branch, or slug from a title or identifier. If a link is absent, keep the
readable title and available status without inventing a URL.
## Output
Write `scratch/garden-assessment.md`:
```markdown
# Tend Assessment — <date>
## Summary
<2-3 sentences: overall chord health and the key tension>
## Wave: <name>
**Pressure**: <the one thing most affecting this wave's progress>
(repeat for each member wave)
## Chord-Level
**Balance**: <how waves relate to each other>
**Gaps**: <unowned work, if any>
**Phase**: <is the current task mix still right?>
## Pressure Points
1. <highest leverage change>
2. <second>
3. <third, if needed>
```
## What to avoid
**Vague health ratings.** "Steady" without evidence is useless. Every judgment
needs a specific observation backing it.
**Activity as proxy for progress.** Lots of commits doesn't mean a wave is
healthy. Finish lines crossed is the metric.
**Premature solutions.** Identify pressure points, don't propose fixes. That's
play-chord's job.