figma-requirements-extraction

name	figma-requirements-extraction
description	Extract requirements and design-system evidence from a Figma file (screens, components, states, exact copy, form fields, interaction flows, design token evidence, accessibility hints) and write to docs/requirements/design-extracted/<figma-file-id>-<ISO-date>.md as additional source corpus for BA synthesis + srs-source-validator coverage check. Use when a PRD references Figma URLs and Design-Flow: A is in effect — runs PRE-BA so BA's first US/FR pass and Design-Guideline selection are informed by what the design already specifies. Strictly read-only against Figma (consumer pattern); strictly inferred-vs-confirmed discipline (no invention).
agents	["ui-ux-designer"]
sdlc_phase	ingestion
owner	Platform Eng
status	active

Figma Requirements Extraction

When to use

You are the UI/UX Designer dispatched in extract mode. The Orchestrator has detected a Figma URL in the project's PRD source AND set SRS header Design-Flow: A (per BA Phase 1.X step 10) AND no docs/requirements/design-extracted/<figma-file-id>-*.md exists yet on disk.

The kit's pattern is: BA's first US/FR synthesis at Phase 1.X must be informed by FULL source corpus. Textual PRD + design-extracted requirements + conversational additions are the three branches. Without design-extracted input, BA invents details that Figma already specifies (or worse, misses details Figma specifies that the textual PRD omits) — every subsequent dispatch then re-discovers the gap.

You produce a structured markdown enumerating WHAT THE DESIGN SHOWS. You do NOT author requirements (that's BA's role); you produce evidence that BA synthesizes into the SRS. When the Figma file has no explicit design guideline, you still extract reusable visual-system evidence — color palette, typography, spacing, radius, elevation, component patterns, and layout grid — so BA can set Design-Guideline: from-figma instead of forcing a generic preset. This token extraction is unconditional for every Figma-backed project: formal variables/styles are preferred, but absence of a design guideline is not a reason to skip token evidence.

Inputs and outputs

• Inputs: Figma file URL passed by Orchestrator dispatch; Figma MCP server (read-only).
• Outputs: docs/requirements/design-extracted/<figma-file-id>-<ISO-date>.md (the one and only artifact this skill produces). The file includes both requirements evidence and a design-guideline evidence inventory for Flow A.
• Consumed by: BA Phase 1.X (synthesis input); srs-source-validator (coverage check spans this file as part of docs/requirements/).

Hard discipline: confirmed vs inferred

The extractor enumerates two distinct categories:

• CONFIRMED elements — text the extractor reads directly from Figma text nodes; components that are instances of named master components; states that exist as Figma variants; explicit copy on buttons / labels / dialogs. These are facts on the canvas.
• INFERRED requirements — behaviors / rules / scope items the extractor THINKS the design implies but cannot prove without PRD anchor. Example: a "confirm" modal with a destructive action button is INFERRED to mean "destructive operations require confirmation," but the extractor cannot prove this is a global rule vs incidental to this one flow.

The output file ALWAYS separates the two. BA at Phase 1.X synthesizes US/FR ONLY from confirmed elements + inferred items the textual PRD also supports. Inferred-only items become OQs (per BA's no-invention invariant).

This is the same discipline as solution-defaults skill (kit-provided defaults vs project-confirmed values) and brownfield Mode E (extracted vs confirmed).

Procedure

Step 0 — Pre-flight + page-scoping

1. Read the dispatch prompt: confirm figma_url is present and Design-Flow: A per SRS header.

2. Compute the output filename: <figma-file-id>-<YYYY-MM-DD>.md where <figma-file-id> is parsed from the Figma URL (the segment after /file/ or /design/).

3. Verify no design-extracted file already exists for this file-id+date. If one exists from today's date for the SAME file-id, halt with NEEDS_CONTEXT — the dispatch is redundant; the Orchestrator should reuse the existing file unless re-extraction is explicitly requested (e.g., the Figma version changed).

4. Read the Figma file's version ID via MCP. Capture it for the output header.

5. Resolve Figma-Design-Page-Node-ID — the root of all enumeration. Read SRS §3.4.1 header field Figma-Design-Page-Node-ID paired with this URL. A Figma file has MULTIPLE pages (top-level tabs); the project's design lives on ONE specific page. Without page-scoping, this extraction would walk every page (brainstorms, old designs, Foundation page, etc.) and either grab irrelevant frames OR miss the project design.

   Three sub-cases:

   • The captured value is a PAGE node (Figma MCP: query node type → CANVAS / PAGE) → use it directly as the root. Proceed to Step 1.
   • The captured value is a FRAME or SECTION node (the PM deep-linked to a specific frame they wanted to highlight) → walk UP the tree via Figma MCP's parent-pointer until you reach a CANVAS / PAGE node. Record the resolution in the extract output's ## Page-scope resolution section. Update SRS §3.4.1 Figma-Design-Page-Node-ID to the resolved page node (you have write access to this single field; do NOT touch other SRS content).
   • The captured value is a PAGE NAME (string, not Node ID) — BA at Phase 1.X step 10 wrote the operator's answer as a name (e.g., "Project Design") rather than an ID. Resolve by querying Figma MCP for pages in the file, finding the one with matching name (case-insensitive, trimmed), and recording its Node ID. Update SRS §3.4.1 with the resolved ID. If no page matches by name → halt with NEEDS_CONTEXT asking the operator to choose from the list of actual page names in the file.

6. The root of all enumeration in Steps 1-7 below is the resolved page node. Walk only its subtree. Frames on OTHER pages are NOT enumerated (they are out of scope for the project's design).

Step 1 — Enumerate screens (frames)

Walk every top-level frame under the resolved page node only. For each frame:

• Capture: frame name, Node ID, page name, dimensions, position on page.
• Identify variants: if the frame is part of a component-set, list all variants by name.
• Infer purpose from name (e.g., "RepositoryList/Default" → purpose: browse repositories; state: default).
• Identify states from variants and from frames with same base-name + state suffix (e.g., "RepositoryList/Empty", "RepositoryList/Loading", "RepositoryList/Error").

Step 2 — Enumerate components per screen

For each frame, walk every nested instance:

• Capture: component master name, instance name, testID (if data-testid set in any node), position within frame, visible properties (label text, icon, state variant).
• Group by type: buttons, inputs, cards, modals, navs, list items, toasts, etc.
• For interactive components: note interaction targets (Figma Prototype connections) — these reveal flows.

For each screen, also record the visual composition needed to distinguish it from a merely similar screen:

• frame viewport and clip behavior;
• direct-child layer order (back to front), including absolute-positioned layers;
• each direct child's frame-relative x/y/width/height, Auto Layout participation, alignment, padding/gap, constraints, and responsive behavior;
• overlays, masks, blend modes, opacity, corner clipping, and image-fill scale/crop settings;
• whether a visible layer is content, branded artwork, decorative-but-required composition, or a non-rendered design annotation.

Do not treat a screenshot as a substitute for this structure. The screenshot is corroborating evidence; node identity and composition properties remain the machine-readable contract.

Step 2a — Enumerate visual assets

Walk every visible node with an image fill, vector/network, boolean vector, SVG-like geometry, video/poster, logo/brand mark, icon, illustration, texture, or background artwork. Record:

• owning frame/state and Figma Node ID;
• semantic class: logo, brand-mark, icon.semantic, icon.decorative, illustration, photo, avatar, texture, background-image, or video-poster;
• source kind: image fill, vector, component instance, external/library instance, or generated shape;
• intrinsic dimensions and rendered bounds;
• crop/fill/fit/tile mode, focal point or transform when available, opacity, blend mode, mask/clip relationship, corner radius, and z-order;
• exportability and required export format/scale (SVG for vectors when faithful; PNG/WebP/JPEG and 1x/2x/3x as platform-appropriate for raster content);
• accessibility intent: meaningful with required alt/label, decorative with empty semantics, or unknown;
• library/component provenance and unresolved-access status.

A visible logo, graphic, image fill, or background image is never silently discardable. If the asset cannot be read or exported, record a blocking gap rather than replacing it with text, emoji, a generic icon, a gradient, or a placeholder.

Step 3 — Enumerate exact copy

Walk every text node in every frame:

• Capture the EXACT text (no normalization, no rephrasing). Preserve locale if multi-language frames exist.
• Group by element role: page titles, section headings, button labels, helper text, error messages, placeholder text, empty-state copy, confirmation-dialog copy, toast text.
• Flag template-style copy (e.g., "Show {count} repositories") — these become parameterized strings BA must specify in the FR.

Step 4 — Enumerate form fields

For every form-shaped frame (input + label + helper pattern):

• Per field: label text, placeholder, default value, validation hints visible in Figma (e.g., red border on RepoNameInput/Error variant), error message text, required-marker visibility.
• Per form: submit button label, submit button states (default / loading / disabled), validation timing (on-blur vs on-submit if inferable from interactions).

Step 5 — Enumerate interaction flows

Walk Figma Prototype connections (the connector arrows between frames). For each:

• Source frame + interaction (click button X) → destination frame + transition style.
• Build a list of flows: "Login → Dashboard" / "Repository List → Repository Detail (drill-in)" / etc.
• Flag flows with no explicit destination in Figma as gaps.

Step 6 — Extract design token evidence

Build a confirmed visual-system inventory from the scoped page. Prefer formal Figma variables/styles/components when present; otherwise infer only from repeated values in the scoped frames. Do not create or modify Figma styles in this mode.

For each category, capture the source of truth, observed values, usage locations, confidence, and whether the value is formal or inferred:

• Color palette
  • First read Figma Variables and local/shared color styles attached to scoped nodes.
  • If no formal styles exist, sample fills, strokes, text colors, and gradients across frames; normalize solid colors to hex or rgba with opacity; group repeated values.
  • Classify by usage where evidence supports it: surface, text, border, accent, state-success, state-warning, state-error, disabled, overlay.
  • Record contrast-relevant pairs when visible: text color + immediate background.
• Typography
  • Read text styles when present.
  • Otherwise group text nodes by font family, font size, weight, line height, paragraph spacing, and role inferred from position/name (heading, body, label, caption, button).
  • Preserve exact numeric values; do not "fix" them into a scale.
• Spacing and layout rhythm
  • Read Auto Layout padding, itemSpacing, layout grids, column/gutter settings, and frame constraints.
  • Infer common spacing values from repeated x/y gaps only when the same value appears across multiple frames/components.
  • Identify likely baseline unit (4px, 8px, or unknown) from the greatest common repeated spacing pattern.
• Border radius
  • Capture per-corner radius values from frames, rectangles, buttons, inputs, cards, modals, chips, and avatars.
  • Group repeated values and classify by component role when clear.
• Elevation and effects
  • Capture shadow/effect styles when present; otherwise list repeated effect signatures (offset, blur, spread, color, opacity).
• Component pattern evidence
  • Inventory named component masters/instances and repeated component-like groups (buttons, inputs, cards, nav, modals, badges, tabs, menus).
  • Note variant/state coverage visible in Figma.
• Layout grid / breakpoints
  • Capture frame sizes, platform hints, columns, gutters, margins, and responsive constraints if present.
  • If only frame sizes exist, list them as observed viewport targets, not as declared breakpoints.

Set a design-guideline recommendation in the output:

• Candidate Design-Guideline: from-figma when either:
  • formal Figma styles/variables/components exist for at least colors plus typography, or
  • inferred repeated values cover colors plus at least two of typography, spacing, radius, or component patterns.
• Candidate Design-Guideline: needs-human-choice when evidence is too sparse, inconsistent, or decorative-only.

Confidence rules:

• High — formal styles/variables/components exist and are used by most scoped screens.
• Medium — no formal styles, but repeated values are consistent across multiple screens/components.
• Low — one-off values, too few frames, or conflicting palettes/scales.

Step 7 — Enumerate accessibility hints

When the design carries explicit a11y metadata:

• Focus order if numbered on the canvas.
• ARIA semantics in component descriptions.
• Color contrast pairs annotated in Figma (some designers note "AA-compliant" on swatches).
• Touch-target sizes for mobile-bridge surfaces.

Empty when design doesn't specify (most projects don't).

Step 8 — Write the design-extracted file

Open docs/requirements/design-extracted/<figma-file-id>-<YYYY-MM-DD>.md. Use the structure below (template: confirmed-first, inferred-last). Except for the required Candidate Design-Guideline field derived from Step 6 evidence, do not include opinion or recommendation — enumerate what the design contains.

# Design-extracted requirements — <figma-file-name>

- **Figma-File-URL:** <url>
- **Figma-File-ID:** <id>
- **Figma-File-Version:** <version-id-at-extraction>
- **Figma-Design-Page-Node-ID:** <page-node-id resolved at Step 0>
- **Figma-Design-Page-Name:** <human-readable page name as it appears in Figma>
- **Extracted-by:** ui-ux-designer (extract mode)
- **Extracted-at:** <ISO-8601>
- **Designer (per Figma metadata):** <name if available, else "(not surfaced in file metadata)">
- **Total frames:** <N>
- **Total pages:** <N>

## Provenance

This file is one of three branches of the `docs/requirements/` source corpus that BA reads at Phase 1.X synthesis. The other two are top-level PM-authored files and `conversational-additions/` (BA Mode D Step D0 captures). The srs-source-validator's coverage check spans ALL three branches.

This file contains CONFIRMED elements (Sections 1–7 below) and INFERRED requirements (Section 8 below). BA at Phase 1.X synthesizes US/FR only from confirmed elements + inferred items the textual PRD also supports. BA uses Section 6 to set `Design-Guideline:` when Flow A provides enough design-system evidence. Inferred-only items must become OQs per BA's no-invention invariant.

## Section 1 — Screens (frames)

| Frame name | Node ID | Page | Purpose | States detected |
|---|---|---|---|---|
| RepositoryList/Default | 530:2 | Repositories | List view | default, loading, empty, error |
| RepositoryList/SelectedRow | 530:14 | Repositories | List with selection | with-selection (1+ rows checked) |
| ConfirmDialog/Hide | 533:2 | Repositories | Destructive action confirm | open, closing |

## Section 2 — Components per screen

### RepositoryList/Default (530:2)
- Per-row checkbox (testID: `rep-row-checkbox-<id>`) — states: default / checked / disabled. Touch target 24×24.
- Select-all checkbox (testID: `rep-select-all-checkbox`) — states: unchecked / mixed / all.
- Search input (testID: `rep-search`) — placeholder: "Search repositories…".
- Filter chips (testIDs: `rep-filter-region`, `rep-filter-status`) — 4 chip variants visible (Active, Hidden, Pending, Archived).
- Batch action bar (testID: `rep-batch-bar`) — sticky-bottom, visible when ≥1 row checked. Contains: "Show selected" button, "Hide selected" button, selection-count indicator.

(Repeat per screen.)

## Section 2A — Visual composition and asset evidence

### Frame composition

| Frame / State | Node ID | Viewport | Clip | Direct-child order (back → front) | Layout/constraint evidence |
|---|---|---|---|---|---|
| Login / Default | 120:1 | 1440×900 | yes | background artwork → scrim → form panel → logo | background absolute/fill; panel x=840 y=120 w=480 h=660; right constrained |

### Visual assets

| Frame / State | Node ID | Class | Source kind | Intrinsic / rendered bounds | Fit/crop/mask/z-order | Required export | Accessibility | Status |
|---|---|---|---|---|---|---|---|---|
| Login / Default | 120:4 | background-image | image fill | 2400×1600 / 1440×900 | fill; focal 32% 50%; clipped; back | WebP 1x/2x | decorative | exportable |
| Login / Default | 120:18 | logo | vector instance | vector / 156×40 | contain; front | SVG | meaningful: product logo | exportable |

## Section 3 — Exact copy

| Element | Text | Locale | Notes |
|---|---|---|---|
| Page title (RepositoryList) | "Repository Visibility Admin" | en | h1 |
| Search placeholder | "Search repositories…" | en | input.placeholder |
| Empty state heading (RepositoryList/Empty) | "No repositories yet" | en | empty state |
| Empty state body | "Connect your first repository to get started" | en | empty state |
| Batch button — Show | "Show selected" | en | primary action |
| Batch button — Hide | "Hide selected" | en | destructive action |
| Confirm dialog title | "Show {count} repositories?" | en | PARAMETERIZED — `count` must be supplied by FR |
| Confirm dialog body | "{count} repositories will become publicly visible." | en | PARAMETERIZED |
| Confirm dialog button — primary | "Show" | en | primary |
| Confirm dialog button — secondary | "Cancel" | en | secondary |
| Completion toast | "{count} repositories updated" | en | PARAMETERIZED |

## Section 4 — Form fields

(Per form: label, placeholder, validation rules visible in Figma, error message text, default values. Empty if no forms in the file.)

## Section 5 — Interaction flows

| Flow | Source | Trigger | Destination | Notes |
|---|---|---|---|---|
| Browse → Detail | RepositoryList/Default | click row | RepositoryDetail/Default | drill-in |
| Batch Hide flow | RepositoryList/SelectedRow | click "Hide selected" | ConfirmDialog/Hide | open modal |
| Batch Hide confirm | ConfirmDialog/Hide | click "Show" | RepositoryList/Default | close modal + toast |
| Batch Hide cancel | ConfirmDialog/Hide | click "Cancel" | RepositoryList/SelectedRow | close modal, preserve selection |

## Section 6 — Design guideline extraction (Flow A)

- **Formal design system present:** <yes | partial | no>
- **Candidate Design-Guideline:** <from-figma | needs-human-choice>
- **Confidence:** <high | medium | low>
- **Evidence basis:** <formal styles/variables/components | repeated inferred values | sparse/ambiguous>
- **Foundation recommendation:** <Use extracted Figma evidence as Foundation source | ask operator to choose preset | use `none` only with explicit opt-out>

### Color palette evidence

| Token candidate | Value | Role evidence | Source | Usage count | Confidence |
|---|---|---|---|---:|---|
| surface-default | #FFFFFF | Frame backgrounds | inferred from 12 frames | 12 | medium |
| text-primary | #111827 | Body/title text | inferred from text nodes | 87 | medium |
| accent-brand | #2563EB | Primary buttons + active nav | Figma color style `Brand/Blue/600` | 24 | high |
| state-error | #DC2626 | Error text + destructive buttons | inferred repeated value | 6 | medium |

### Typography evidence

| Token candidate | Family | Size | Weight | Line height | Role evidence | Source | Confidence |
|---|---|---:|---:|---:|---|---|---|
| heading-lg | Inter | 32 | 700 | 40 | Page titles | text style `Heading/Large` | high |
| body-md | Inter | 16 | 400 | 24 | Body text | repeated text nodes | medium |
| label-md | Inter | 14 | 600 | 20 | Buttons + labels | repeated text nodes | medium |

### Spacing and layout rhythm evidence

| Value | Token candidate | Evidence | Usage count | Confidence |
|---:|---|---|---:|---|
| 8px | space-2 | Button icon gap, form label gap | 18 | medium |
| 16px | space-4 | Card padding, list item gap | 42 | medium |
| 24px | space-5 | Section gap | 16 | medium |

- **Likely baseline unit:** <4px | 8px | unknown>
- **Layout grid:** <columns/gutters/margins if present; otherwise observed frame sizes>

### Radius evidence

| Value | Token candidate | Evidence | Usage count | Confidence |
|---:|---|---|---:|---|
| 8px | radius-md | Buttons, inputs, cards | 38 | medium |
| 9999px | radius-full | Pills, avatars | 9 | medium |

### Elevation/effect evidence

| Token candidate | Effect signature | Evidence | Usage count | Confidence |
|---|---|---|---:|---|
| elevation-sm | y=1 blur=2 color=#000000 opacity=0.08 | Cards | 12 | medium |

### Component pattern evidence

| Component candidate | Formal component? | Variants/states observed | Notes |
|---|---|---|---|
| Button | yes | primary, secondary, destructive; default, disabled, loading | Instance names use `Button/*` |
| Input | partial | default, focused, error | Some inputs are standalone groups |
| Card | no | default, selected | Repeated group pattern, no master component |

### Design guideline gaps

- <List missing token categories, inconsistent scales, sparse evidence, or formal-style gaps BA/UIUX must account for. Empty if none.>

## Section 7 — Accessibility hints

(Focus order, ARIA semantics, contrast annotations, touch-target sizes. Empty when design doesn't specify.)

## Section 8 — Inferred requirements (proposed; require PRD anchor or OQ)

Items the extractor infers from the design but cannot confirm. BA decides per Phase 1.X gap-handling: anchor to textual PRD OR file as OQ. Do NOT synthesize US/FR from this section without anchor.

- **Inferred (selection state):** Selection persists across pagination — inferred from the "with-selection" state appearing on RepositoryList/Default-pagination-2. No textual confirmation of persistence rule.
- **Inferred (destructive confirmation):** All destructive bulk actions require modal confirmation — inferred from ConfirmDialog/Hide existing for batch-hide. Cannot confirm "all destructive" vs "this one only" without PRD.
- **Inferred (max batch size):** No max-count UI element visible — design may imply unlimited OR may rely on backend enforcement. PRD must confirm.
- **Inferred (toast timing):** Completion toast auto-dismisses — duration not visible in Figma (no timeline annotation).
- **Inferred (locale support):** Only en copy in this file — VN / TH / TW locale support unknown.

## Section 9 — Gaps observed

Items the extractor expected to find but didn't. These become OQs for BA to surface during synthesis:

- No design for `RepositoryList/Error` variant with specific error code (only generic error state)
- No design for offline / network-unavailable state
- No design for the "Hide selected" success path when some rows fail (partial success state)
- No accessibility annotations visible on the canvas (focus order, ARIA labels not surfaced)
- No design for mobile-bridge layout (< 480px viewport) — adaptive behavior unclear

Step 9 — Commit

Commit the file with conventional-commits convention (feat(requirements): extract design requirements from <figma-file-name>). Reference any task ID if the dispatch carried one.

Hard Rules

• READ-ONLY against Figma. This skill uses Figma MCP in consumer mode only. No frame edits, no comment additions, no version changes.
• NO INVENTION. Sections 1–7 contain ONLY what the canvas literally shows or repeated visual values/effects/components observed on scoped nodes. Section 8 contains inferred requirements but explicitly flags them as proposals BA must anchor or OQ. Empty sections stay empty (do not fabricate sample data).
• TOKEN EXTRACTION IS MANDATORY FOR FIGMA LINKS. Every Figma extraction must produce Section 6 design token evidence, even when the Figma file has no named design guideline, no Foundation page, and no formal variables/styles. In that case, capture repeated observed values with confidence and source locations; do not leave Section 6 empty unless the scoped page contains no usable visual evidence.
• DESIGN GUIDELINE EXTRACTION IS EVIDENCE, NOT AUTHORING. You may recommend from-figma from observed evidence, but you do not create the Foundation page, rename styles, normalize values, or invent missing token categories in extract mode.
• VERBATIM COPY. Section 3 captures text exactly as it appears — no normalization, no fixing typos, no spelling corrections, no translation. The audit-log value depends on faithfulness.
• VISIBLE ASSETS ARE REQUIREMENTS EVIDENCE. Record every logo, graphic, illustration, image fill, texture, and background image in Section 2A with its node provenance and rendering properties. decorative controls semantics, not whether the layer is rendered.
• PARAMETERIZED STRINGS marked clearly. When copy contains {placeholders}, flag as PARAMETERIZED so BA's FR specifies the parameter source.
• One file per dispatch. If the Figma file is large enough that the extraction produces a >5000-line single file, split by Figma page into multiple files: <figma-id>-<date>-<page-slug>.md. The Orchestrator's BA dispatch reads the full directory; multiple files are fine.
• No SRS-side writes except page-scope resolution. This skill writes to docs/requirements/design-extracted/. The only allowed SRS update is the page-scope field update delegated to ui-ux-page-scoping when a frame/section/name must be resolved to a page Node ID. It does NOT touch SRS body content, docs/user-stories/, docs/frs/, or any role-owned doc that BA / SA / QA-Author own.
• The output is source corpus, not authored requirements. BA at Phase 1.X is the synthesis authority. Your output is INPUT to BA's authoring, in the same way PM's textual PRD is input.

Edge cases

• Figma file inaccessible / version mismatch: halt with NEEDS_CONTEXT. Do not produce a partial extraction; the audit-log value depends on completeness.
• Empty Figma file (canvas blank or trivial): produce the output file with all sections marked "(no content extracted)" + a note in Section 9 stating "Figma file appears not yet designed." BA's Phase 1.X synthesis then treats this branch as informational-only.
• Multi-version Figma file: extract from the file's HEAD version only. If PRD references a specific version-id different from HEAD, halt with NEEDS_CONTEXT asking which to extract.
• Permission restricted: if MCP can't read the file (private, restricted), halt with NEEDS_CONTEXT requesting access.

References

• Workflow contract: CLAUDE.md
• Source corpus discipline: CLAUDE.md §1
• BA synthesis authority: .claude/agents/_templates/ba.md § Phase 1.X
• srs-source-validator (consumer at sign-off): .claude/agents/_templates/srs-source-validator.md
• Design-Flow A detection: .claude/agents/_templates/ba.md § Phase 1.X step 10
• Sibling skill (Figma-SRS mapping after BA): .claude/skills/figma-srs-mapping/SKILL.md
• Sibling skill (Foundation authoring): .claude/skills/design-system-author/SKILL.md