@mmerterden/multi-agent-pipeline 8.6.1 → 10.0.6

package/pipeline/skills/figma-common/figma-fix/SKILL.md

@@ -1,4 +1,9 @@
-# /figma-fix — Fix a Review Bug
+---
+name: figma-fix
+description: Applies a targeted fix for a bug filed during component review (via `/figma-review`), re-runs affected pipeline phases, closes the bug sub-issue, and cleanly transitions the parent component back to In Review with a.
+---
+
+# /figma-fix  -  Fix a Review Bug
 
 ## Purpose
 
@@ -10,8 +15,8 @@ This skill fills the gap between `/figma-review` (which *files* bugs) and `/figm
 
 | Parameter | Required | Description |
 |-----------|----------|-------------|
-| Bug issue number | Yes (one of) | `#123` — the bug sub-issue filed by a reviewer |
-| Parent issue number | Alternative | `#100` — the parent component issue (lists open bugs to pick from) |
+| Bug issue number | Yes (one of) | `#123`  -  the bug sub-issue filed by a reviewer |
+| Parent issue number | Alternative | `#100`  -  the parent component issue (lists open bugs to pick from) |
 | Figma URL | Alternative | Resolves to the component, then lists open bugs |
 
 ```
@@ -56,7 +61,7 @@ gh issue list --repo ${GH_REPO} --search "parent:#<M> label:review-fix state:ope
 ```
 
 2. If multiple bugs: present them and ask which to fix (or fix all sequentially).
-3. If zero bugs: HALT — "No open bugs on this component."
+3. If zero bugs: HALT  -  "No open bugs on this component."
 
 ### If Figma URL provided:
 
@@ -89,7 +94,7 @@ Extract: `componentName`, `suggestedComponentLocation`, `suggestedArtifactPath`.
 
 3. Read the Figma design (if MCP available) or FIGMA.md variant mapping to understand the correct behavior.
 
-4. Identify the fix — what code needs to change.
+4. Identify the fix  -  what code needs to change.
 
 ---
 
@@ -98,7 +103,7 @@ Extract: `componentName`, `suggestedComponentLocation`, `suggestedArtifactPath`.
 Edit the component source files to fix the bug. This is a **surgical edit**, not a full re-implementation.
 
 Rules:
-- Only edit files that need changing — don't rewrite the entire component
+- Only edit files that need changing  -  don't rewrite the entire component
 - Follow existing code patterns (tokens, modifiers, configuration style)
 - If the fix requires new assets/tokens, use `/common-utility assets add-color` or `/common-utility assets generate`
 - If the fix requires new testing identifiers/localization/accessibility keys, use `/common-utility identifiers add` / `localization add` / `accessibility add`
@@ -201,7 +206,7 @@ python3 .instructions/figma/figma-to-swiftui/scripts/phase6-finalize.py \
 
 ```bash
 gh issue close <bug_number> --repo ${GH_REPO} \
-    --comment "Fixed in $(git log -1 --format='%h') — $(git log -1 --format='%s')"
+    --comment "Fixed in $(git log -1 --format='%h')  -  $(git log -1 --format='%s')"
 ```
 
 ### 7b. Check remaining open bugs on parent
@@ -255,16 +260,16 @@ The commit message references the bug issue number so GitHub auto-links it.
 ```
 [ ] Bug sub-issue identified and read
 [ ] Component source files read
-[ ] Fix applied — only changed files that needed changing
+[ ] Fix applied  -  only changed files that needed changing
 [ ] xcodebuild build passed (exit 0)
-[ ] phase4-finalize.py ran — implementation version bumped
+[ ] phase4-finalize.py ran  -  implementation version bumped
 [ ] Tests re-run and passing (ViewInspector + Snapshot)
-[ ] phase5-finalize.py ran — tested flag green
-[ ] Code Connect checked — .figma.swift updated if needed
-[ ] phase6-finalize.py ran — codeConnect flag green
+[ ] phase5-finalize.py ran  -  tested flag green
+[ ] Code Connect checked  -  .figma.swift updated if needed
+[ ] phase6-finalize.py ran  -  codeConnect flag green
 [ ] Bug sub-issue closed with fix commit reference
 [ ] review-fix label removed from parent (if last bug)
-[ ] update-issue-from-registry.py ran — parent synced to board
+[ ] update-issue-from-registry.py ran  -  parent synced to board
 [ ] Parent status column: In Review (not Bugfix)
 [ ] Parent review progress: 0/4 (fresh cycle)
 ```
@@ -274,11 +279,11 @@ The commit message references the bug issue number so GitHub auto-links it.
 ## Success Output
 
 ```
-Bug fix complete: {ComponentName} — #{bug_number}
+Bug fix complete: {ComponentName}  -  #{bug_number}
 
 | Field | Value |
 |-------|-------|
-| Bug | #{bug_number} — {bug_title} |
+| Bug | #{bug_number}  -  {bug_title} |
 | Component | {ComponentName} |
 | Fix commit | {commit_hash} |
 | Implementation version | {new_version} (bumped from {old_version}) |
@@ -295,22 +300,22 @@ Next: Reviewers can re-review the component at #{parent_number}.
 
 | Error | Action |
 |-------|--------|
-| Issue is not a bug (no review-fix/bug label) | HALT — not a bug issue |
-| No parent issue | HALT — orphan bug, can't resolve component |
-| Component not found via registry | HALT — check node-id |
+| Issue is not a bug (no review-fix/bug label) | HALT  -  not a bug issue |
+| No parent issue | HALT  -  orphan bug, can't resolve component |
+| Component not found via registry | HALT  -  check node-id |
 | Build fails after fix | Show errors, iterate |
 | Tests fail after fix | Show failures, update tests |
 | Bug close fails | Show error, ask user to close manually |
-| review-fix label removal blocked | Non-fatal — sync will still work via sub-issue count |
-| Sync fails | Non-fatal — finalize scripts already updated registry |
+| review-fix label removal blocked | Non-fatal  -  sync will still work via sub-issue count |
+| Sync fails | Non-fatal  -  finalize scripts already updated registry |
 
 ---
 
 ## Notes
 
-- This skill is **surgical** — it fixes one specific bug, not a full re-implementation
+- This skill is **surgical**  -  it fixes one specific bug, not a full re-implementation
 - It always bumps `implemented.version` (Phase 4 finalize) because the code changed
 - The version bump automatically makes the old review count stale, forcing a fresh review cycle
 - Multiple bugs on the same component: run `/figma-fix` once per bug, or pass the parent issue to batch
-- The `--no-sync` flag on Gates 4-6 prevents 3 redundant sync calls — Gate 7d does a single authoritative sync
+- The `--no-sync` flag on Gates 4-6 prevents 3 redundant sync calls  -  Gate 7d does a single authoritative sync
 - Works hand-in-hand with `/figma-review` (which creates bugs) and `/figma-iteration-commit` (which commits)

package/pipeline/skills/figma-common/figma-form-integration/SKILL.md

@@ -1,13 +1,13 @@
 ---
 name: figma-form-integration
-description: "Form pattern integration for Figma-to-SwiftUI components. Guides FormSection/FormField adoption — when a component embeds form-capable sub-components (Selectbox, Checkbox, Radio, TextboxTextarea, DatepickerSchedule, ButtonsInputStepper) this skill defines how to model them as FormField references inside a nested FormSection, owned by the caller."
+description: "Form pattern integration for Figma-to-SwiftUI components. Guides FormSection/FormField adoption  -  when a component embeds form-capable sub-components (Selectbox, Checkbox, Radio, TextboxTextarea, DatepickerSchedule, ButtonsInputStepper) this skill defines how to model them as FormField references inside a nested FormSection, owned by the caller."
 user-invocable: true
 allowed-tools: Read, Glob, Grep
 status: wip-v5
 sourced-from: upstream/figma-form-integration
 ---
 
-# /figma-form-integration — Form Pattern Integration
+# /figma-form-integration  -  Form Pattern Integration
 
 ## Purpose
 
@@ -33,13 +33,13 @@ This is the forms counterpart of `/figma-price-integration`. Same shape: a proto
 
 4. **Configuration holds form references, not values.** No `amount: String`, no `selectedOption: Option`, no `isChecked: Bool` next to a form input. If a value travels through the API, it travels through its `FormField`.
 
-5. **Section belongs in Configuration, not View — if a Configuration exists.** When the component has a Configuration struct (COMPLEX), the `FormSection` property MUST live on Configuration. Only components with NO Configuration may accept a `FormField` directly as a View init parameter.
+5. **Section belongs in Configuration, not View  -  if a Configuration exists.** When the component has a Configuration struct (COMPLEX), the `FormSection` property MUST live on Configuration. Only components with NO Configuration may accept a `FormField` directly as a View init parameter.
 
-6. **Static content (labels, placeholders, helper text, toggle captions) stays in Configuration — not on the field.** Fields are pure form state: value, rules, policy, options, loading. Labels and copy are visual/content — they go on Configuration (chainable via `@GenerateChainModifiers`).
+6. **Static content (labels, placeholders, helper text, toggle captions) stays in Configuration  -  not on the field.** Fields are pure form state: value, rules, policy, options, loading. Labels and copy are visual/content  -  they go on Configuration (chainable via `@GenerateChainModifiers`).
 
 7. **The nested `FormSection` mirrors the design exactly.** Declare ONLY the fields the component actually renders. Do not add fields the design doesn't use; do not drop fields the design does use. The section's shape is dictated by the design, not by developer convenience or a shared/generic form model.
 
-8. **Non-form actions ("Sil", "Detaylar", "Edit") stay as paired closures on the View.** They are NOT fields, NOT Configuration values — they are View dependencies passed via paired modifiers, exactly like any other coexistent action (see Phase 3D §2.3.1).
+8. **Non-form actions ("Sil", "Detaylar", "Edit") stay as paired closures on the View.** They are NOT fields, NOT Configuration values  -  they are View dependencies passed via paired modifiers, exactly like any other coexistent action (see Phase 3D section2.3.1).
 
 9. **Validation and focus are caller concerns.** The component never exposes an `isValid` property, never owns a `FormFocus`, never calls `validate()` internally. The scene calls `section.validate()` (or `[section].validateAll(focus:)`) and sets `.formFocus(...)` at the scene root.
 
@@ -49,7 +49,7 @@ This is the forms counterpart of `/figma-price-integration`. Same shape: a proto
 
 Invoke when ANY of these are detected:
 
-1. **Phase 3D — Sub-Component Integration (§2.2):** A nested instance of a form-capable design-system component:
+1. **Phase 3D  -  Sub-Component Integration (section2.2):** A nested instance of a form-capable design-system component:
    - `Selectbox` (single-select dropdown)
    - `Checkbox` / `CheckboxButton`
    - `Radio` / `RadioButton`
@@ -57,13 +57,13 @@ Invoke when ANY of these are detected:
    - `DatepickerSchedule` (date / date-range input)
    - `ButtonsInputStepper` (numeric +/- counter, e.g. passenger / quantity selectors)
    - Any component whose Figma variants include an input state (empty/filled/error/disabled) with a user-driven value
-2. **Phase 4A — Configuration:** A property group contains form-input fields.
-3. **Phase 4B — View:** The view renders form controls that require user input with validation semantics.
+2. **Phase 4A  -  Configuration:** A property group contains form-input fields.
+3. **Phase 4B  -  View:** The view renders form controls that require user input with validation semantics.
 
 **Counting rule (atomic vs composite):**
-- **0 embedded form sub-components** — no form pattern; skip this skill.
-- **1 embedded form sub-component** — atomic form: the Configuration (or View init) takes ONE `*FormField` directly, no `FormSection` wrapper.
-- **2+ embedded form sub-components** — composite form: nested `FormSection` class in Configuration bundling every field.
+- **0 embedded form sub-components**  -  no form pattern; skip this skill.
+- **1 embedded form sub-component**  -  atomic form: the Configuration (or View init) takes ONE `*FormField` directly, no `FormSection` wrapper.
+- **2+ embedded form sub-components**  -  composite form: nested `FormSection` class in Configuration bundling every field.
 
 ---
 
@@ -94,7 +94,7 @@ Atomic form views (Checkbox, Radio, Selectbox, InputField, DatePicker)
 | File | Location | Purpose |
 |------|----------|---------|
 | `FormSection.swift` | `CoreUI/Components/Forms/Foundation/` | Protocol + default aggregate `validate` / `evaluate` / `clear` / `state` semantics |
-| `FormGroup.swift` | `CoreUI/Components/Forms/Foundation/` | Concrete everyday `FormSection` — use for ad-hoc grouping when a named type isn't worth it |
+| `FormGroup.swift` | `CoreUI/Components/Forms/Foundation/` | Concrete everyday `FormSection`  -  use for ad-hoc grouping when a named type isn't worth it |
 | `FormField.swift` | `CoreUI/Components/Forms/Foundation/` | Generic base: `value`, `state`, `rules`, `validationPolicy` |
 | `Validatable.swift` | `CoreUI/Components/Forms/Foundation/` | Non-generic protocol; `[any Validatable].validateAll(focus:)` + `leafFields` |
 | `FormFocus.swift` | `CoreUI/Components/Forms/Foundation/` | `.formFocus(focus)` environment, `focus.focusFirstError()` |
@@ -114,13 +114,13 @@ public protocol FormSection: Validatable {
 }
 ```
 
-Default aggregate implementations are provided by a protocol extension: `validate()` runs every child (no short-circuit — all inline errors update), rolls the first error into the section's own `state`; `clear()` resets everything to `.pristine`. Identical semantics to `FormGroup`.
+Default aggregate implementations are provided by a protocol extension: `validate()` runs every child (no short-circuit  -  all inline errors update), rolls the first error into the section's own `state`; `clear()` resets everything to `.pristine`. Identical semantics to `FormGroup`.
 
 ### @FormSection macro
 
 Attached to an `@Observable` class, synthesizes:
 - `public var state: FormState = .pristine`
-- `public var children: [any Validatable]` — auto-detected from stored properties whose type matches `*FormField`, `*FormSection`, `FormGroup`, or is marked `@FormChild`.
+- `public var children: [any Validatable]`  -  auto-detected from stored properties whose type matches `*FormField`, `*FormSection`, `FormGroup`, or is marked `@FormChild`.
 
 Supports `T?`, `[T]`, `[T]?` transparently. Plain data properties (`String`, `URL`, `Int`) are ignored.
 
@@ -128,7 +128,7 @@ Supports `T?`, `[T]`, `[T]?` transparently. Plain data properties (`String`, `UR
 
 ## How to Create a Component-Specific Section
 
-**Rule: each COMPOSITE form component defines its own nested `.Section` class conforming to `FormSection`.** The nested section exposes ONLY the fields that component accepts — no silent discard.
+**Rule: each COMPOSITE form component defines its own nested `.Section` class conforming to `FormSection`.** The nested section exposes ONLY the fields that component accepts  -  no silent discard.
 
 ### Step 1: Inventory the Embedded Form Sub-Components
 
@@ -180,9 +180,9 @@ extension PNRContactCard {
 }
 ```
 
-> **`@unchecked Sendable` on the nested `Section`**: nested `Section` classes MUST conform to `@unchecked Sendable` so they can be stored on a `Sendable` Configuration (compiler cannot verify a mutable reference type as Sendable, but @Observable's MainActor scheduling makes it safe in practice). All concrete sections in the codebase use this pattern (see `MilesSmilesMilesMissingMiles.Section`, `AvailabilityFilter.Section`).
+> **`@unchecked Sendable` on the nested `Section`**: nested `Section` classes MUST conform to `@unchecked Sendable` so they can be stored on a `Sendable` Configuration (compiler cannot verify a mutable reference type as Sendable, but @Observable's MainActor scheduling makes it safe in practice). All concrete sections in the codebase use this pattern (see `FrequentFlyerProgramMissingPoints.Section`, `MyFilterSection.Section`).
 
-**If the component has NO Configuration (SIMPLE, 0–1 field):** skip the `Section` and take the `FormField` directly on the View init.
+**If the component has NO Configuration (SIMPLE, 0-1 field):** skip the `Section` and take the `FormField` directly on the View init.
 
 ```swift
 public struct TermsCheckbox: View {
@@ -205,7 +205,7 @@ public struct PNRContactCardConfiguration: Sendable {
     public let avatarURL: URL?
     public let deleteLinkTitle: String?             // "Sil" (paired action's label)
 
-    // Per-field labels / placeholders — static copy, NOT on the field
+    // Per-field labels / placeholders  -  static copy, NOT on the field
     public let emailLabel: String                   // "E-Posta"
     public let emailPlaceholder: String             // "E-Postanızı giriniz"
     public let phoneLabel: String                   // "Telefon Numarası"
@@ -352,9 +352,9 @@ struct EInvoiceSceneView: View {
 
 ## Integration with Phase 3D
 
-When Phase 3D's Sub-Component Integration (§2.2) detects a form-capable instance:
+When Phase 3D's Sub-Component Integration (section2.2) detects a form-capable instance:
 
-### Replace / augment §2.2 Output
+### Replace / augment section2.2 Output
 
 Instead of treating a Selectbox/Checkbox/Radio/TextboxTextarea/DatepickerSchedule instance as a mini-config struct of its dynamic props, recognize it as a **form input** and emit a `FormField` reference.
 
@@ -367,10 +367,10 @@ In the Sub-Components section:
 
 | Element | Scope | Integration |
 |---------|-------|-------------|
-| Email input (TextboxTextarea) | Required | `FormField` — `email: TextFormField` in nested `Section` |
-| Phone country (Selectbox) | Required | `FormField` — `phoneCountry: PickerFormField<CountryCode>` |
-| Phone number (TextboxTextarea) | Required | `FormField` — `phoneNumber: TextFormField` |
-| Primary toggle (Checkbox)   | Required | `FormField` — `isPrimary: CheckboxFormField` (rendered as Switch) |
+| Email input (TextboxTextarea) | Required | `FormField`  -  `email: TextFormField` in nested `Section` |
+| Phone country (Selectbox) | Required | `FormField`  -  `phoneCountry: PickerFormField<CountryCode>` |
+| Phone number (TextboxTextarea) | Required | `FormField`  -  `phoneNumber: TextFormField` |
+| Primary toggle (Checkbox)   | Required | `FormField`  -  `isPrimary: CheckboxFormField` (rendered as Switch) |
 ```
 
 In the Final API Design:
@@ -405,7 +405,7 @@ public struct ComponentNameConfiguration: Sendable {
 
 ### Layer-text + form interaction
 
-Dynamic layer text INSIDE a form control (e.g. the placeholder text inside a Selectbox) is still **static copy** from the caller's perspective — it becomes a Configuration string (`placeholder`, `label`), NOT a FormField-value substitute. Form fields own the *value*, not the *copy*.
+Dynamic layer text INSIDE a form control (e.g. the placeholder text inside a Selectbox) is still **static copy** from the caller's perspective  -  it becomes a Configuration string (`placeholder`, `label`), NOT a FormField-value substitute. Form fields own the *value*, not the *copy*.
 
 ---
 
@@ -414,11 +414,11 @@ Dynamic layer text INSIDE a form control (e.g. the placeholder text inside a Sel
 When writing the Configuration struct for a component with form fields:
 
 1. Define the nested `Section: FormSection` class in an extension on the component namespace, annotated `@FormSection @Observable`.
-2. Only include the fields identified in Phase 3D analysis — one FormField subclass per form sub-component.
+2. Only include the fields identified in Phase 3D analysis  -  one FormField subclass per form sub-component.
 3. The `section` property on Configuration is non-optional when the form is required, optional when the whole form block is boolean-gated.
-4. Do NOT flatten field values into the Configuration — keep them inside the section.
+4. Do NOT flatten field values into the Configuration  -  keep them inside the section.
 5. Static content (labels, placeholders, helper copy, toggle labels) stays in Configuration as `String` / `String?` and gets chainable modifiers via `@GenerateChainModifiers`.
-6. Paired action closures (`onDelete`, `onEdit`, row-level disclosure) stay as View init parameters — NOT in Configuration, NOT on fields.
+6. Paired action closures (`onDelete`, `onEdit`, row-level disclosure) stay as View init parameters  -  NOT in Configuration, NOT on fields.
 
 ---
 
@@ -457,11 +457,11 @@ public struct ComponentName: View {
 
 ### Rules
 
-- **Never** use `@State` for form values. Never wrap `section.<field>.value` in `Binding(get:set:)` — pass the field itself.
+- **Never** use `@State` for form values. Never wrap `section.<field>.value` in `Binding(get:set:)`  -  pass the field itself.
 - **Never** call `section.validate()` from inside the View. Validation is a caller concern.
 - **Never** instantiate a `FormField` or `Section` inside the component. They come from the caller via Configuration.
 - **Do** read `section.state` to render section-level banners/errors if the design shows one.
-- **Do** use atomic form views (`InputField(field:)`, `Selectbox(field:)`, `Radio(field:)`, `Checkbox(field:)`, `DatePicker(field:)`) — they handle `field.state` → visual state internally.
+- **Do** use atomic form views (`InputField(field:)`, `Selectbox(field:)`, `Radio(field:)`, `Checkbox(field:)`, `DatePicker(field:)`)  -  they handle `field.state` → visual state internally.
 
 ---
 
@@ -483,10 +483,10 @@ public struct ComponentName: View {
 
 ## When NOT to Use Form Integration
 
-- **Pure display components** showing data that is not user-editable — use plain `String` / `Int` / model properties.
-- **Static checkmarks / indicators** that are read-only state (e.g., a green tick in a stepper) — use `Bool` in Configuration, not `CheckboxFormField`.
-- **Radio-like selection that is display only** (e.g., a highlighted selected tab in a segmented control where selection is controlled by the parent, not a form submission) — use an `enum` property, not `RadioFormField`.
-- **Segmented controls that represent navigation / filter state, not form input** — plain `Binding<Enum>` is fine for those; they are not validated or submitted.
+- **Pure display components** showing data that is not user-editable  -  use plain `String` / `Int` / model properties.
+- **Static checkmarks / indicators** that are read-only state (e.g., a green tick in a stepper)  -  use `Bool` in Configuration, not `CheckboxFormField`.
+- **Radio-like selection that is display only** (e.g., a highlighted selected tab in a segmented control where selection is controlled by the parent, not a form submission)  -  use an `enum` property, not `RadioFormField`.
+- **Segmented controls that represent navigation / filter state, not form input**  -  plain `Binding<Enum>` is fine for those; they are not validated or submitted.
 
 Rule of thumb: ask "would a ViewModel run `validate()` on this value before submitting?" If no → it's not a form field.
 
@@ -518,14 +518,14 @@ Prefer a named `FormSection` subclass when the card has a stable identity in the
 | Search form with free-text + date range + pax count selectbox | Nested `Section` with 3 fields |
 | E-invoice form (passenger radio + N contact cards) | Scene `FormGroup([passengerRadio] + contacts.map { $0 })` |
 | Password change (old + new + confirm) | Nested `Section` with 3 `TextFormField`s + cross-field `MatchRule` |
-| Toggle inside a card (no other inputs, dedicated) | `ToggleFormField` directly on Configuration (atomic, no Section) — preferred when the design uses `TurkishToggle` |
-| Toggle inside a card (no other inputs, unified) | `CheckboxFormField` directly on Configuration (atomic, no Section) — only when toggle and checkbox are interchangeable in the same form |
+| Toggle inside a card (no other inputs, dedicated) | `ToggleFormField` directly on Configuration (atomic, no Section)  -  preferred when the design uses `TurkishToggle` |
+| Toggle inside a card (no other inputs, unified) | `CheckboxFormField` directly on Configuration (atomic, no Section)  -  only when toggle and checkbox are interchangeable in the same form |
 | Passenger picker (N stepper rows + disclosure expansion) | Nested `Section` with N `StepperFormField`s + a plain `displayState` enum property (named to avoid colliding with the `state: FormState` synthesized by `@FormSection`) |
 | Filter panel (1 toggle + N multi-select chip groups) | Nested `Section` with 1 `ToggleFormField` + N `CheckboxGroupFormField<Item>` (one per group). Section conforms to `@unchecked Sendable`. See `AvailabilityFilter` for the canonical example. |
 
 ---
 
-## Checklist — Before Leaving the Skill
+## Checklist  -  Before Leaving the Skill
 
 ```
 [ ] Counted form-capable sub-components in the Figma design
@@ -537,6 +537,6 @@ Prefer a named `FormSection` subclass when the card has a stable identity in the
 [ ] Non-form actions (Sil/Edit/Detaylar) are paired closures on the View
 [ ] View uses @Bindable on the section; never @State for values
 [ ] View never calls validate() or instantiates fields
-[ ] No Binding<Value> anywhere in the component — only field references
+[ ] No Binding<Value> anywhere in the component  -  only field references
 [ ] Scene-level caller builds the section, calls validate() / leafFields / focus
 ```

package/pipeline/skills/figma-common/figma-issue/SKILL.md

@@ -1,4 +1,9 @@
-# /figma-issue — GitHub Issue Manager for Figma Components
+---
+name: figma-issue
+description: Creates and manages GitHub Issues for Figma component implementations.
+---
+
+# /figma-issue  -  GitHub Issue Manager for Figma Components
 
 ## Purpose
 
@@ -96,16 +101,16 @@ Map the registry `pageName` to the project board's Figma Page option. Use substr
 
 ## Command: `open <url>[,<url>,...]`
 
-### STEP 0 — Parse Input
+### STEP 0  -  Parse Input
 
 1. Extract all Figma URLs from `$ARGUMENTS` (comma-separated or space-separated).
 2. For each URL, extract `node-id` query parameter. Keep as-is (e.g., `2251-15872`).
-3. Deduplicate by `node-id` — if the same node-id appears multiple times, process it only once.
+3. Deduplicate by `node-id`  -  if the same node-id appears multiple times, process it only once.
 4. Print: "Found N unique Figma component(s) to process."
 
 **For each component, run STEPs 1-6 sequentially.** The specs prompt (STEP 2.5) is asked once per component.
 
-### STEP 1 — Registry Lookup
+### STEP 1  -  Registry Lookup
 
 ```bash
 cd ${REPO_ROOT}/{repos.common.path}
@@ -121,7 +126,7 @@ Collect from JSON output:
 
 If lookup fails, mark as **unregistered**.
 
-### STEP 1.5 — Dependency Detection
+### STEP 1.5  -  Dependency Detection
 
 Uses the **exact same algorithm** as `confluence-component-status-upload.py` → `readiness()`:
 1. Build unified `name → nodeId` lookup from catalog + registry + graph
@@ -200,7 +205,7 @@ else:
     for sname in sub_names:
         sub_nid = name_to_nid.get(sname)
         if not sub_nid:
-            # Unresolved — not in any registry/catalog (same as all_comps.get() → None → not a blocker)
+            # Unresolved  -  not in any registry/catalog (same as all_comps.get() → None → not a blocker)
             results.append({'name': sname, 'nodeId': None, 'status': 'unresolved'})
             continue
         sc = components.get(sub_nid)
@@ -243,7 +248,7 @@ else:
 "
 ```
 
-Parse the JSON output. Only `not_implemented` entries are blockers — `implemented`, `skipped`, and `unresolved` (not in any registry) are NOT blockers.
+Parse the JSON output. Only `not_implemented` entries are blockers  -  `implemented`, `skipped`, and `unresolved` (not in any registry) are NOT blockers.
 
 **Readiness precedence (architecture-update):**
 1. `status.ios.implemented.value` (new canonical field, set by `phase4-finalize.py`)
@@ -263,7 +268,7 @@ gh issue list --repo ${GH_REPO} --state open --label component \
   --search "<SubComponentName>" --json number,title --jq '.[0]'
 ```
 
-Collect: `BLOCKING_DEPS` = list of `{name, nodeId, issueNumber (or null)}` — only `not_implemented` entries.
+Collect: `BLOCKING_DEPS` = list of `{name, nodeId, issueNumber (or null)}`  -  only `not_implemented` entries.
 
 #### 1.5c. Report
 
@@ -282,16 +287,16 @@ If zero `not_implemented` → **no blockers**, do NOT auto-block.
 
 Store `BLOCKING_DEPS` for use in STEP 3.5.
 
-### STEP 2 — Duplicate Check
+### STEP 2  -  Duplicate Check
 
 ```bash
 gh issue list --repo ${GH_REPO} --state open --search "node-id=<NODE_ID>" --json number,title,url
 ```
 
 If a match is found, print warning and stop:
-"Issue already exists: #N — <title> (<url>)"
+"Issue already exists: #N  -  <title> (<url>)"
 
-### STEP 2.5 — Specs & Acceptance Criteria
+### STEP 2.5  -  Specs & Acceptance Criteria
 
 Present the component info and **STOP. Do not proceed to STEP 3.** Wait for the user's next message.
 
@@ -319,11 +324,11 @@ Type "skip" to create without specs.
 
 When the user responds:
 - If the response is `skip` (case-insensitive): set `SPECS = ""`, proceed to STEP 3.
-- Otherwise: the user's message is the specs input. You MAY read referenced files to gather context and understand the user's intent better — this helps write clearer specs. Then rewrite the user's input into clean, actionable acceptance criteria (checkbox list) that another AI can easily follow when it fetches this issue for implementation. Do NOT implement anything — this skill only creates issues, not code. Then proceed to team selection / STEP 3.
+- Otherwise: the user's message is the specs input. You MAY read referenced files to gather context and understand the user's intent better  -  this helps write clearer specs. Then rewrite the user's input into clean, actionable acceptance criteria (checkbox list) that another AI can easily follow when it fetches this issue for implementation. Do NOT implement anything  -  this skill only creates issues, not code. Then proceed to team selection / STEP 3.
 
 If `SPECS` is not empty, include it in the issue body under `### Acceptance Criteria` (see STEP 3 body template).
 
-### STEP 3 — Create GitHub Issue
+### STEP 3  -  Create GitHub Issue
 
 **Title:**
 ```
@@ -342,7 +347,7 @@ Where `<TEAM_SHORT>` is mapped from the team label:
 
 If unregistered: `feat: <TEAM_SHORT> Implement component (node-id: <NODE_ID>)`
 
-**Body** — must match the issue template field headers exactly:
+**Body**  -  must match the issue template field headers exactly:
 
 ```markdown
 ### Figma URL
@@ -380,9 +385,9 @@ _No response_
 
 <!--
 State legend:
-  🟢 green  — flag is set and validated against the current implementation version
-  🟡 yellow — flag was validated against an older impl version (or Figma moved ahead, for implemented)
-  ⚪ gray   — flag is not set
+  🟢 green   -  flag is set and validated against the current implementation version
+  🟡 yellow  -  flag was validated against an older impl version (or Figma moved ahead, for implemented)
+  ⚪ gray    -  flag is not set
 
 The Progress table is rewritten automatically by update-issue-from-registry.py
 on every phase finalize. Do not hand-edit this section; edits will be
@@ -443,7 +448,7 @@ gh issue create \
 (`impl:green`, `impl:yellow`, `test:green`, etc.) are applied
 automatically by `update-issue-from-registry.py` once a phase finalize
 script has populated `status` in the registry. On creation the issue
-has zero flag labels (all gray) — that's the correct initial state for
+has zero flag labels (all gray)  -  that's the correct initial state for
 a component nobody has implemented yet.
 
 Legacy `phase:*` labels are stripped from existing issues on any sync;
@@ -451,7 +456,7 @@ new issues never get them.
 
 Capture the issue number and URL from the output.
 
-### STEP 3.5 — Auto-Block (if dependencies detected)
+### STEP 3.5  -  Auto-Block (if dependencies detected)
 
 If `BLOCKING_DEPS` from STEP 1.5 has any `not_implemented` sub-components:
 
@@ -462,7 +467,7 @@ gh issue edit <N> --repo ${GH_REPO} --add-label "blocked"
 
 2. Comment with blocking info:
 ```bash
-gh issue comment <N> --repo ${GH_REPO} --body "**Auto-blocked** — unimplemented sub-components (from sub-component-graph.json):
+gh issue comment <N> --repo ${GH_REPO} --body "**Auto-blocked**  -  unimplemented sub-components (from sub-component-graph.json):
 - <SubName> → #M
 - <SubName> → no issue
 
@@ -471,7 +476,7 @@ Will be auto-unblocked when all dependencies are implemented."
 
 The issue will be auto-unblocked by `/figma-iteration-commit` STEP 5 when blocking components get implemented.
 
-### STEP 4 — Add to Project Board
+### STEP 4  -  Add to Project Board
 
 #### 4a. Add issue to project
 
@@ -503,7 +508,7 @@ Map `pageName` using the Figma Page Mapping table, then:
 gh api graphql -f query='mutation { updateProjectV2ItemFieldValue(input: { projectId: "{github.projectV2Id}", itemId: "'"$ITEM_ID"'", fieldId: "{github.projectV2Fields.figmaPage}", value: { singleSelectOptionId: "<MAPPED_PAGE_OPTION_ID>" } }) { projectV2Item { id } } }'
 ```
 
-### STEP 5 — Summary
+### STEP 5  -  Summary
 
 Print:
 
@@ -527,13 +532,13 @@ Issue created:
 
 Assign the issue to the current GitHub user. If a Jira task is linked, also assign it.
 
-### STEP 1 — Assign GitHub Issue
+### STEP 1  -  Assign GitHub Issue
 
 ```bash
 gh issue edit <N> --repo ${GH_REPO} --add-assignee @me
 ```
 
-### STEP 2 — Assign Jira (if linked)
+### STEP 2  -  Assign Jira (if linked)
 
 Read the issue body and check the `### Jira Issue` section for a linked key.
 
@@ -560,7 +565,7 @@ Print: "Issue #N assigned to you." (+ "Jira <KEY> assigned." if applicable)
 
 Link an existing Jira task to the GitHub issue (both directions).
 
-### STEP 1 — Update GitHub Issue Body
+### STEP 1  -  Update GitHub Issue Body
 
 1. Read current issue body:
 ```bash
@@ -579,7 +584,7 @@ BODY=$(gh issue view <N> --repo ${GH_REPO} --json body --jq '.body')
 gh issue edit <N> --repo ${GH_REPO} --body "<UPDATED_BODY>"
 ```
 
-### STEP 2 — Update Project Board Jira Field
+### STEP 2  -  Update Project Board Jira Field
 
 ```bash
 # Get item ID from project
@@ -589,7 +594,7 @@ ITEM_ID=$(gh api graphql -f query='{ node(id: "{github.projectV2Id}") { ... on P
 gh api graphql -f query='mutation { updateProjectV2ItemFieldValue(input: { projectId: "{github.projectV2Id}", itemId: "'"$ITEM_ID"'", fieldId: "{github.projectV2Fields.jira}", value: { text: "<JIRA_KEY>" } }) { projectV2Item { id } } }'
 ```
 
-### STEP 3 — Update Jira Description with GitHub Link
+### STEP 3  -  Update Jira Description with GitHub Link
 
 ```bash
 JIRA_TOKEN=$("$HOME/.claude/lib/credential-store.sh" get \1 2>/dev/null)
@@ -613,12 +618,12 @@ Print: "Issue #N linked to [JIRA_KEY]({jira.baseUrl}/browse/JIRA_KEY)"
 
 ---
 
-## Command: `phase <#N> <phase>` — **DEPRECATED**
+## Command: `phase <#N> <phase>`  -  **DEPRECATED**
 
 This command is deprecated as of the architecture-update. Phase state
 is now tracked per-flag in the component registry
 (`status.ios.{implemented,tested,codeConnect,wiki}`), not as a single
-enum. The `phase:*` labels are no longer used — they're replaced by
+enum. The `phase:*` labels are no longer used  -  they're replaced by
 per-flag `impl:green`/`impl:yellow`/`test:green`/etc. labels, which are
 applied automatically by `update-issue-from-registry.py` after every
 phase finalize script writes the registry.
@@ -709,7 +714,7 @@ Print: "Issue #N closed."
 
 ## Command: `status [#N]`
 
-### With issue number — show single issue
+### With issue number  -  show single issue
 
 ```bash
 gh issue view <N> --repo ${GH_REPO} --json number,title,state,assignees,labels,body
@@ -722,7 +727,7 @@ gh api graphql -f query='{ node(id: "{github.projectV2Id}") { ... on ProjectV2 {
 
 Print a formatted summary with issue details + board fields.
 
-### Without issue number — list all open
+### Without issue number  -  list all open
 
 ```bash
 gh issue list --repo ${GH_REPO} --state open --label component --json number,title,assignees --jq '.[] | "| #\(.number) | \(.title) | \(.assignees | map(.login) | join(", ")) |"'
@@ -737,9 +742,9 @@ Print as a table.
 - **FigmaRegistryUtility not built**: Run `cd ${REPO_ROOT}/{repos.common.path} && swift build --product FigmaRegistryUtility`.
 - **Issue not found**: Print error and stop.
 - **Invalid phase**: Print valid options: `implementation`, `testing`, `code-connect`, `documentation`.
-- **Duplicate issue**: Print existing issue link and stop — do not create.
+- **Duplicate issue**: Print existing issue link and stop  -  do not create.
 - **GraphQL errors**: Print the error message from the API response.
 - **Jira token not found**: Prompt user to add to keychain: `"$HOME/.claude/lib/credential-store.sh" set \1 \"\2\"`.
-- **Jira API error (401/403)**: Token expired or invalid — prompt user to update keychain.
-- **Jira API error (404)**: Wrong issue key — print error and continue.
+- **Jira API error (401/403)**: Token expired or invalid  -  prompt user to update keychain.
+- **Jira API error (404)**: Wrong issue key  -  print error and continue.
 - **Jira VPN not reachable**: Print warning, skip Jira steps, continue with GitHub-only operations.