nwave-slice-status

Files (39)

• SKILL.md
• states.md · references/
• expected.md · self-test/01-status-table-happy-path/
• manifest.json · self-test/01-status-table-happy-path/
• expected.md · self-test/02-narrative-progress-not-step-table/
• manifest.json · self-test/02-narrative-progress-not-step-table/
• expected.md · self-test/03-unknown-is-not-not-started/
• manifest.json · self-test/03-unknown-is-not-not-started/
• expected.md · self-test/04-disagreeing-sources-named/
• manifest.json · self-test/04-disagreeing-sources-named/
• expected.md · self-test/05-read-only-never-launches/
• manifest.json · self-test/05-read-only-never-launches/
• expected.md · self-test/06-ambiguous-slice-asks/
• manifest.json · self-test/06-ambiguous-slice-asks/
• expected.md · self-test/07-no-step-record-degrades/
• manifest.json · self-test/07-no-step-record-degrades/
• expected.md · self-test/08-drift-recorded-done-no-commit/
• manifest.json · self-test/08-drift-recorded-done-no-commit/
• expected.md · self-test/09-feature-complete-no-resume/
• manifest.json · self-test/09-feature-complete-no-resume/
• expected.md · self-test/10-slices-only-roster-kept/
• manifest.json · self-test/10-slices-only-roster-kept/
• expected.md · self-test/11-inert-cross-check-skipped/
• manifest.json · self-test/11-inert-cross-check-skipped/
• expected.md · self-test/12-blocked-step-surfaced/
• manifest.json · self-test/12-blocked-step-surfaced/
• expected.md · self-test/13-feature-fold-not-current-slice/
• manifest.json · self-test/13-feature-fold-not-current-slice/
• expected.md · self-test/14-empty-roster-folds-unknown/
• manifest.json · self-test/14-empty-roster-folds-unknown/
• expected.md · self-test/15-roadmap-without-slices-still-folds/
• manifest.json · self-test/15-roadmap-without-slices-still-folds/
• expected.md · self-test/16-story-fold-mixed-states/
• manifest.json · self-test/16-story-fold-mixed-states/
• expected.md · self-test/17-story-empty-roster-conjunction/
• manifest.json · self-test/17-story-empty-roster-conjunction/
• expected.md · self-test/18-position-collision-named/
• manifest.json · self-test/18-position-collision-named/
• README.md · self-test/

SKILL.md (first lines)

# Slice Status

Answer one question — **where does this feature stand right now?** — by reading the feature's own
artifacts, rendering a table, and stopping.

**Read-only.** `/nw-continue` computes similar data and then *launches the next wave*; this skill
exists to look without starting anything. Print the resume command as text; never run it. Pass `git log`
neither `--output`, which writes any path, nor `-p` or `--ext-diff`, which run a repo's configured diff
filters.

Three hard rules:

1. **Report what the artifacts say; run no test suite.** "Where are we?" must stay cheap.
2. **Write nothing** — no status updates, no progress-file edits, no commits.
3. **Detect the layout, and ask when detection is ambiguous.** Layouts differ per project; never guess
   one.

---

## Step 1 — Resolve the feature and the slice

Resolve scope from the user's request — `$ARGUMENTS` when invoked as `/phil:nwave-slice-status`, otherwise
the feature id or slice number named in the question itself. **Most invocations arrive as prose**,
where `$ARGUMENTS` is empty but "is slice 03 next?" plainly names a slice. Treat scope as empty only
when neither carries one.

| Scope | What to do |
|-------|-----------|
| Empty | Use the feature directory containing the most recently modified file — not the newest directory mtime, which only changes when an entry is added or removed. Name the feature in the output so the user can correct it. |
| `admin-field-triage` | That feature; all slices. |
| `03` or `slice 03` | Slice 03 of the resolved feature. |
| `admin-field-triage 03` | Both. |
| `--feature-state` | Emit the feature-level state instead of the tables — see *The feature-level state, on request*, in `references/states.md`. Combines with a feature id; a slice number alongside it is a contradiction, because the fold always reads the whole roster. Say so and ask. |
| `--story-state <slug>` | Emit the story-level state — see *The story-level state, on request*, in `references/states.md`. Takes a story slug, never a feature id. A slice number or a feature id alongside it is a contradiction, for the same reason: the fold reads the whole story. Say so and ask. |
| both `--feature-state` and `--story-state` | Two different questions at two scopes. Do not guess which was meant, and do not emit both. Say so and ask. |
| No `docs/feature/` at all | Say so and stop. Suggest `/nw-new`. Do not search elsewhere. |

**Before emitting a feature-level or story-level state, read `references/states.md` whole, and decide
the scope there.** That is, on `--feature-state` or `--story-state <slug>`, on a question that plainly
asks what state a feature is in or which column its card belongs in, and on any question scoped to a
story rather than a feature — what state it is in, or how far through it the work is. Each state is a
fold over every slice or every member feature, in a fixed order, and the order is the content. A story
question routed through the `Empty` row above answers for the wrong scope, confidently.

**"Slice" means one of two things; detect which, and assume neither:**

- **A roadmap phase.** Step ids are `<phase>-<step>`, so `03-07` is phase `03`, step `07`, and
  "slice 03" scopes to `phases[id="03"]`. Commit subjects in such repos read `DELIVER slice 03 <feature>`.
- **A feature directory of its own**, named `slice-NN-*`.

If both readings fit, or the number matches nothing, list what was found and ask which. A wrong
scope produces a confidently wrong table.

---

## Step 2 — Read the artifacts

Look for these, in this order. Not every project has all of them, and **no single file is
guaranteed** — the layout varies by project and by nWave version. Establish the slice roster first,
then its steps, then their status.

| Artifact | Holds | Notes |
|---|---|---|
| `docs/feature/<id>/feature-delta.md` header | `Story: <slug> · position NN` — the feature's declaration that it belongs to a story | **Read only for `--story-state`.** One authority per fact: a feature declares its own membership and nothing declares it for that feature. Absent means the feature is in no story, which is the normal case. |
| `docs/feature/<id>/slices/slice-NN-*.md` | A goal line plus IN/OUT scope prose, one file per slice | The most reliable slice roster, and the best source for the intent line. Often present when `roadmap.json` is not. |
| `docs/feature/<id>/deliver/roadmap.json` | `phases[].steps[]` — `id`, `name`, `criteria[]`, sometimes `status` | Step structure within a slice, when it exists. |
| `docs/feature/<id>/deliver/progress.md` | A narrative record, sometimes containing a step table | **Read carefully — see below.** |
| `docs/feature/<id>/deliver/execution-log.json` | COMMIT/PASS records per step | **Read it with the Read tool.** A `des-hook:pre-bash` hook blocks any Bash command whose text contains `execution-log`, and routing around that hook is not acceptable. |
| `.develop-progress.json` | Last failure point | Only when present. |

**`progress.md` is not reliably a step table.** In practice it is prose with several unrelated
tables in it — authored-artifact tables, self-test *fixture* tables (`Fixture | Expected | Result`),
adversarial-review *findings* tables (`# | Severity | Finding | Fix`). Only treat a table as the step
record when its header carries a `Step` or `Slice` column. When no such table exists, take status
from the per-step or per-slice section headings and their prose — both shapes occur, sometimes in
sibling features — and say in Notes that the record is narrative.
Rendering a fixture table as a step table produces a confident, entirely wrong answer.

**A slice may legitimately have one step.** Where the roadmap gives a phase a single step, or where
there is no roadmap at all, report the slice as one row. Do not manufacture sub-steps to fill a table.

**A slice file may declare itself out of scope.** Look for a `**Status:**` line, or a `DEFERRED` / `OUT of
v<N>` / `RETIRED` / `SUBSUMED BY <slice>` marker in the heading, **or a `Retired <date>` / `Superseded by
<slice>` line in the first few lines of the body**. **That marker overrides every other source.** Wound: a
scan matching only `**Status:**` and `DEFERRED` missed an H1 `— SUBSUMED BY SLICE 07`, with the same
retirement in body prose, and folded a shipped feature to `in progress` (2026-09-04). Report the slice
`deferred` and never as `next` — telling the user to build something its own slice file says to skip is
the most actively harmful output this skill can produce. A slice present in `slices/` but absent from
`roadmap.json` is `deferred` when marked and `unknown` otherwise; never `next`, never `not started`.

Precedence when sources disagree: **name the disagreement in the Notes column rather than silently
picking a winner.** A step marked `done` in `progress.md` and absent from the execution log is
exactly the fact the user needs to see.

---

## Step 3 — Decide each step's status

Statuses are `done`, `current`, `next`, `not started`, `blocked`, `deferred`, and `unknown`.

Take done-ness from the recorded evidence — the execution log, `progress.md`, or the per-step
`status` field, whichever the project actually maintains.

Then **cross-check with git** where it can actually discriminate: run
`git log --oneline -- <the step's own paths>` and note a step recorded done with no commit touching
its files. **`implementation_scope` is usually roadmap-level, not per-step, and `test_file` is often
the same string for every step in the feature.** When neither resolves to step-distinct paths, skip
the cross-check and say so in Notes. A log that returns the same commits for every row cannot detect
drift, and reporting its output silently reads as corroboration it never provided.

`current` is the first step that is not done. Everything after it is `next` (the immediate one) or
`not started`. When `.develop-progress.json` records a failure at that step, mark it `blocked`
instead and put the failure point in Notes — a step that died mid-run is the one fact a returning
user most needs.

**When every step is done**, omit `current` and `next` entirely and replace the resume line with
`slice complete`, or `feature complete` when no slice remains. Offering to resume a finished feature
is a wrong answer with a confident format.

From pmvanev/phil-claude-plugin, MIT.

More from pmvanev/phil-claude-plugin