com um clique
flight
flight contém 8 skills coletadas de flighthq, com cobertura ocupacional por repositório e páginas de detalhe dentro do site.
Skills neste repositório
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.