Capture screenshots and structured logs from Flight examples and functional tests, then read them back to verify rendering. Use when you need to SEE what a renderer drew (debug a visual bug, confirm a change looks right across backends), set or update a screenshot baseline, or interpret the screenshot.png / logs.jsonl / status.json output files. Covers one-shot capture, watch mode, baselines, and emitting logs from a scene.
Audit the Flight SDK against its own conventions — exported API naming/verbs/out-params, source filename descriptiveness, dependency hygiene, and TS-upstream↔Rust-downstream alignment. Use when asked to do an "API alignment review", "convention/consistency check", "filename review", "dependency mapping review", or "TS/Rust sync check". Produces ephemeral Markdown reports (gitignored under reports/).
Create or modify a Flight functional scene under functional/scenes/ — one scene rendered across Canvas/DOM/WebGL/WebGPU backends and validated by a fingerprint baseline plus an in-page not-blank/oracle check. Use when adding visual coverage that jsdom unit tests cannot exercise (transforms, blending, clipping, filters, text layout, WebGL specifics) or when verifying a rendering change looks correct across backends.
Turn one package's review.md into its assessment.md — the recommendation layer of the per-package cell under agents/packages/<name>/. Sorts the gaps from review.md into Recommended (sweep-safe, within-package, non-design-decision) and Backlog (parked / cross-package / larger), applying the SDK-wide structural forks (registry-by-default, the subject triad, the bedrock test). Leaves Approved empty — approval is the user's verbal gate. Surfaces design forks and cross-package items to the charter's Open directions, not into Recommended. Use after package-review, or when asked to "assess <package>", "build the assessment", or as a batch stage. Read agents/packages/index.md, structural-forks.md, and CONTRACT.md first.
Generate an UNBLESSED first-pass charter for a package — the non-interactive batch analogue of package-direction. From the package's review.md + structural-forks + domain, draft What it is / proposed North star / proposed Boundaries / Open directions, marked clearly as a DRAFT pending the user's blessing (front-matter draft: true + a banner; Decisions left empty). Never marks anything blessed — it gives the user something to edit in review rather than author from scratch. Use as a batch stage. Read agents/packages/index.md, structural-forks.md, and CONTRACT.md first.
Interactive per-package direction session — the combination pass. For ONE package, gather every existing fragment (charter, review, assessment, worker status report, the diff) into a short briefing, discuss the package's direction with the user, and write simultaneously to charter.md (the user's blessed direction) and assessment.md (Recommended/Backlog of possible changes), freezing any verbal approval into Approved. This is the membrane that turns inbound, as-claimed fragments into blessed, authoritative direction. Use when asked to "set direction for <package>", "run a direction session", "do the combination pass", or "build the charter for <package>". Runs one package per session — a real conversation, not a fan-out. Read agents/packages/index.md first.
Turn blessed work into per-worker briefs staged under outgoing/<target-worktree>/<pkg>.md, ready for the host's `npm run assign:worktree <worktree>` to deposit into that worker's assignments/ inbox. Every brief carries the frozen scope (assessment.md › Approved items, verbatim), a target delta (current verdict/score → expected), an Acceptance section (checkable definition-of-done + the exact verify commands), stop-and-ask rules, and the reporting contract — so a worker's delivery is measurable against the promise on ingest, not taken on faith. Use when asked to "dispatch <package>", "brief the workers", "fan out the approved work", or after an approval session. Read agents/packages/index.md (the Dispatching section) and CONTRACT.md first.
Survey one Flight package and write its review.md — the independent observation layer of the per-package knowledge tree under agents/packages/<name>/. Reads evidence from EITHER the live worktree OR an incoming bundle under incoming/<worktree>-<sha>/, ingests the status.md, source and tests, and reasons against the package's charter.md and the contract (falling back to the codebase-map AAA standard where the charter is silent). Surfaces both how well the package lives up to the contract and where the contract/admin docs themselves need revising. Use when asked to "review a package", "survey <package>", "review the incoming bundle", "ingest the status docs", or to (re)generate review.md before assessment/approval. Read agents/packages/index.md first.