القائمة
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.