# The Six Skills

| Skill | Owns | Produces | Runs as |
| --- | --- | --- | --- |
| `etabli-orchestrator` | Where the project stands, the route, the gates, the lane policy | decisions about what happens next | a human's session |
| `etabli-spec` | Requirements (stage A), then decisions and contracts (stage B) | `delivery/prd.md`, decision records, `delivery/contracts/` | a human's session |
| `etabli-decompose` | Splitting approved work into epics and independent tasks | `delivery/decomposition.md` and `delivery/tasks/<id>.md`, validated | a human's session |
| `etabli-status` | Claims and run state, read from git | exit codes and tab-separated rows | `sh`, no model |
| `etabli-implement` | One task into one validated change | a working tree and a handoff report | an unattended lane |
| `etabli-refine` | Reviewing that change, fixing what the review finds, and simplifying it | the same working tree, and a Refinement section in the report | the same lane, a second session on a stronger model |

Only `etabli-orchestrator` is invoked by a human directly. The rest are reached through it, or through `launch-lanes.sh`.

## Refinement, the second session

`etabli-refine` is the second session of every lane. It did not write the change, it runs on the [tier](<https://ancelin-code.github.io/etabli/guides/tiers/index.md>) above the task's, and it works in one pass: review the change against the task's acceptance criteria, fix what that finds, then simplify the lines the change added without altering their behaviour, and re-run validation.

Simplifying last means the fixes get tidied too, and no effort goes into polishing code about to change. A failed refinement never loses the implementation: the change is published as it was, and the report says so. `--no-refine` on the launcher skips it.

## Why the spec is one skill

`etabli-spec` covers two stages rather than shipping as two skills: they are written in one sitting from the same source material, and the design spine is worthless without approved requirements to hang it on.

## Review is not shipped

Review is deliberately **not** part of the kit: use the harness's own review capability, or install a review skill alongside the kit and compare it against the unassisted harness before adopting it.

The orchestrator can suggest a review skill for each pull request; see [Review the Pull Requests](<https://ancelin-code.github.io/etabli/guides/review/index.md>).

## The rule behind every skill

A skill must beat what the harness does unassisted on its task, or be free. A rule stays in the kit only if removing it measurably degrades results. The kit exists because an earlier skill lost to an unassisted harness by adding ceremony the model did not need.