plugins/lisa-copilot/skills/lisa-delivery-effectiveness/SKILL.md
Measure whether the work the factory delivers was worth shipping — gate rejection, rework, escape, first-pass yield and cost per delivered item — so autonomy rate cannot stand alone as a success measure.
npx skillsauth add codyswanngt/lisa lisa-delivery-effectivenessInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Autonomy rate answers how much ran without a human. It says nothing about whether any of it should have shipped, and on its own it rewards exactly the wrong thing: a factory that produces rejected work faster scores better.
Each needs a stated numerator, denominator and window, or it is a number-shaped opinion.
| Measure | Counts | Reads as | | --- | --- | --- | | Gate rejection rate | Work the pipeline refused, over work submitted | How much effort is spent producing output the standards reject | | Rework rate | Items reopened or returned after being declared complete, over items completed | How often "done" was not done | | Escape rate | Defects reaching production, over items released | What the gates did not catch | | First-pass yield | Items reaching terminal state with no rework, over items started | The one number that moves only when the whole line works | | Cost per delivered item | Metered spend, over items reaching terminal state | What a unit of accepted output actually costs |
First-pass yield is the summary measure worth watching, because every other failure shows up in it. The other four exist to tell you where it went.
Prefer the systems of record over anything self-reported: the tracker for state transitions and reopenings, CI history for gate rejections, the release record for escapes, the billing or gateway boundary for spend. An agent's account of its own rework rate is the least reliable source available and the easiest one to reach for.
Say which source each measure came from. Two measures drawn from different systems with different definitions of "complete" cannot be compared, and that mismatch is invisible in the result.
Targets are yours to declare — this says nothing about what a good rejection rate is, because that depends on the standards being enforced and the work being attempted. But declare them, disclose them, and let them move in one direction only. A target quietly loosened to match the current number is a redefinition dressed as an improvement.
Report both, together, always. The pairing is the point:
## Delivery Effectiveness
**Window:** dates · **Autonomy rate over the same window:** %
| Measure | Value | Numerator / denominator | Source of record | Target | Trend |
|---|---|---|---|---|---|
| Gate rejection rate | | | | | |
| Rework rate | | | | | |
| Escape rate | | | | | |
| First-pass yield | | | | | |
| Cost per delivered item | | | | | |
**Reading:** which of the four autonomy/yield quadrants this window sits in
**Uncollected:** any measure not gathered, and why — never an estimate in its place
**Filed:** work items raised for measures outside target
development
Prepare a machine — a fresh laptop or a throwaway container — to run coding agents, before any repository exists. Detects which of Lisa's supported agents (Claude Code, Codex, Cursor, OpenCode, Antigravity, Copilot) are already installed, asks which credential manager the machine uses (Bitwarden, 1Password, Doppler, Vault, AWS, or none), and installs only what is missing, each by its vendor's own preferred method. Idempotent, headless by default, and emits a Dockerfile for a spin-up/spin-down environment. Run it on a new machine, in a container, or before cloning anything.
tools
Provision and verify a remote execution environment for a host project — Codex Cloud today, other remote surfaces as they are added. Generates a repository-owned setup script that installs the declared toolchain, materializes secrets through lisa-secrets-access, and runs the project's own hook. Provisions by API where one exists, by driving the vendor console where one does not, and by emitting exact config otherwise — then proves the result with the same read-back regardless of which tier did the work. Use before dispatching any work with executionEnv.
tools
Bring a developer's machine in line with the toolchain the project declares. Reports every tool in remoteEnv.tools that is missing, outdated, or unpinned for this platform, and installs the missing ones into ~/.local/bin from the same pinned, checksummed entries the remote surfaces use — but only when asked. Same manifest, same pins, same installers as lisa-setup-remote-env; what differs is consent and that the pin is a floor rather than an equality. Run it on a fresh checkout, after a manifest change, or when a tool fails at the moment of use.
tools
Route one unit of work to a remote execution surface. Reads the executionEnv parameter (local by default, codex-cloud or claude-web today), verifies the environment is provisioned and bound to this repository, submits a thin skill invocation, records the task identifier to .lisa/remote-dispatch.json, and exits without polling. Routing only — the remote runs the identical skill from the identical repository. Composable and inline: other skills invoke it via the Skill tool rather than users calling it directly.