Use when the user wants to add a new household-level collection that has owner-keyed members (e.g. life insurance policies, future trust distributions, custodial accounts, side businesses). The include-in-rollup flag must cascade through the new collection just like it does for accounts, liabilities, budget items, and income streams. There's a failure-driven checklist test (lib/rollupContract.test.ts) that catches new collections that ignore the flag — this skill walks through adding to it.
Use when the user wants to add a new asset class (e.g. carbon credits, private credit, gold-backed tokens) to the holding taxonomy. Walks through the four files that must change in lockstep — lib/types.ts (extend AssetClass union), lib/portfolio/holdingKinds.ts (kind metadata), lib/portfolio/holdingFactory.ts (builder), and one or more form components under app/_components/holdings/holding-creator/. Skip when the change is just adding a new ETF preset to an existing class — use the presets file directly.
Use for multi-phase work that warrants a coordinator + independent review of each phase. The team-lead subagent decomposes the work, delegates implementation to feature-builder, gates each phase through code-reviewer, and verifies green at phase boundaries. Two operational modes — hub-and-spoke (standard Claude Code) and persistent team (experimental agent-teams feature) — pick by capability available; see below. Skip for single-file fixes or focused engine changes — main agent in-conversation is faster.
Use when the user asks to regenerate the README's comprehensive tour video, add a new feature flow to that tour, refresh it after a UI change, or otherwise work with the Playwright capture pipeline. Produces one animated WebP (~1-2 MB) that inline-renders on GitHub README + a WebM source file. Covers when to regenerate (which UI changes drift the capture), how to add a new feature flow section, and the pacing pattern that makes the video read well. Skip for general Playwright work (smoke tests, visual regression, e2e flows) — those live under e2e/ separately.
Use when a GitHub Actions PR webhook reports a CI failure on this repo (lint / test / build / visual / lighthouse / e2e). Triages by failure class, identifies whether the cause is environmental (CI runner difference), a recent code change, or a flaky test. Returns either a one-line "this is the fix" plan or a clarifying question. Don't use to investigate local-only test failures — those are usually faster to debug interactively.