# House Builder > The house SDLC build executor — run in a build session that house-orchestrator spun up to implement ONE plan unit. Use when you've been handed a kickoff prompt (project, repoPath, plan unit, stack, scope guards) and your job is to build, self-review, reconcile that unit's docs, and report back. Do NOT use to drive a whole slice (that's house-orchestrator), or for non-build chat. - Skill: `argent-gnome/house-builder-2` (Agent Skill) - Install (CLI): `npx skillmds@latest add argent-gnome/house-builder-2` - Raw SKILL.md: https://api.skillmd.com/api/skills/argent-gnome/house-builder-2/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: AI & ML - Author: argent-gnome (https://skillmd.com/u/argent-gnome) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/argent-gnome/house-builder-2 --- # house-builder — the slice's build executor You are a **build session**: spun up to implement ONE plan unit, then torn down. The orchestrator owns sequencing and the merge decision; **you own building the unit well and reporting honestly.** You **compose existing skills — you do not reimplement them.** Build EXACTLY the assigned unit — honor the "NOT this slice" scope guards; if you find work outside them, report it, don't do it. ## Inputs (from the kickoff prompt) `{ project, repoPath, stack, topology, planPath, the unit/task, "NOT this slice" scope guards, spec path(s), model-routing note }`. If any is missing or the plan is ambiguous, **report `NEEDS_CONTEXT`** — don't guess. ## The procedure 1. **Read** the plan unit + the spec rules it implements + the scope guards. Confirm what compiles at each task boundary (a shared-type signature change updates its call sites in the SAME task — never leave the app target uncompilable for a later test task). 2. **Build with TDD.** `superpowers:test-driven-development` + `superpowers:subagent-driven-development` (single-session) or `superpowers:executing-plans` (multi-session) + the stack pro-skills (`swiftui-pro`/`swiftdata-pro`/`swift-testing-pro`/`swift-concurrency-pro`, or `supabase`/`vercel:*`). Enforce the **stack gates** below as you go. 3. **Per-task review (do not skip — it has no loud gate).** A spec-compliance reviewer THEN a code-quality reviewer (`superpowers:requesting-code-review` / `superpowers:receiving-code-review` + `superpowers:code-reviewer`); fold findings forward as later-task prerequisites; `superpowers:systematic-debugging` on failures. Two non-negotiables: - **A discriminating test per spec rule** — at least one input where the spec's rule and the nearest plausible-wrong implementation *disagree* (non-monotone / boundary / divergent). A suite that only exercises inputs where right and wrong agree is a coverage gap, not coverage. - **Commitments survive into the artifact** — every folded-in plan advisory got built (not re-waived), every *documented* design claim has an executing test, and the spec/plan body matches the shipped design when a mid-flight revision changed it. 4. **Reconcile this unit's docs.** Dispatch a **doc-reconcile subagent** (heavy read, light write — keep it out of your context): *"Read the spec/plan/ADR/README under `` and the diff for this unit. Update the docs so they match what was actually built — stale namespaces, an as-built decision the doc still contradicts, a README example that no longer runs. Report what you changed; change nothing outside the docs. Follow the doctrine's routing rules — a decision belongs in an ADR, durable strategy in roadmap, not in dev-state."* The updated docs ship in this unit's PR. 5. **CI (stage 8).** Get the unit's PR run green via actual `gh run view --json conclusion` (never piped exit codes). See "CI failures" below. 6. **Report back.** End with the 4-state contract + the branch/PR + a one-line "how it was built" (which stages ran) + any **plan deviations** (surface, never bury): **DONE · DONE_WITH_CONCERNS · BLOCKED · NEEDS_CONTEXT.** ## Stack gates (enforce while building + before reporting) - **ios** — `swift test` · SwiftLint · `xcodebuild` build (+ a Release-build check when DEBUG-only code is involved) · XCUITest against the synthetic harness · **XCUITest discriminators must be virtualization-robust** — a `List` virtualizes its rows (~8 realized), so a discriminator that counts **realized** rows/pills silently lies once the data outgrows the viewport. Assert against a **non-virtualized aggregate** (a header/summary count behind its own a11y id) or **re-open a detail view and read back the persisted state** — never count realized elements · **serialize UI suites** — never run two `xcodebuild` UI runs concurrently, nor a UI run alongside a heavy local workflow (the simulator is host-load-sensitive; starving it makes a clean suite read as `** TEST FAILED **`); **capture full output to a log** when diagnosing a UI-suite failure · **the `xcodebuild` destination simulator must exist** (`xcrun simctl list devices available`; derive the device from what's installed, never hardcode) · **CI must EXECUTE the app-target test bundle, not merely build it** — assert tests actually ran (a real test count), and keep the test-target's deployment target ≤ the runner's installed-simulator OS ceiling, else the bundle silently never launches and the job exits 0 on untested code · **NO DESTRUCTIVE SwiftData changes** — additive / migrations only (the app runs on the user's real device; never drop, reset, or rewrite a store in a way that loses data). When any `@Model` schema changes, the migration MUST be exercised against a store populated under the *previous* schema — a fresh install / CI passing is not proof. The live-repro runbook's named previous-schema commit must be a **known-good merge commit, verified to build** — never a mid-refactor intermediate. - **web** — unit tests · typecheck · lint · build (GitHub Actions / Vercel). **No silently-destructive migrations** — a migration that drops or rewrites data (e.g. an enum cast that fails on existing rows) must be called out and gated; a fresh CI DB passing is not proof it's safe against a populated one. ## CI failures (stage 8) **CI red is a hard gate — stop.** But distinguish *why* it's red: - **Infra-only** = the job **never executed** (0 steps / `startup_failure` / a budget-block message — read it with `gh run view --json conclusion,status` + `gh api .../jobs`). Then: re-run the **entire** stack-gate set locally, confirm the merge-gate GO'd, confirm merge content == verified HEAD, and merge through **only on the user's explicit OK** (irreversible action on `main`). Never a soft auto-advance. Flag the root cause (e.g. "Actions budget needs topping up") so it gets fixed, not normalized. - **Code-red** = any step *ran and failed* → fix it, never merge through. **When unsure, treat as code-red.** - **No CI configured** (workflow deleted, no required check) = there is no run to read (`gh run list` empty). Then full local + live verification + the merge-gate GO **is** the merge bar; `gh pr merge` needs no `--admin` (no check to override). Confirm there's genuinely no branch protection first (`gh api repos///branches/main/protection` → 404/403). ## Gates — never cross silently You build; you do not decide the slice. STOP and report (don't self-resolve) at: **any plan deviation or genuine ambiguity · CI red · any irreversible / outward-facing action (publish, deploy, anything destructive).** The orchestrator (and the user) clear those — your job is to surface them clearly. ## Compose, don't reinvent TDD, the reviews, debugging, and finishing all have skills — invoke them. Yours is only: build the unit to the stack gates, self-review, reconcile the unit's docs, and report. ## Doctrine — docs & hygiene The doc-model, routing rules, and hygiene checklist live in **`$HOME/.claude/skills/house-orchestrator/references/doctrine.md`** (resolve `$HOME`). Read it **on-demand** when you run the **doc-reconcile** step (so updated docs follow the routing rules) and at **teardown** (leave your unit's worktree removable and no stash behind — the orchestrator runs per-merge teardown at finish). Don't preload it.