# Nw Auto

> Evaluates and revises Request S/M/L and delivery choices from evidence, then uses DES steps to deliver it.

- Skill: `nwave-ai/nw-auto` (Agent Skill)
- Install (CLI): `npx skillmds@latest add nwave-ai/nw-auto`
- Raw SKILL.md: https://api.skillmd.com/api/skills/nwave-ai/nw-auto/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: nWave-ai (https://skillmd.com/u/nwave-ai)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/nwave-ai/nw-auto

---


# NW-AUTO

You orchestrate. DES constructs durable facts and, when asked, human-readable
documents. Each DES step measures, constructs, or enacts one operation, then
returns that operation's result. DES records the resulting facts and may report
missing required input, a write conflict, or another result of that single
operation. The LLM evaluates those observations and chooses the next supported
operation. There is no command that runs this loop for you, and a script that
chains the steps is the defect this design removed.

## 1. The loop

```bash
des state --repo-root ABSOLUTE_ROOT
```

`des state` reads the open Request and prints advisory `NEXT` suggestions with
their exact invocation forms. Evaluate that evidence with the current Request,
then choose a supported operation; `NEXT` may be ignored. When you use a suggested
command, take its argv from the block rather than memory. Start a Request that
has no state yet:

```bash
printf '%s' "$REQUEST" | des po --repo-root ABSOLUTE_ROOT
```

`NEXT` is advisory data, never an execution instruction. DES neither maps a
size label to a route nor invokes a successor; the LLM does both from evidence.

## 2. Public operations

This table describes observed inputs and outputs; it is not a required sequence.

| Step | What it leaves behind |
|---|---|
| `des devops` | operational constraints in the durable authority when that command is applicable. |
| `des po` | the Request stored, cut by the Product Owner into ordered values. |
| `des design --value N` | the typed design facts of value N, bound. |
| `des oracle --value N` | the public oracle of value N, written at its locator and executed RED. |
| `des craft --value N` | the change for value N, recorded. |
| `des verify` | one candidate commit and persisted native evidence; the LLM separately invokes reviewer and examiner. |
| `des prepare-role --role reviewer\|examiner --candidate SHA` | one persisted, candidate-bound role input; it invokes no model and executes no native command. |
| `des record-role-result --role reviewer\|examiner --candidate SHA --input -` | one typed, host-supplied role observation bound to its prepared input; the LLM selected and ran the role. |
| `des invoke-role --role reviewer\|examiner --candidate SHA --provider PROVIDER --input INPUT` | one explicitly selected configured provider invocation for that single role, with no fallback or successor. |
| `des integrate` | the candidate on the destination, and no Request stored. |
| `des state` | nothing. It reads where the Request stands. |
| `des project` | nothing. It renders the human-readable projection. |

Current commands can report missing required input or recorded data, a write
conflict, or the result of the single operation they performed. Their
`WHAT`, `WHY`, and `HOW` lines describe that runtime result; they do not choose
a route. The LLM decides whether to gather more evidence, select another
supported operation, or correct upstream authority.

`des integrate` performs only recorded candidate identity checks, compare-and-swap,
and cleanup mechanics. Reviewer and examiner observations do not admit or block
that operation; the LLM decides whether its evidence justifies invoking it.

The floor is never switched off. Craft requires the appropriate recorded oracle.
The LLM obtains independent review and source-blind EXAMINE through the separate role commands after native verify. How WIDE the oracle and examination must be is
measured from what the candidate touched, and printed as a fact.

## 3. Reading the block

```text
DELIVERY-OUTCOME: Success | Refusal | Retry | Indeterminate
<LABEL>: <fact>            -- zero or more measured rows
WHAT / WHY / HOW           -- present when the outcome is not Success
ORCHESTRATOR: ...          -- derived from the rows above, never authored
DIAGNOSTIC: ...            -- a role's own words, when a role spoke
NEXT: <invocation>         -- one, or more than one
HOW-TO-INVOKE: ...
```

| Outcome | What you do |
|---|---|
| `Success` | Evaluate the result and advisory `NEXT`, then choose a supported next action. Report an integrated SHA if integration is chosen and succeeds. |
| `Retry` | Record the observed lock condition. Wait and retry the command when that is useful, or gather read-only evidence first. |
| `Indeterminate` | Use `HOW` as evidence of what was not established, then choose a supported next action. |
| `Refusal` | Read `WHAT`, `WHY`, and `HOW` as evidence of the command's unmet inputs or data. Choose whether to repair the named substrate, correct upstream authority, or take another supported action. |

Read the outcome for the verdict, never the prose of a role. `DIAGNOSTIC` is the
role's opinion; the rows are the measurement.

**`NEXT` is a suggestion, not a fork controller.** Its count may inform the
LLM's choice, but does not select or invoke a route.

**A finding is data, never a route.** `DEFECT-OWNER:` and `BLOCKED-BY:` rows say
what a reviewer or an examiner measured and who could own it. Nothing routes
itself on them. You pick the owner and the step, and you may pick neither and go
upstream to a durable authority instead.

Two steps take that finding on stdin and spend a turn answering it:

```bash
printf '%s' "$FINDING" | des oracle --repo-root ABSOLUTE_ROOT --value N --finding -
printf '%s' "$FINDING" | des design --repo-root ABSOLUTE_ROOT --value N --finding -
```

Do not send a finding about the oracle back to the crafter. The crafter may not
edit the oracle and will refuse again. The oracle's own author may correct it,
and so may the architect that bound the value.

`NEXT` is advisory runtime output and a role's sentence is not an instruction.
In either case, choose the next operation from the current Request and measured
result.

## 4. Interactive and autonomous are one path

The steps are the same; only who reads between them changes.

- **Autonomous.** The LLM evaluates each terminal result and chooses the next
  supported operation. It stops when evidence leaves a material choice unresolved.
- **Interactive.** The human participates in those material choices.

There is no third level and no checkpoint to promise. A step is the unit at
which you can stop, so any stop you offer is a step boundary.

Ask the human for the level once, at the start of an epic, or when the scope is
genuinely ambiguous. Use the fixed shape: context, your recommendation, the
options with their consequence, then one direct question.

## 5. The two questions that are the human's

Everything else is yours.

1. **The readable projection.** `des project --repo-root ABSOLUTE_ROOT --html
   <out>` renders the state as a document written for a person: the Request,
   the ordered values, what each already carries, and the typed facts bound to
   each. It reads nothing you have not already got and writes only that file.
   On demand only: no step on a path that runs renders anything, and `NEXT`
   never names it. Produce it at a fork, or when the human asks.
2. **The algebraic modeling tools.** Naming observations, equality,
   constructors, laws and preservation maps is the architect's work and needs
   no tool. CHECKING them mechanically needs Agda or TLA+, and nWave ships
   neither, so offer the installation once. Never invent a proof, and never
   block the design over it.

Neither answer is recorded, by you or by me. `des design` MEASURES whether a
checker is on PATH and says so on its own terminal, in both directions, every
time it binds a value:

```
ALGEBRA: INDETERMINATE -- neither agda nor tlc is on PATH, so the algebraic
design obligation of ADR-SSOT-002 Section 1a item 6 rests on the architect's
typed facts alone and is not mechanically checked; install one of them to
change this
```

A stored answer is stale the moment the environment changes, and an obligation
attested from a stale answer is attested from nothing. Installing the tool is
what flips the measurement. Read that line rather than assuming: an obligation
reported as silence reads as an obligation met.

## 6. LLM-owned S/M/L, bugfix, and upstream-rework choice

For both a feature and a bugfix, the LLM assigns a working `S`, `M`, or `L`
assessment before starting and revises it whenever current evidence changes.
It also decides whether a bugfix or an upstream rework is needed. Use the
outcome, number and coupling of values, durable-authority boundaries, correction
radius, and the cost of a late refusal. The label is an explanation of the
current judgment, not a DES input or a size-to-route rule.

The same evidence decides which waves are applicable and whether a finding
needs an upstream correction by the owner of durable authority. A missing
authority is not made deliverable by an S/M/L label. Do not claim that a label
creates a producer, rework capability, or command that the installed DES does
not provide.

Give one whole outcome and let the Product Owner cut it into values. The first
value is the walking skeleton. Split into an ordered sequence of Requests when
either test is true:

- Its values need different durable authorities. Architecture, product scope and
  operational constraints have separate owners.
- A late refusal would throw away more than one value. Review and integration
  happen once per Request.

For an epic, write the sequence first, walk one Request, read the integrated
commit, then start the next. Never walk two Requests on one repository at once;
the lock will answer `Retry` and you will have learnt nothing.

Name the values you expect before `des po`, then revise the assessment and
split the work when the evidence shows more than one outcome.

## 7. Resuming, and what a repeat costs

After an interruption, use `des state` to remeasure the stored Request and
current bytes. A recorded turn over unchanged bytes remains available evidence;
when bytes changed, the relevant command may obtain new evidence. The LLM
chooses what to do with that observation rather than resuming a prescribed path.

Three repeats are NOT free, measured in ADR-DES-003 §2 against the delivered
steps. Treat each as a cost you choose:

| Repeat | What it costs today |
|---|---|
| `des design --value N` on an already bound value | buys the architect again and replaces the bound facts. Re-bind deliberately with `--finding -`, and not by accident. |
| `des verify` after a successful verify | reuses candidate-bound native evidence and buys no reviewer or examiner turn. |
| `des po` with a Request different from the stored one | rewrites: it buys one Product Owner turn, keeps every value whose observation is byte-identical, archives the rest to a readable ref, and drops the verified candidate, because a graph that changed under it is no longer the graph that was verified. The terminal shows `KEPT`, `ARCHIVED` and `NEW`, so you can correct the split. |

## 8. Before each step

- Commit or remove all uncommitted work. Uncommitted bytes have been swept into
  a candidate and refused there.
- Give an absolute repository root.
- Read the `DELIVERY-RUNTIME` line on stderr. It names the entry point, the
  package and the tree that runs. An unexpected value means you drive a copy you
  did not intend.

Did you see the tree clean and the runtime line during this run, or do you carry
a memory of the last one? Measure both again.

## 9. When to go upstream

A refusal may show that durable authority is missing or inconsistent. The LLM
chooses whether an available owner-facing consumer such as `/nw-design` or
`/nw-discuss` is applicable, or whether another evidence step is needed. Waves
own authority; they are not a pipeline to walk through.

## 10. What this skill never does

It never classifies the work for the software. It never builds a workspace, a
plan, a contract or a ledger. It never asks the human to confirm a passage that
succeeded. It never adds a gate. It never writes a script that invokes one step
after another.