Repository navigation
Effort now scales with risk.
AI agents are rarely wrong. They are usually expensive — re-reading the same repository, re-running the same suite, re-reviewing the same unchanged diff, and continuing long after the change was already proven correct. Run a wave of them in parallel and most of the compute goes into rediscovery.
Do not perform more engineering activity than is necessary to prove the requested change correct.
A shorter execution is not automatically better. A longer execution is not automatically safer. The correct execution is the minimum defensible one that produces sufficient evidence of correctness.
Additive and on by default. One setting restores the previous always-validate-everything behavior.
What it stops
| Waste | How |
|---|---|
| A typo fix triggering the repository-wide suite | LOW budget caps scope at smoke; full is unreachable from a budget alone |
| Re-running a check that already passed | Evidence keyed to the content hash of the files it depended on |
| Re-running one that already failed | FIX_FIRST — fix the cause, don't reproduce the failure |
| Three agents running the same suite | The first claims it; the others consume its evidence |
| Re-deriving the architecture every task | Shared mission facts, carrying explicit confidence levels |
Escalating to full after fixing a test |
Escalation requires evidence of wider impact, not a passing fix |
| Re-reviewing an already-proven diff | DeliveryComplete is objective, and states what not to do next |
Delivery budgets
Classified deterministically before implementation — path patterns and keyword sets, no model call — so the same task always lands in the same budget with an auditable reason.
| Budget | Work | Validation |
|---|---|---|
| LOW | CSS, text, small config, isolated rename, docs | type-check → smoke → diff → stop |
| MEDIUM | Normal feature, endpoint, business rule, DB query | targeted tests → affected build → acceptance → stop |
| HIGH | Auth, security, crypto, migration, infra, concurrency, deployment, secrets, public API, financial/compliance | plan first → integration tests → security checks → broad build → regression |
$ /delivery plan STORY-042
Budget: MEDIUM
Test scope: affected
Impact: 3 changed files reach 22 dependents within 3 hops
Why this scope
· MEDIUM budget starts at "targeted"
· 22 dependent files exceed the 15-file fan-out bound — widened to "affected"
It tells you why, every time.
Three workers, one suite
Worker A → targeted ┐
Worker B → targeted ├→ integration gate → repository-wide validation ONCE
Worker C → targeted ┘
The gate verifies handoffs, aggregates the blast radius, invalidates only what integration itself disturbed, reuses what survives, and runs only what is genuinely missing.
Claims are an atomic mkdir — a directory rather than an exclusive file create, because mkdir is atomic on NFS as well as local POSIX and Windows, where O_CREAT | O_EXCL on a regular file is not.
Measured impact, not guesses
A reverse import graph (TypeScript/JavaScript/Python) cached against the tree hash, with tsconfig path aliases resolved. That matters more than it looks: without it a monorepo reports nearly every first-party import as external, measured fan-out collapses toward zero, and the layer would quietly narrow test scope on exactly the codebases needing it widened.
Deliberately a static scan — resolving a full module graph would cost more than the validation it avoids — and honest about its limits: an unresolvable specifier is counted and reported, so fan-out is an explicit lower bound.
Safety — never optimised away
Authentication, authorization, secrets, cryptography, destructive DB changes, migrations, deployment, financial integrity and compliance classify HIGH on path or keyword. A change described as "a tiny tweak" that touches src/auth/ is still HIGH.
- A downgrade override is refused and logged
- Security checks cannot be skipped at HIGH
- A scope override that would under-test a HIGH change is refused
- A budget is never lowered mid-task; escalation without evidence is refused
Measurement
/cost --efficiencyReuse rate, repeated commands, validation seconds spent and saved, repository-wide runs avoided. Token usage comes from the real usage ledger, attributed by execution window and stated as an approximation. Anything unmeasurable reports unknown — never estimated, because a fabricated count poisons every ratio computed from it.
Getting started
/delivery plan STORY-042 --text "add a paginated orders endpoint"
/delivery check --kind test --command "npm test -- src/api"
/delivery complete --budget MEDIUM --implemented --diff-inspected …
/cost --efficiency/delivery help lists all 13 subcommands. $forge --dry-run and /gate all both consult evidence before running the tier suite; /gate all --force bypasses it.
Configuration
[delivery_efficiency]
enabled = true # master switch
default_budget = "MEDIUM"
evidence_reuse = true
validation_deduplication = true
test_scope_policy = "risk-based" # or "always-full"
stop_when_proven = trueWith enabled = false, every task is HIGH, every scope is full, nothing is reused, and completion is reported but never enforced — the behavior SkillFoundry had before this release.
Also in this release
Provenance contribution ranges (PR #50). verifyProvenance compared a single worker SHA against the integration tree, so every later commit on the same branch made its files read as LOST. It now accepts a base..tip range and verifies the net change. The ledger also stopped verifying itself — it is rewritten after the commit that carries it, so it could never contain its own future.
A latent v5.31.0 defect. git() trimmed stdout, and git status --porcelain encodes state in columns 1–2. Trimming strips the leading space of an unstaged entry (' M src/x.ts' → 'M src/x.ts'), so a fixed-column parse ate the first character of every first path: rc/x.ts. In the mission code it could misclassify a governance path as product.
Compatibility
Fully backward-compatible and additive. No schema migration — the evidence store, shared context and import graph are regenerable caches under .skillfoundry/, so deleting them costs time, never correctness. A config written before this release keeps working; unknown values are ignored rather than adopted.
Tests
264 new tests, 639 passing across delivery, mission, config, commands, forge, gates, budget and docs-validation. Both runtime reuse paths are covered end to end, including --force bypass and an assertion that a failing result is never reused as a pass.
Four defects were found by these tests and fixed before release — including one where the first $forge wiring re-ran the gate suite "to render the detail" on a reuse, which would have made the whole optimisation a relabelled re-run saving nothing.
Full detail: CHANGELOG [5.32.0] · release notes · docs/DELIVERY-EFFICIENCY.md · PR #51