Webinar DEMO variant of the release phase — runs the real SECURITY audit (the star of this act) and prints a pre-deploy CHECKLIST, for a live before/after demo. Use only for the vibe-coding course demo, NOT for real releases (that's release-product). By default it spawns the genuine audit-security skill as a fresh, read-only subagent and renders its findings as a green/red pre-deploy checklist — the payoff being to SHOW that the method finds real security problems before shipping (leaked keys, missing auth, injection) versus a vibe-coder who just deploys and hopes. Performance is OPTIONAL (--with-performance). REPORT-ONLY: it does NOT file rework tasks, does NOT loop fixes, and does NOT cut a release / bump versions. Reuses the real audit; only the fix/ship machinery is stripped.
Webinar DEMO variant of the spec pipeline — the REAL staged flow (gather-context → product requirements → architecture → dev-architecture), just compressed, NOT the full create-project-spec. Use only for the vibe-coding course demo. It runs four real, SEQUENTIAL stages with an approval gate between each: (1) gather-context interviews the user AND critically pushes back on what they propose; (2) it drafts the functional/product requirements and stops for ok/not-ok; (3) it proposes an architecture (options + trust boundaries) and stops for ok/not-ok; (4) it proposes the dev-architecture (the verification tooling — e.g. Playwright — the build act later uses) and stops. Shorter than the real pipeline (no research subagents, no adversarial-review subagents, no dual outputs, drops validate-idea/user-flows/design phases) but keeps the staged, gated, critical structure. Writes the same filenames the build/release demos read, so the three acts chain.
Webinar DEMO variant of the build loop — builds ONE feature with the real implementer/verifier two-agent mechanism, for a live before/after demo. Use only for the vibe-coding course demo, NOT for real builds (that's build-product). It skips the kanban planning entirely: it writes a single throwaway task file for the feature you name, spawns the real implementer agent to build it, then spawns the SEPARATE, fresh verifier agent to independently find bugs and hand them back — the whole point being to SHOW the second agent catching real bugs in the first agent's work, versus a naive 'it works, ship it'. HARD-CAPPED at 2 implement↔verify iterations (usually 1 is enough) so it fits a webinar slot. Reuses the genuine agents/mechanism — only the surrounding kanban is stripped.
Design the development-time architecture that lets the product be built fast and well with AI: how to run the whole product locally (Docker Compose topology, local stand-ins for cloud/managed services with prod-equivalent APIs, seed data), how it is tested in an AI-drivable way (test levels + purpose-built developer/test scripts + an e2e harness an agent can run and verify, e.g. Playwright for web), how concurrent access to the single shared local environment is coordinated (lock and/or per-run isolation), and how the AI tooling is configured for the chosen stack (Claude Code config, which Anthropic plugins/skills to install, MCP servers, other agents) — including the custom, project-local Claude Code skills to author that wrap those dev/test scripts and the e2e harness so future agents run the verification loop by name — backed by research into the current tools and an adversarial review pass. Use after design-architecture (reads .buildloop/project-spec/architecture.research.md and .buildloop/project-spec/us
Turn the finished project spec into a buildable backlog. Use after setup-dev-environment, as the planning step of the build/development phase, to read the committed feature set (.buildloop/project-spec/product-requirements.research.md), the user flows, the architecture, and the dev-architecture (incl. its developer/test scripts and the custom project skills that wrap them, which become build-out/authoring tasks), and emit a kanban backlog under .buildloop/build-plan/: one markdown file per task (type, status, blockers, acceptance criteria, provenance), plus a derived board.md and a short plan.summary.md. Single pass — each task's blocked_by list IS the dependency graph; there is no parallel scheduling. For an existing project (project_type: existing) it runs in delta mode: it diffs the target spec against the reverse-engineered codebase-map and emits ONLY the gap (rework for divergent code, new tasks for unbuilt features, verify tasks for adopted features, a quality-gate setup task), marking already-matching
Turn the dev-architecture spec into a real, runnable local environment. Use after the project-spec pipeline (reads .buildloop/project-spec/dev-architecture.research.md and architecture.research.md + adr/*), as the first step of the build/development phase, to scaffold the repo and bring up the inner loop: install tooling, init the repo (.gitignore, project CLAUDE.md, settings.json), write the Docker Compose stack + seed data + one-command bring-up, wire the AI tooling (MCP servers, plugins), and scaffold skeleton stubs of the developer/test scripts and the custom project skills (.claude/skills/) the dev-architecture specified. Runs an internal plan → approve → execute: it plans everything but auto-executes only repo-local scaffolding; global installs, API keys, and Claude plugins run only with explicit confirmation. Idempotent (safe to re-run), detect-state-first. For an existing project (project_type: existing) it runs in adopt mode: it reads the reverse-engineered codebase-map, adopts and extends what's alr
Audit the built product's accessibility against the spec's accessibility decisions. Use in the release phase (run by release-product, or standalone) for a product with a UI; it self-skips cleanly for a CLI / library / API with no UI. A fresh, independent accessibility specialist: it reads the target conformance (e.g. WCAG 2.2 AA), viewports, and platforms from .buildloop/project-spec/design-decisions.research.md and drives the real UI to prove them — automated checks (axe-core) PLUS what automation misses: keyboard-only operability and focus order, visible focus, screen-reader semantics (roles/labels/landmarks/alt), color contrast, motion / reduced-motion, and forms + error messaging. Read-only: it drives and ranks (blocker = a WCAG-A failure on a core journey, per the rubric) but NEVER edits product code — it files blockers/majors as rework tasks into the backlog and writes .buildloop/release/accessibility-audit.md. Brings the UI up through the coordinated entrypoint (env lease). Re-runs after a fix to confi
Audit whether the built codebase ages well — the whole-codebase health the per-commit quality gate does not measure. Use in the release phase (run by release-product, or standalone). A fresh, independent staff engineer: where the gate fails a single red commit (lint/type/format/tests), this measures the rot the gate can't see across the whole tree — duplication clusters and the refactor-vs-clone ratio (GitClear-style signals), oversized files/functions, dead code, standing suppression debt (accumulated eslint-disable / type:ignore / noqa the gate only blocks when NEW), and TEST-SUITE QUALITY (coverage on critical modules + mutation testing — does the suite actually catch an injected bug, not just execute the line). Read-only: it measures and ranks (mostly major/minor; blocker only when rot is a real reliability risk) but NEVER edits product code — it files majors as rework tasks and writes .buildloop/release/code-health-audit.md. Mostly static, so it fans out freely. Re-runs after a fix to confirm the signal