Run the autonomous build loop that drives a system-design spec to shipped features — optional spec-authoring front (spec-writer → review-spec gate → clarifications) → initiator (roadmap) → executor (TDD) → evaluator (judge) → whole-spec panel → commit, looping per Success Criterion. Use when asked to build the app, run the loop, or turn a list of requirements/todos into shipped features. The orchestrator is the main session (bootstrap) + a Workflow (the SC-stream), NOT a sub-agent.
Build ONE medium-size feature autonomously and hands-off — spec (spec-writer → spec-reviewer) → auto-approve → plan → implement (TDD) → verify gate → adversarial panel → e2e, with opinionated medium defaults and NO launch questions. Use when you've described a single feature and want it built end-to-end while you're away, without being pinged. The mid-tier between interactive create-spec+plan and the big build loop. A thin recipe over the author-specs + build-feature workflows — no new engine, no new agents.
Use this skill to review ONE system-design spec for readiness before it is Approved / handed to planning — template conformance, Success-Criteria quality, scope, alignment with the fixed product invariants and prior decisions, reuse pointers, and open questions. Read-only; produces a SPEC-* flagged report with a readiness verdict and direct clarification questions for the author. A soft sensor, not a commit gate.
Use this skill before proposing a commit or PR, and whenever you change README.md, AGENTS.md, CLAUDE_template.md, docs/index.md, or a template. It runs this repository's verify gate (./scripts/check-docs.sh) and explains how to fix a failure — terminology drift, a missing published doc, or whitespace errors.
Use this skill when starting or updating a spec for a non-trivial change — a new feature, a refactor, a high-blast-radius change, or an ambiguous solution space — or when returning to one. It walks the UI/UX → system-design spec → approve → plan flow, points to the template, and covers the spec-status gate and the distillation step on completion.
Verify a user-facing flow in a real browser via the Playwright MCP server — after a change to the app shell, routing, a shared UI primitive, or any flow whose exit criterion is "user-facing", or when asked to confirm a UI change actually works (not just that tests pass). Drives navigate → snapshot → interact → assert. Starter skill — adapt the blocking-failure list to the target repo.
Use this skill when a change touches docs/, AGENTS.md, CLAUDE.md, or a module README, or when a diff changes a public contract or spans more than one area. It audits documentation for drift (doc vs reality) and for sprawl/bloat, and reports findings without modifying anything.