菜单
Example/sample program only: patterns and registry for widgetbook host-overlay demo pages (widgetbook/lib/*_overlay_page.dart). Use when adding or reviewing widgetbook knob demos — not for package overlay architecture (see reactive-riverpod, form-inputs).
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Semantics contract for Adaptive Card elements — how labels, headings, live regions, and decorative-vs-meaningful images are exposed to screen readers, and how to test them with `tester.ensureSemantics()`. Use when adding or changing any element, input, or action widget, and at code review.
Optional flutter_adaptive_cards_host_fs package — backend invoke serialization, PlainJson/Teams adapters, AdaptiveCardBackendHandlers, and response effects. Use when wiring Submit/Execute/Refresh/onChange to a flow-service or reviewing associatedInputs + invoke round-trips.
Use when finalizing a change in the Flutter-AdaptiveCards monorepo — before you propose, commit, or merge — as the manual or AI-assisted review gate. Checks monorepo hygiene, Adaptive Cards spec compliance, theming, widget keys, accessibility, and testing.
FVM rules for the Flutter-AdaptiveCards monorepo. Prefix every `flutter` and `dart` shell command with `fvm`. Use when vendored dart/flutter skills show bare commands, when installing or switching the pinned SDK, or before analyze, test, pub, or build_runner workflows.
Classify, audit, and enforce the Diátaxis documentation framework across the Flutter-AdaptiveCards canonical `docs/` and package READMEs. Keeps each doc in exactly one quadrant (tutorial / how-to / reference / explanation) and flags mixed-mode drift. Use when writing or reviewing a doc under `docs/`, adding a `doc_type:` front-matter tag, auditing the doc set for gaps or violations, or when the user mentions Diátaxis or documentation structure. Advisory only — it proposes splits, it does not silently move or rewrite files.
Use before adding a new Adaptive Card element type — implementing its widget, registering it, or testing it. Covers the StatefulWidget + mixin pattern, CardTypeRegistry registration, the extension API, and optional packages (charts).
| name | adaptive-cards-widgetbook-overlay-demos |
| description | Example/sample program only: patterns and registry for widgetbook host-overlay demo pages (widgetbook/lib/*_overlay_page.dart). Use when adding or reviewing widgetbook knob demos — not for package overlay architecture (see reactive-riverpod, form-inputs). |
widgetbook/is a demonstration app. Library overlay contracts live indocs/reactive-riverpod.mdand package tests. Seedocs/documentation-scope.md.
Canonical reference: docs/widgetbook-overlay-demos.md
Use this skill for Widgetbook demo plumbing (GlobalKey, knob lifecycle, use-case registration). Library overlay APIs are covered by adaptive-cards-testing and docs/reactive-riverpod.md.
widgetbook/lib/*_overlay_page.darttextBlockOverlayPageKey / factSetOverlayPageKey existdocs/widgetbook-overlay-demos.md — shared checklist + registry.widgetbook/lib/*_overlay_page.dart and check each registry row.GlobalKey passed from adaptive_cards_use_cases.dartOverlayDemoPageState mixin from widgetbook/lib/overlay_demo_scaffold.dartwidgetbookCardTypeRegistry / widgetbookChartOverlayCardTypeRegistry from widgetbook/lib/widgetbook_card_registry.dartbuild() before early returns_queue… + mixin scheduleOverlayApply / runWhenCardReady (30-attempt retry)_lastApplied… dedupflutter_adaptive_cards_fs imports| Strategy | Use when | Example |
|---|---|---|
| Per-build queue | Cheap setText, string knobs | text_block_overlay_page.dart |
| Change-only sync | Heavy setFacts/clearFacts, dropdown presets | fact_set_overlay_page.dart |
| Page | GlobalKey | Host API | Target id | Lifecycle | Use case |
|---|---|---|---|---|---|
text_block_overlay_page.dart | textBlockOverlayPageKey | setText | bodyText | per-build | Text overlay (knob) |
fact_set_overlay_page.dart | factSetOverlayPageKey | setFacts / clearFacts | demoFactSet | change-only | Facts overlay (knob) |
Full columns (assets, knobs, spec links): see the doc registry table.
Follow Adding a new overlay demo in docs/widgetbook-overlay-demos.md. Minimum deliverables:
*_overlay_page.dart + sample JSON with element idGlobalKey## Summary
One paragraph per reviewed page (or one for a full audit): does `<page>.dart`
match shared patterns and its registry entry?
## Shared pattern compliance
| Page | GlobalKey | Queue/retry | Knobs before early return | Dedup | Imports | Use case + key |
| ---- | --------- | ----------- | ------------------------- | ----- | ------- | -------------- |
## Page-specific behavior
Per page: host API, target id, knob label(s), lifecycle strategy, baseline/clear semantics.
## vs sibling pages
Justify lifecycle differences (per-build queue vs change-only sync).
## Spec / plan alignment
Per page — only when registry lists doc paths; otherwise "checklist only."
## Registry hygiene
Missing rows for existing `*_overlay_page.dart` files, or rows with a wrong
GlobalKey, asset path, or use case name.
## Risk assessment
| Item | Risk | Notes |
| ---- | ---- | ----- |
## Verdict
- **Matches** — code aligns with doc + registry (+ spec/plan if applicable), or
- **Regression** — describe drift, or
- **Registry update needed** — new/changed page not reflected in docs.
Be precise: quote knob labels and API names exactly, reference file paths, and re-read live files before asserting state. Do not propose refactors unless the user asks to change implementation.