ultracode-build

Human output. Read ${CLAUDE_PLUGIN_ROOT}/skills/build-item/references/plain-language-output.md once per top-level run; composed skills reuse it. Apply it to every message.

The build engine for one scoped story: understand → build → verify → risk check → hand back. Invoked by build-item once the branch exists and the item is In Progress.

Argument — item number + one-line goal, optionally followed by profile: <name> and review-moment: release-deferred|pr-boundary (e.g. I20130 enforce the seat-count invariant profile: standard review-moment: release-deferred): $ARGUMENTS

Config: .claude/ds-config.json (verify.*, baseBranch, generated.*, preCommitWiringChecks, conventionsDoc, lessonsDoc, review.localAssistCommand, profile, profileOverrides) — authoritative over any literal here. Coding conventions live in conventionsDoc (AGENTS.md), not the config. lessonsDoc (inline fallback .claude/ds-lessons.md) is the repo's lessons store, distilled from past review findings — this skill READS it and never writes it; review owns every write. An absent or empty lessons file is a valid state: proceed exactly as you would without it, no note, no prompt, no setup step.

Engineering economy. Read ${CLAUDE_PLUGIN_ROOT}/skills/ultracode-build/references/engineering-economy.md before choosing an approach or launching agents. It governs reuse, DRY/YAGNI, bounded parallelism, task-sized Claude models/effort, and the optional read-only local support call.

Delivery profile. How much of this engine's budget a story gets is set by the delivery profile — the canonical contract is ${CLAUDE_PLUGIN_ROOT}/skills/plan/references/delivery-profiles.md, and this skill honours three of its knobs: understandReaders (phase 1), fixFloor (phase 3), and storyVerify (phases 2 and 4). Resolve it ONCE, before phase 1, and announce it with its source:

• Passed in the invocation (profile: <name> — the build-item path): use it as given, do not re-resolve, and announce it as such ("profile: standard — from the invocation"); the caller already walked the order and reported the underlying source. The name must be one of the three the contract defines; anything else (profile: standart) is a stop-and-ask, never a guess or a silent fall-through — with an unknown name no column supplies the knobs below.
• Standalone (no profile in $ARGUMENTS): walk the contract's resolution order — its root marker needs get_item(view: 'full'), since the default projection omits the description and a summary read silently falls through to the config default. Announce the result and where it came from ("profile: prototype — from the plan root", "… — from config", "… — default").

Then apply profileOverrides to those knobs within the contract's floors; report and ignore an unknown knob. The immediate auth/migration/deployed-contract verifier below cannot be overridden away.

Stop and ask ONLY at a genuine fork: an ambiguous or risky review finding, scope that turns out human- or infra-gated, or a destructive/outward-facing action.

1. UNDERSTAND

Build an evidence-backed picture of "done" before writing code. Provision readers proportional to the story — don't reflexively fan all six. The profile's understandReaders is the CAP on that fan-out; the triage below still decides how much of the cap a given story uses.

Load lessonsDoc here, alongside conventionsDoc. It is small and capped per ${CLAUDE_PLUGIN_ROOT}/skills/review/references/lessons-format.md, so read it inline — it is never a reason to spin up a reader. Lessons are ADVISORY hypotheses, NOT rules — this is the difference between them and conventionsDoc, which is human-owned and binding. A lesson is machine-distilled from past findings and never independently reviewed, so it can be stale, overgeneralized, or simply wrong. Before letting one shape the implementation, check that it actually applies to THIS story's code; where it does, handling it up front is the cheapest place to deal with a known mistake class. Where it does not, ignore it — silently, with no note. A lesson never overrides conventionsDoc, the item's spec, or your own reading of the code. Absent or empty file → skip this paragraph entirely and build as usual.