Boots four Social Home households (a / b / c / d) on adjacent ports, walks the §11 QR handshake (a↔b, b↔c, a↔c, b↔d) plus the §11 simple-pairing trust-relay flow (a auto-pairs with d via b without a QR scan), exercises the federation surface end-to-end (profile sync, posts, moments, highlights, cross-household DMs, multi-household space with remote invites, space-calendar event + cross-household RSVP) under the real WebRTC transport, and asserts that every household sees the others' federated content. Use when validating an end-to-end federation change, smoke-testing a new ``aiolibdatachannel`` release, or reproducing a multi-household sync bug.
How to build, test, and release Social Home Apps — embedded JS extension apps (e.g. chess) that install into Social Home and play cross-household over federation. Use when creating a new app, changing the @socialhome/app-sdk, debugging an app that won't load in the sandbox, or cutting a release of the socialhome-apps repo. Covers the manifest, the mandatory single-inlined-bundle shape for the sandboxed iframe, the SDK API, local single- and two-instance (federated) testing with a headless browser, and the CalVer release flow that publishes the catalog Social Home installs from.
A lean plan-then-subagent-driven delivery workflow for any non-trivial coding task — a feature, refactor, multi-file change, bug fix with real risk, or anything you'd open a PR for. Plan first (explore, ask only on genuine forks), decompose into bite-sized TDD tasks, implement each with a fresh subagent, review every stage in two passes (spec-compliance then code-quality; adversarial for security-sensitive code), do one final whole-change review, and ship behind green CI with docs updated. Use when work is more than a trivial edit, when correctness/security matters, or when the user wants careful, reviewed, high-quality delivery. Skip for one-line fixes, pure Q&A, or read-only exploration.
Bootstrap the chrome-devtools-mcp plugin (and its underlying browser) in this Debian-trixie devcontainer. The plugin expects ``/opt/google/chrome/chrome``; the container ships ``/usr/bin/chromium``; chromium needs ``--no-sandbox`` because the unprivileged user-namespace clone path isn't enabled here; and the plugin defaults to a headful launch so it also needs an X server (Xvfb) on ``$DISPLAY``. Once these four pieces line up, ``mcp__plugin_chrome-devtools-mcp_chrome-devtools__*`` calls work end-to-end. Use this skill when (a) a chrome-devtools-mcp call fails with "Could not find Google Chrome" / "Missing X server" / "Operation not permitted" / immediately closes the page; (b) the devcontainer has just been rebuilt; (c) you want to take a screenshot or interact with a local web service from inside the agent.