Health

---
name: health
description: Review the health of the project's process and practices - waits on people, stalled changes, rework reasons, first-pass verification, waivers, hook denials, configuration gaps - and draft improvements as backlog items for a person to order. Use when the user asks how the process is going, why things are slow, what to improve, or after a release or retrospective.
when_to_use: The user asks how the process is going, what slows the team down, or what to improve.
argument-hint: "[area: flow | quality | discipline | config]"
license: "PolyForm-Noncommercial-1.0.0 with sdlc Additional Permissions, or sdlc Commercial License (https://github.com/marin-ai-tech/sdlc)"
compatibility: Requires the sdlc CLI (sdlc) from the sdlc package.
allowed-tools: Bash(sdlc *)
metadata:
  author: marin-ai technologies
  version: "1"
  generatedBy: "sdlc 0.23.7"
---

Review where the process and its practices suffer, and propose improvements a person can order.

!`sdlc health --json`
If the output above is missing, run `sdlc health --json`.

**Harness contract** (applies to every SDLC workflow)
- `sdlc` is the source of truth for lifecycle state. Read it (`sdlc status --change <id> --json`) instead of inferring the stage from the conversation, and re-read artifacts from disk before using them.
- Gates are human decisions. Never run `sdlc approve`, `sdlc reject`, `sdlc waive` or `sdlc tests unlock`, and never edit `.sdlc.yaml`. When a gate needs a person, stop, name the people from the hint (`next.people` in `sdlc next --json`) rather than the role, and give them the exact command to run in their own terminal.
- An answer in chat is never an approval: gate approvals, `track set`, `backlog move`/`drop` and other human decisions happen only as a command the person runs in their own terminal. Offer the choice, explain the consequences, and give the exact command.
- OpenSpec is the specification subsystem: `sdlc openspec <args>` runs the bundled OpenSpec CLI (`list --specs`, `show`, `validate`, `instructions`). Change folders live in `openspec/changes/<id>/`.
- **Change selection**: use the change named in the input. Otherwise run `sdlc status --json`; with exactly one active change use it, with several ask which one. Announce "Using change: <id>".
- **Language**: talk to the person, and write notes and artifacts, in the person's language; when `locale:` is set in `openspec/sdlc.yaml`, use that language. Keep command names, file names, ids and the template headings as they are (sdlc and OpenSpec parse those headings).
- End every workflow with the next step from `sdlc next --json` (the exact command when a person must act).

**Input**: the user's request (a change id, or a description of the work)

**Steps**

1. Run `sdlc health --json` (or use the result above). Every finding has an `id`, an `area`, a `level` (`bad`, `warn`, `info`), the facts and a recommendation. There is no single score: never invent one.
2. Delegate to the `sdlc-health` subagent when the findings need digging (which changes, which reworks, which denials); it reads only and reports back.
3. Explain the findings in plain words, `bad` first: what happens, the facts behind it, why it matters to the team, and the recommended improvement. When an area is named in the input, keep to it. Say plainly when there is nothing worth acting on.
4. Ask the user which improvements to draft. For each one they choose, add a backlog item that names the finding it comes from: `sdlc backlog add "<title>" --kind chore --outcome "<what improves>" --accept "<how we know>" --source-type health --source-ref <finding id>`. Do not set its priority or move it: ordering the backlog is a person's decision (`sdlc backlog move <B-id> --top`, `--before <B-id>`, `--after <B-id>` or `--epic <E-id>`).
5. For configuration findings (enforcement, verify commands, roles, signing, thresholds), run `sdlc config propose`
   and `sdlc config show <id>`. Explain warnings and give the person `sdlc config apply <id>` to run in their terminal.
6. End with the drafted items and the exact commands a person runs to order them: `sdlc backlog move <B-id> --top`, `sdlc backlog move <B-id> --before <B-id>` or `sdlc backlog move <B-id> --after <B-id>` (`--epic <E-id>` moves it into an epic).

<!--
Generated by sdlc 0.23.7 (https://github.com/marin-ai-tech/sdlc).
Required Notice: Copyright (c) 2026 marin-ai technologies (https://github.com/marin-ai-tech/sdlc)
License: PolyForm Noncommercial 1.0.0 (https://polyformproject.org/licenses/noncommercial/1.0.0) with the sdlc Additional Permissions, or a commercial license; see https://github.com/marin-ai-tech/sdlc
-->