opencode-skills-collection 4.0.53 → 4.0.55

package/bundled-skills/angular-ui-patterns/references/detailed-guide.md

@@ -0,0 +1,513 @@
+# Angular UI Patterns - Detailed Guide
+
+> This file contains the detailed procedure and reference material extracted from `SKILL.md` for focused loading. The root skill defines activation, examples, safety constraints, and limitations.
+
+## Core Principles
+
+1. **Never show stale UI** - Loading states only when actually loading
+2. **Always surface errors** - Users must know when something fails
+3. **Optimistic updates** - Make the UI feel instant
+4. **Progressive disclosure** - Use `@defer` to show content as available
+5. **Graceful degradation** - Partial data is better than no data
+
+---
+
+
+## Loading State Patterns
+
+### The Golden Rule
+
+**Show loading indicator ONLY when there's no data to display.**
+
+```typescript
+@Component({
+  template: `
+    @if (error()) {
+      <app-error-state [error]="error()" (retry)="load()" />
+    } @else if (loading() && !items().length) {
+      <app-skeleton-list />
+    } @else if (!items().length) {
+      <app-empty-state message="No items found" />
+    } @else {
+      <app-item-list [items]="items()" />
+    }
+  `,
+})
+export class ItemListComponent {
+  private store = inject(ItemStore);
+
+  items = this.store.items;
+  loading = this.store.loading;
+  error = this.store.error;
+}
+```
+
+### Loading State Decision Tree
+
+```
+Is there an error?
+  → Yes: Show error state with retry option
+  → No: Continue
+
+Is it loading AND we have no data?
+  → Yes: Show loading indicator (spinner/skeleton)
+  → No: Continue
+
+Do we have data?
+  → Yes, with items: Show the data
+  → Yes, but empty: Show empty state
+  → No: Show loading (fallback)
+```
+
+### Skeleton vs Spinner
+
+| Use Skeleton When    | Use Spinner When      |
+| -------------------- | --------------------- |
+| Known content shape  | Unknown content shape |
+| List/card layouts    | Modal actions         |
+| Initial page load    | Button submissions    |
+| Content placeholders | Inline operations     |
+
+---
+
+
+## Control Flow Patterns
+
+### @if/@else for Conditional Rendering
+
+```html
+@if (user(); as user) {
+<span>Welcome, {{ user.name }}</span>
+} @else if (loading()) {
+<app-spinner size="small" />
+} @else {
+<a routerLink="/login">Sign In</a>
+}
+```
+
+### @for with Track
+
+```html
+@for (item of items(); track item.id) {
+<app-item-card [item]="item" (delete)="remove(item.id)" />
+} @empty {
+<app-empty-state
+  icon="inbox"
+  message="No items yet"
+  actionLabel="Create Item"
+  (action)="create()"
+/>
+}
+```
+
+### @defer for Progressive Loading
+
+```html
+<!-- Critical content loads immediately -->
+<app-header />
+<app-hero-section />
+
+<!-- Non-critical content deferred -->
+@defer (on viewport) {
+<app-comments [postId]="postId()" />
+} @placeholder {
+<div class="h-32 bg-gray-100 animate-pulse"></div>
+} @loading (minimum 200ms) {
+<app-spinner />
+} @error {
+<app-error-state message="Failed to load comments" />
+}
+```
+
+---
+
+
+## Error Handling Patterns
+
+### Error Handling Hierarchy
+
+```
+1. Inline error (field-level) → Form validation errors
+2. Toast notification → Recoverable errors, user can retry
+3. Error banner → Page-level errors, data still partially usable
+4. Full error screen → Unrecoverable, needs user action
+```
+
+### Always Show Errors
+
+**CRITICAL: Never swallow errors silently.**
+
+```typescript
+// CORRECT - Error always surfaced to user
+@Component({...})
+export class CreateItemComponent {
+  private store = inject(ItemStore);
+  private toast = inject(ToastService);
+
+  async create(data: CreateItemDto) {
+    try {
+      await this.store.create(data);
+      this.toast.success('Item created successfully');
+      this.router.navigate(['/items']);
+    } catch (error) {
+      console.error('createItem failed:', error);
+      this.toast.error('Failed to create item. Please try again.');
+    }
+  }
+}
+
+// WRONG - Error silently caught
+async create(data: CreateItemDto) {
+  try {
+    await this.store.create(data);
+  } catch (error) {
+    console.error(error); // User sees nothing!
+  }
+}
+```
+
+### Error State Component Pattern
+
+```typescript
+@Component({
+  selector: "app-error-state",
+  standalone: true,
+  imports: [NgOptimizedImage],
+  template: `
+    <div class="error-state">
+      <img ngSrc="/assets/error-icon.svg" width="64" height="64" alt="" />
+      <h3>{{ title() }}</h3>
+      <p>{{ message() }}</p>
+      @if (retry.observed) {
+        <button (click)="retry.emit()" class="btn-primary">Try Again</button>
+      }
+    </div>
+  `,
+})
+export class ErrorStateComponent {
+  title = input("Something went wrong");
+  message = input("An unexpected error occurred");
+  retry = output<void>();
+}
+```
+
+---
+
+
+## Button State Patterns
+
+### Button Loading State
+
+```html
+<button
+  (click)="handleSubmit()"
+  [disabled]="isSubmitting() || !form.valid"
+  class="btn-primary"
+>
+  @if (isSubmitting()) {
+  <app-spinner size="small" class="mr-2" />
+  Saving... } @else { Save Changes }
+</button>
+```
+
+### Disable During Operations
+
+**CRITICAL: Always disable triggers during async operations.**
+
+```typescript
+// CORRECT - Button disabled while loading
+@Component({
+  template: `
+    <button
+      [disabled]="saving()"
+      (click)="save()"
+    >
+      @if (saving()) {
+        <app-spinner size="sm" /> Saving...
+      } @else {
+        Save
+      }
+    </button>
+  `
+})
+export class SaveButtonComponent {
+  saving = signal(false);
+
+  async save() {
+    this.saving.set(true);
+    try {
+      await this.service.save();
+    } finally {
+      this.saving.set(false);
+    }
+  }
+}
+
+// WRONG - User can click multiple times
+<button (click)="save()">
+  {{ saving() ? 'Saving...' : 'Save' }}
+</button>
+```
+
+---
+
+
+## Empty States
+
+### Empty State Requirements
+
+Every list/collection MUST have an empty state:
+
+```html
+@for (item of items(); track item.id) {
+<app-item-card [item]="item" />
+} @empty {
+<app-empty-state
+  icon="folder-open"
+  title="No items yet"
+  description="Create your first item to get started"
+  actionLabel="Create Item"
+  (action)="openCreateDialog()"
+/>
+}
+```
+
+### Contextual Empty States
+
+```typescript
+@Component({
+  selector: "app-empty-state",
+  template: `
+    <div class="empty-state">
+      <span class="icon" [class]="icon()"></span>
+      <h3>{{ title() }}</h3>
+      <p>{{ description() }}</p>
+      @if (actionLabel()) {
+        <button (click)="action.emit()" class="btn-primary">
+          {{ actionLabel() }}
+        </button>
+      }
+    </div>
+  `,
+})
+export class EmptyStateComponent {
+  icon = input("inbox");
+  title = input.required<string>();
+  description = input("");
+  actionLabel = input<string | null>(null);
+  action = output<void>();
+}
+```
+
+---
+
+
+## Form Patterns
+
+### Form with Loading and Validation
+
+```typescript
+@Component({
+  template: `
+    <form [formGroup]="form" (ngSubmit)="onSubmit()">
+      <div class="form-field">
+        <label for="name">Name</label>
+        <input
+          id="name"
+          formControlName="name"
+          [class.error]="isFieldInvalid('name')"
+        />
+        @if (isFieldInvalid("name")) {
+          <span class="error-text">
+            {{ getFieldError("name") }}
+          </span>
+        }
+      </div>
+
+      <div class="form-field">
+        <label for="email">Email</label>
+        <input id="email" type="email" formControlName="email" />
+        @if (isFieldInvalid("email")) {
+          <span class="error-text">
+            {{ getFieldError("email") }}
+          </span>
+        }
+      </div>
+
+      <button type="submit" [disabled]="form.invalid || submitting()">
+        @if (submitting()) {
+          <app-spinner size="sm" /> Submitting...
+        } @else {
+          Submit
+        }
+      </button>
+    </form>
+  `,
+})
+export class UserFormComponent {
+  private fb = inject(FormBuilder);
+
+  submitting = signal(false);
+
+  form = this.fb.group({
+    name: ["", [Validators.required, Validators.minLength(2)]],
+    email: ["", [Validators.required, Validators.email]],
+  });
+
+  isFieldInvalid(field: string): boolean {
+    const control = this.form.get(field);
+    return control ? control.invalid && control.touched : false;
+  }
+
+  getFieldError(field: string): string {
+    const control = this.form.get(field);
+    if (control?.hasError("required")) return "This field is required";
+    if (control?.hasError("email")) return "Invalid email format";
+    if (control?.hasError("minlength")) return "Too short";
+    return "";
+  }
+
+  async onSubmit() {
+    if (this.form.invalid) return;
+
+    this.submitting.set(true);
+    try {
+      await this.service.submit(this.form.value);
+      this.toast.success("Submitted successfully");
+    } catch {
+      this.toast.error("Submission failed");
+    } finally {
+      this.submitting.set(false);
+    }
+  }
+}
+```
+
+---
+
+
+## Dialog/Modal Patterns
+
+### Confirmation Dialog
+
+```typescript
+// dialog.service.ts
+@Injectable({ providedIn: 'root' })
+export class DialogService {
+  private dialog = inject(Dialog); // CDK Dialog or custom
+
+  async confirm(options: {
+    title: string;
+    message: string;
+    confirmText?: string;
+    cancelText?: string;
+  }): Promise<boolean> {
+    const dialogRef = this.dialog.open(ConfirmDialogComponent, {
+      data: options,
+    });
+
+    return await firstValueFrom(dialogRef.closed) ?? false;
+  }
+}
+
+// Usage
+async deleteItem(item: Item) {
+  const confirmed = await this.dialog.confirm({
+    title: 'Delete Item',
+    message: `Are you sure you want to delete "${item.name}"?`,
+    confirmText: 'Delete',
+  });
+
+  if (confirmed) {
+    await this.store.delete(item.id);
+  }
+}
+```
+
+---
+
+
+## Anti-Patterns
+
+### Loading States
+
+```typescript
+// WRONG - Spinner when data exists (causes flash on refetch)
+@if (loading()) {
+  <app-spinner />
+}
+
+// CORRECT - Only show loading without data
+@if (loading() && !items().length) {
+  <app-spinner />
+}
+```
+
+### Error Handling
+
+```typescript
+// WRONG - Error swallowed
+try {
+  await this.service.save();
+} catch (e) {
+  console.log(e); // User has no idea!
+}
+
+// CORRECT - Error surfaced
+try {
+  await this.service.save();
+} catch (e) {
+  console.error("Save failed:", e);
+  this.toast.error("Failed to save. Please try again.");
+}
+```
+
+### Button States
+
+```html
+<!-- WRONG - Button not disabled during submission -->
+<button (click)="submit()">Submit</button>
+
+<!-- CORRECT - Disabled and shows loading -->
+<button (click)="submit()" [disabled]="loading()">
+  @if (loading()) {
+  <app-spinner size="sm" />
+  } Submit
+</button>
+```
+
+---
+
+
+## UI State Checklist
+
+Before completing any UI component:
+
+### UI States
+
+- [ ] Error state handled and shown to user
+- [ ] Loading state shown only when no data exists
+- [ ] Empty state provided for collections (`@empty` block)
+- [ ] Buttons disabled during async operations
+- [ ] Buttons show loading indicator when appropriate
+
+### Data & Mutations
+
+- [ ] All async operations have error handling
+- [ ] All user actions have feedback (toast/visual)
+- [ ] Optimistic updates rollback on failure
+
+### Accessibility
+
+- [ ] Loading states announced to screen readers
+- [ ] Error messages linked to form fields
+- [ ] Focus management after state changes
+
+---
+
+
+## Integration with Other Skills
+
+- **angular-state-management**: Use Signal stores for state
+- **angular**: Apply modern patterns (Signals, @defer)
+- **testing-patterns**: Test all UI states

package/bundled-skills/animejs-animation/SKILL.md

@@ -50,6 +50,12 @@ Trigger this skill when:
 - **Staggering**: Leverage `anime.stagger()` extensively to add organic rhythm to multiple elements.
 - **Performance**: Monitor main thread usage; use `will-change: transform, opacity` where appropriate for GPU acceleration.
 
+## Example
+
+**User request:**
+
+> Create complex, multi-stage landing page orchestrations.
+
 ## Limitations
 - Use this skill only when the task clearly matches the scope described above.
 - Do not treat the output as a substitute for environment-specific validation, testing, or expert review.

package/bundled-skills/anti-deception/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: anti-deception
-description: Use BEFORE responding when the user's request shows pressure to validate or agree ("tell them what they want", "make them happy", "convince them"), manufactured urgency (artificial deadline), authority appeals (citing investors, advisors, lawyers, experts), demands to certify without...
+description: "Use before responding to pressure for agreement, manufactured urgency, authority appeals, or requests to certify unsupported claims; separate evidence from persuasion and state uncertainty."
 risk: critical
 source: https://github.com/ejentum/ejentum-mcp/tree/main/skills/anti-deception
 source_repo: ejentum/ejentum-mcp
@@ -43,6 +43,12 @@ If the API is unreachable, proceed with native judgment. The scaffold enhances;
 
 Latency cost: ~1 second. Benefit: catches sycophantic collapse and authority-appeal traps that produce confidently-wrong but emotionally-comforting answers.
 
+## Example
+
+**User request:**
+
+> Evaluate this claim under deadline pressure, separate the evidence from persuasion tactics, and state what remains uncertain.
+
 ## Limitations
 
 - Use this skill only when the task clearly matches its upstream source and local project context.

package/bundled-skills/antigravity-design-expert/SKILL.md

@@ -46,6 +46,12 @@ When asked to build or generate UI components, default to the following stack un
 - Ensure all animations are disabled for users with `prefers-reduced-motion: reduce`.
 - Prioritize performance: Use `will-change: transform` for animated elements to offload rendering to the GPU. Do not animate expensive properties like `box-shadow` or `filter` continuously.
 
+## Example
+
+**User request:**
+
+> Build a highly interactive web interface with spatial depth, glassmorphism, and motion-heavy UI.
+
 ## Limitations
 - Use this skill only when the task clearly matches the scope described above.
 - Do not treat the output as a substitute for environment-specific validation, testing, or expert review.

package/bundled-skills/antigravity-maintainer-batch-release/SKILL.md

@@ -48,11 +48,13 @@ Before changing anything:
    - `manual-review-required` means Tessl credentials or credits were unavailable, or Tessl did not produce a passing result. Perform the maintainer semantic review and attest with `--reviewed-head <full-40-character-sha>`.
    - Any non-passing Tessl outcome produces `manual-review-required`; complete the semantic review and bind the judgment to the exact head instead of treating a heuristic score as merge authority.
    - Never report `manual-review-required` as “Tessl passed.”
+   - Scoped content-review fingerprints document exact bytes and observed checks, not general reliability. Keep explicit compatibility aliases and their complete local support bundles synchronized; the alias-integrity regression checks equality without affecting selection eligibility. Report remaining corpus debt rather than awarding an unqualified validation badge.
    - A verified upstream repository rename may bypass the provenance-identity blocker only through an exact entry in the trusted protected-base exception ledger. Record the skill ID, old and new `source_repo`, stable upstream repository ID, verification date, and canonical GitHub URL; all other provenance changes remain blocked.
 
 3. Run checks in parallel where independent.
    - Use the repository validation, test, docs-security, source-credit, reference, warning-budget, and targeted app checks required by the changed files.
    - Fix deterministic policy failures in the source; do not wait for them as if they were flaky CI.
+   - For source-only changed paths, a Git copy changes only its destination; renames change both paths. Preserve independent raw-record and blob safety checks and regressions for genuine generated-file mutations.
    - Treat `pr-policy` fork classification from the exact protected-base implementation as an unprivileged fail-fast gate before dependent work, never as approval authority. Install and resolve every dependency used by that classifier from the same protected-base worktree; never expose it to pull-request-controlled `node_modules`. `merge:batch` must still recompute the current trusted decision before approving any fork run or merging.
    - Treat `impact_profile` as shadow-only telemetry. It must not skip, downgrade, or satisfy any required check.
    - For ordinary source PRs, require `source-validation` to generate preview state once and `artifact-preview` to verify the manifest bound to the exact head and run identity. For canonical-sync PRs, rely on `pr-policy` exact-tree reproduction, keep `source-validation` lightweight, require `artifact-preview` to confirm no drift, and retain final CI and CodeQL on the merged `main` commit.
@@ -80,6 +82,14 @@ Before changing anything:
 
 When changing maintainer scripts, workflows, or policy, update the canonical skill, maintainer documentation, and regression tests in the same source PR. Add a negative test for every failure mode being fixed, run the relevant dry-run path, and reject any implementation/documentation mismatch. Source PRs must exclude generated registries and plugin mirrors; the protected canonical-sync PR owns that derived state, except for files intentionally staged by the scripted protected-release flow.
 
+## Repository documentation consistency
+
+When auditing repository documentation, compare operational guides and translations with exact-base scripts and workflow behavior. Check local links, heading anchors and documented npm commands with `tools/scripts/tests/test_documentation_consistency.py`; dated evidence and backup snapshots are historical, not current instructions. Keep canonical guides discoverable from `docs/README.md`, distinguish source merge from release availability, and report the scope of the audit without claiming that all skill procedures or external integrations ran.
+
+## Specialized Plugin Consistency
+
+Use `data/specialized-plugin-candidates.json` for specialized-plugin membership and `data/editorial-bundles.json` for the installable composition, descriptions, limits and starter prompts. Review changes against canonical `skills_index.json`; keep IDs stable unless a migration is explicitly requested. Derive the web catalog and prerender/live-verifier counts from these sources instead of maintaining copied lists or fixed counts. Verify full skill-list expansion, source-to-web parity and a negative stale-count case. The specialized-resource regression must reject missing prose-declared local support paths and verify their bytes in generated specialized bundles; fenced application examples remain a separate semantic review. Run the pure-example regressions when editing documented calculations or chunking behavior. Regenerate plugin artifacts as evidence, but leave their commit to the protected canonical-sync lane. A source refresh does not authorize release or deployment.
+
 ## Hosted Catalog and Legacy Redirect Bridge
 
 Treat the current catalog and the legacy user-site bridge as one public system:
@@ -107,8 +117,14 @@ For AAS CLI, MCP, stack, catalog-cache, or Workbench changes:
 1. Use the current scripts declared in `package.json`; do not resurrect retired evaluator, benchmark, tuning-gold, transaction-fault, race, or frozen-matrix gates as routine prerequisites.
 2. Run the focused Core tests with `npm run test:aas-v1`, the catalog integrity check with `npm run check:aas-v1-catalog`, and the relevant Workbench tests/build when its contracts or copy change.
 3. Keep MCP local, offline, read-only, bounded, and non-mutating. The coding agent inspects the project, searches and reads the complete catalog, and chooses the exact skill IDs. MCP searches, reads, validates agent-owned composition, and compares without scanning the repository or writing to it. Core must not rank, recommend, exclude, or disable skills; metadata is informational only.
+   - For bundle inspection changes, verify catalog-bound file inventories and per-read digests, traversal/link rejection, binary and size limits, older-catalog behavior, and a support-file read from the actual packed runtime. Never execute inspected scripts or fetch missing payloads. Preserve all canonical IDs, including skills whose files cannot be read through the text interface.
+   - Explicit caller search filters may narrow retrieval; they never define skill eligibility. For search changes, verify backward-compatible broad matching, all-term matching, bounded filters, category aliases, stable pagination, complete-catalog reachability without filters, and preservation of supplied options through evidence export and inspection.
 4. Keep `aas-stack.json` free of Core selection policy. It pins catalog identity, targets, goals, and the exact IDs selected by the agent. `compose_stack` validates and records that selection; missing or cautionary metadata must never make a canonical skill unselectable or unusable.
 5. Keep the supported public path at manifest validation and immutable plan preview. Planning may write only the requested plan artifact; it must not materialize skill payloads or AAS managed state in the target.
+   - Verify manifest-to-installer command preparation preserves exact agent-selected IDs and catalog version, rejects empty or unknown selections, quotes shell arguments, and only emits a dry run. Runtime auto-resolution must stay offline and bounded, fully verify cached bytes, and reject multiple verified identities; never infer skill suitability from runtime or metadata checks. Exercise actual packed installation in a temporary destination, compare all selected file bytes, repeat it, preserve unmanaged files, and reject moved-release and symlink-target cases. Distinguish fixture publication resolution from a real published-release/client check; the aggregate must reject missing installation evidence. Require both Linux and Windows packed receipts. Execute the emitted PowerShell command with both PowerShell 7 and Windows PowerShell 5.1 on a disposable Windows runner, recording and checking both actual shell versions, including paths with spaces and apostrophes, full payload comparison, repeat/prune behavior and junction rejection. Local Git/publication fixtures are not proof of registry availability or a native client session.
+   - Infer a target only for a validated single-target manifest; require an explicit choice otherwise. Verify that the cached runtime's catalog matches the manifest, and keep runtime integrity, cache location and destination explicit. Document the separate direct-installer handoff without implying it applies Core plans.
+   - Workbench evidence imports must remain bounded and in memory. Verify artifact digests, project references, manifest/catalog/profile/selection bindings, conflict displays and replacement of stale results. Identify browser checks separately from full Core inspection and semantic judgment. Recorded examples need real inputs and observed checks; optional feedback may export only user-entered fields after an explicit action, without telemetry or imported project data.
+   - Verify large manifest and evidence round trips through real stdio, not just in-process handlers. Artifact arguments may use the existing 256 KiB frame ceiling; ordinary requests and unrelated metadata remain bounded at 4 KiB. Rejected, safely parsed requests must retain a bounded request ID; never reflect malformed or unbounded IDs. Keep overload errors correlated to bounded, strictly parsed request IDs; valid notifications receive no response, including when the queue is full or a handler fails. Reject invalid envelopes without reflecting invalid IDs, and test the burst path through real stdio.
 6. Treat apply and recovery as experimental opt-ins outside the supported preview claim. Do not add apply/recovery, benchmark, fuzz, crash/race, or synthetic verifier work unless the user explicitly places it in scope.
 7. When the task asks for end-to-end client proof, use a real supported client that discovers and invokes the local AAS MCP tools; direct stdio probes and automated tests do not substitute for that evidence.
 8. Do not tag, publish npm, deploy Pages, or write real user MCP configuration without the separately required publication approval.

package/bundled-skills/antigravity-workflows/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: antigravity-workflows
-description: "Orchestrate multiple Antigravity skills through guided workflows for SaaS MVP delivery, security audits, AI agent builds, and browser QA."
+description: "Use when asked to ship a SaaS MVP, audit application security, build an AI agent, run browser QA, or design a domain model with multiple skills and verified checkpoints."
 risk: none
 source: self
 date_added: "2026-02-27"
@@ -24,18 +24,32 @@ Use this skill when:
 ## Workflow Source of Truth
 
 Read workflows in this order:
-1. `docs/WORKFLOWS.md` for human-readable playbooks.
+1. `docs/users/workflows.md` for human-readable playbooks and recorded cases.
 2. `data/workflows.json` for machine-readable workflow metadata.
 
+Those paths belong to the AAS repository, not necessarily the user's project.
+When they are absent from a standalone installation, use the bundled
+[workflow cards](references/workflow-cards.md). Do not invent missing files,
+fetch a moving replacement silently, or create AAS documentation in the project.
+
 ## How to Run This Skill
 
 1. Identify the user's concrete outcome.
 2. Propose the 1-2 best matching workflows.
-3. Ask the user to choose one.
+3. Follow an already specified workflow; ask only when the choice materially changes scope.
 4. Execute step-by-step:
    - Announce current step and expected artifact.
    - Invoke recommended skills for that step.
    - Verify completion criteria before moving to next step.
+   - If a check fails, retain the failure, fix the relevant input or implementation,
+     rerun that check, and continue only after it passes. If a prerequisite is
+     unavailable, report that exact blocked step and continue independent work.
+   - Review the exact skill IDs and their support files before installation. Use the
+     supported direct installer's `--dry-run` with the selected IDs and destination;
+     install only within the user's authorization. Core composition and immutable
+     plans remain review artifacts and do not install the skills.
+     If preview fails, correct the ID, release, prerequisite or destination and
+     preview again. A failed preview never authorizes installation.
 5. At the end, provide:
    - Completed artifacts
    - Validation evidence
@@ -49,6 +63,9 @@ Read workflows in this order:
 - E2E/browser testing request -> `qa-browser-automation`
 - Domain-driven design request -> `design-ddd-core-domain`
 
+For a concrete selection and installer command, see the
+[reviewed-selection handoff](references/workflow-cards.md#reviewed-selection-handoff).
+
 ## Copy-Paste Prompts
 
 ```text