@mmerterden/multi-agent-pipeline 11.2.0 → 11.3.1

package/pipeline/skills/figma-common/performance-review-next/SKILL.md

@@ -1,238 +0,0 @@
----
-name: performance-review-next
-description: Reads `_tour_tracker.json`, presents a dashboard of produced components, and guides the user through reviewing each one. Fix commits are separate. Halted components can be retried or dropped.
----
-
-# /performance-review-next  -  Interactive Component Review Session
-
-> Reads `_tour_tracker.json`, presents a dashboard of produced components,
-> and guides the user through reviewing each one. Fix commits are separate.
-> Halted components can be retried or dropped.
-
-## Parameters
-
-| Parameter | Required | Default | Description |
-|-----------|----------|---------|-------------|
-| `--status` | No |  -  | Show dashboard only, don't start review loop |
-
-```
-/performance-review-next
-/performance-review-next --status
-```
-
----
-
-## Constants
-
-```
-REPO_ROOT       = git repo root (auto-detect)
-TRACKER_FILE    = ${REPO_ROOT}/_tour_tracker.json
-UICOMPONENTS    = ${REPO_ROOT}/{repos.components.path}
-```
-
----
-
-## STEP 0  -  Read Tracker & Show Dashboard
-
-Read `_tour_tracker.json`. If not found → HALT: "No tour in progress."
-
-Detect lean mode:
-```python
-lean_mode = tracker.get("lean_mode", False)
-```
-
-### Dashboard
-
-```
-╔══════════════════════════════════════════════════════════════╗
-║  TOUR REVIEW DASHBOARD                                       ║
-╠══════════════════════════════════════════════════════════════╣
-║                                                              ║
-║  # │ Issue  │ Component    │ Status                          ║
-║  ──┼────────┼──────────────┼──────────────────────────────── ║
-║  1 │ #1000  │ ComponentA   │ ✅ Produced  -  ready for review  ║
-║  2 │ #1002  │ ComponentC   │ ✅ Produced  -  ready for review  ║
-║  3 │ #1001  │ ComponentB   │ ❌ Halted (Phase 4)             ║
-║                                                              ║
-║  Reviewed: 0/2 produced                                      ║
-║                                                              ║
-╚══════════════════════════════════════════════════════════════╝
-```
-
-If `lean_mode` is `true`, add a warning banner after the dashboard:
-
-```
-⚠️  LEAN MODE  -  Tests & wiki were NOT generated.
-    Review covers: implementation (Phase 4) + Code Connect (Phase 6) only.
-```
-
-If `--status` → print dashboard and exit.
-
----
-
-## STEP 1  -  Build All (One Time)
-
-Before any review, run a single build to verify the current state:
-
-```bash
-xcodebuild build -project "${REPO_ROOT}/{build.xcodeproj}" \
-    -scheme {build.scheme} -destination 'generic/platform=iOS' \
-    CODE_SIGNING_ALLOWED=NO -quiet
-```
-
-**If build fails:**
-
-Identify which component's files caused the failure from the error output.
-Print:
-
-```
-⚠️ Build failed. Error in: Sources/.../ComponentA/ComponentAView.swift:42
-   Likely component: ComponentA (#1000)
-   
-   Fix the issue, then run /performance-review-next to continue.
-```
-
-Do NOT proceed until build passes.
-
-**If build passes:** Print "Build ✅  -  all components compile" and proceed to STEP 2.
-
----
-
-## STEP 2  -  Review Loop
-
-Ask user which component to review:
-
-```
-Which component would you like to review?
-  [1] ComponentA (#1000)  -  ready for review
-  [2] ComponentC (#1002)  -  ready for review
-  [3] ComponentB (#1001)  -  halted (retry/drop)
-  [done] All reviews complete → proceed to commit
-```
-
-### 2a. Reviewing a Produced Component
-
-When user selects a produced component:
-
-1. **Show component files:**
-   ```bash
-   # List files created by this component
-   find "${UICOMPONENTS}/Sources" -path "*/${COMPONENT_NAME}/*" -type f
-   find "${UICOMPONENTS}/Tests" -path "*/${COMPONENT_NAME}*" -type f
-   ```
-
-2. **Run component tests:**
-
-   > **LEAN MODE:** If `lean_mode` is `true`, **SKIP this substep.** Print `Tests: ⏭ skipped (lean mode)` instead.
-
-   ```bash
-   xcodebuild test -project "${REPO_ROOT}/{build.xcodeproj}" \
-       -scheme {build.scheme} \
-       -destination 'platform=iOS Simulator,name=iPhone 16 Pro' \
-       -only-testing:"UIComponentsTests/${COMPONENT_NAME}ViewInspectorTests" \
-       -only-testing:"UIComponentsTests/${COMPONENT_NAME}SnapshotTests" \
-       CODE_SIGNING_ALLOWED=NO -quiet
-   ```
-
-3. **Present review options:**
-   ```
-   ComponentA (#1000)  -  Review
-     Files: 8 files (view, config, tests, snapshots, wiki, code-connect)    # lean: fewer files
-     Tests: ✅ 12 passed    # lean: ⏭ skipped (lean mode)
-   
-   Actions:
-     [approve] Mark as reviewed ✅
-     [fix]     I see an issue  -  let me fix it
-     [back]    Back to dashboard
-   ```
-
-4. **If user selects "fix":**
-   - User makes changes manually or describes the fix
-   - Agent applies the fix
-   - Agent commits the fix:
-     ```bash
-     cd ${UICOMPONENTS}
-     git add -A
-     git commit -m "fix(uicomponents): [${JIRA_KEY}] fix ${COMPONENT_NAME} review feedback
-     
-     Refs: ${JIRA_KEY}
-     Tour: performance-tour review fix"
-     ```
-   - Re-run tests to verify fix
-   - Return to review options for this component
-
-5. **If user selects "approve":**
-   - Update tracker: add to `reviewed_components`
-   - Print: "✅ ComponentA marked as reviewed"
-   - Return to dashboard
-
-### 2b. Reviewing a Halted Component
-
-When user selects a halted component:
-
-```
-ComponentB (#1001)  -  Halted at Phase 4
-  Reason: Build failure  -  missing dependency protocol
-  
-  Actions:
-    [retry]  Re-produce this component from scratch
-    [drop]   Remove from tour (issue stays open)
-    [back]   Back to dashboard
-```
-
-**If "retry":**
-1. Run `/performance-start <issue> --tour` + `/performance-swiftui <figma-url>` (add `--lean` if `lean_mode` is `true`)
-2. If successful → commit locally, update tracker to `"produced"`
-3. Return to dashboard (component now reviewable)
-
-**If "drop":**
-1. Update tracker: move from `halted_components` to `dropped_components`
-2. Print: "ComponentB dropped from tour. Issue #1001 remains open."
-3. Return to dashboard
-
-### 2c. All Reviews Complete
-
-When user selects "done" or all produced components are reviewed:
-
-```
-╔══════════════════════════════════════════════════════════════╗
-║  REVIEW COMPLETE                                             ║
-╠══════════════════════════════════════════════════════════════╣
-║                                                              ║
-║  Reviewed:  2 components                                     ║
-║  Dropped:   1 component (ComponentB)                         ║
-║                                                              ║
-║  Ready to commit:                                            ║
-║  ✅ #1000  -  ComponentA                                       ║
-║  ✅ #1002  -  ComponentC                                       ║
-║                                                              ║
-║  Next: /performance-iteration-commit-all                     ║
-╚══════════════════════════════════════════════════════════════╝
-```
-
-Update tracker: `current_step = "STEP_3"`.
-
----
-
-## Error Handling
-
-| Error | Action |
-|-------|--------|
-| Tracker not found | HALT: "No tour in progress" |
-| No produced components | HALT: "No components to review. All halted." |
-| Build fails during review | Show error, let user fix, re-build |
-| Test fails after fix | Show failure, let user decide (fix again or approve anyway) |
-| Retry fails again | Mark as halted again, ask user to drop or try later |
-
----
-
-## Guardrails
-
-> **NEVER push during review.** All commits (including fixes) are local only.
-
-> **Fix commits are ALWAYS separate.** Never amend, squash, or rebase existing commits.
-> New fix commit with descriptive message.
-
-> **ALWAYS update tracker after every action** (approve, fix commit, retry, drop).
-
-> **ALWAYS re-run build after any fix** to ensure project still compiles.

package/pipeline/skills/figma-common/performance-start/SKILL.md

@@ -1,430 +0,0 @@
----
-name: performance-start
-description: Identical to `/figma-to-swift-ui-start` for Steps 0-5. After printing the summary (Step 6), automatically invokes `/performance-swiftui <figma-url>` to begin the implementation pipeline.
----
-
-# /performance-start  -  Start + Auto-Launch Performance Pipeline
-
-> Identical to `/figma-to-swift-ui-start` for Steps 0-5. After printing the summary (Step 6),
-> automatically invokes `/performance-swiftui <figma-url>` to begin the implementation pipeline
-> without waiting for user input.
-
-## Parameters
-
-| Parameter | Required | Default | Description |
-|-----------|----------|---------|-------------|
-| `<issue-number>` | Yes |  -  | GitHub issue number from uicomponents repo |
-| `jira id <KEY>` | No |  -  | Jira issue key (e.g., `{jira.projectKey}-129850`). If provided, updates GitHub issue body and populates Jira task. |
-| `--tour` | No |  -  | Tour mode: skips fetch/pull (STEP 1) and branch creation (STEP 2). Used by `/performance-tour` when producing multiple components on `iteration/develop`. |
-| `--lean` | No |  -  | Lean mode: forwarded to `/performance-swiftui` to skip Phase 5 (testing) and Phase 7 (wiki). Can be combined with `--tour`. |
-
-```
-/performance-start #107
-/performance-start 107
-/performance-start 160, jira id {jira.projectKey}-129850
-/performance-start #107 --tour
-/performance-start #107 --lean
-/performance-start #107 --tour --lean
-```
-
-### Tour Mode (`--tour`)
-
-When `--tour` is passed, the following steps are **SKIPPED**:
-
-| Step | Normal Mode | Tour Mode |
-|------|------------|:---------:|
-| STEP 0  -  Parse Issue | ✅ | ✅ |
-| STEP 0.5  -  Confirm Pipeline Mode | ✅ | **SKIP** |
-| STEP 1  -  Fetch Latest | ✅ | **SKIP** |
-| STEP 2  -  Create Feature Branches | ✅ | **SKIP** |
-| STEP 3  -  Registry Lookup | ✅ | ✅ |
-| STEP 3.5  -  Save Specs Artifact | ✅ | ✅ |
-| STEP 4  -  Assign to Me | ✅ | ✅ |
-| STEP 5  -  Update Issue Status | ✅ | ✅ |
-| STEP 6  -  Summary + Auto-Launch | ✅ | ✅ |
-
-**Rationale:** In tour mode, `/performance-tour` has already fetched latest and
-all submodules are on `iteration/develop`. Creating feature branches would conflict
-with the tour's single-branch local commit strategy.
-
----
-
-## Constants
-
-```
-REPO_ROOT       = git repo root (auto-detect)
-GH_REPO         = {github.componentsRepo}
-DEFAULT_JIRA    = {jira.projectKey}-124692
-BASE_BRANCH     = develop                # main repo; submodules use iteration/develop
-```
-
-### Submodule Paths
-
-```
-MAIN_REPO       = ${REPO_ROOT}
-COMMON          = ${REPO_ROOT}/{repos.common.path}
-UICOMPONENTS    = ${REPO_ROOT}/{repos.components.path}
-WIKI            = ${REPO_ROOT}/{repos.wiki.path}
-```
-
----
-
-## STEP 0  -  Parse Issue
-
-```bash
-gh issue view <N> --repo ${GH_REPO} --json number,title,body,labels,assignees
-```
-
-Extract from the issue body:
-- **Component Name**  -  from `### Component Name (PascalCase)` section
-- **Figma URL**  -  from `### Figma URL` section
-- **Node ID**  -  from `### Node ID` section
-- **Registry Name**  -  from `### Registry Name` section
-- **Figma Page**  -  from `### Figma Page` section
-- **Jira Key**  -  from `### Jira Issue` section (if not `_No response_`)
-- **Acceptance Criteria**  -  from `### Acceptance Criteria` section (if not `_No response_`)
-
-If Jira key is `_No response_` or empty **and** user provided a `jira id` parameter:
-1. Use the user-provided key as `JIRA_ISSUE`.
-2. Update the GitHub issue body  -  replace `_No response_` under `### Jira Issue` with a Jira link:
-   ```bash
-   # Read current body, replace the Jira section, update via gh
-   CURRENT_BODY=$(gh issue view <N> --repo ${GH_REPO} --json body --jq '.body')
-   # Replace '_No response_' in the Jira Issue section with the link
-   NEW_BODY=$(echo "$CURRENT_BODY" | sed 's|### Jira Issue\n\n_No response_|### Jira Issue\n\n[<JIRA_KEY>]({jira.baseUrl}/browse/<JIRA_KEY>)|')
-   gh issue edit <N> --repo ${GH_REPO} --body "$NEW_BODY"
-   ```
-
-If Jira key is `_No response_` or empty **and** no `jira id` parameter, use `DEFAULT_JIRA`.
-
-Derive:
-- `COMPONENT_PASCAL` = Component Name (e.g., `ModalsTitle`)
-- `COMPONENT_KEBAB` = kebab-case (e.g., `modals-title`)
-- `JIRA_ISSUE` = extracted key or default
-- `NODE_UNDERSCORE` = node-id with `-` replaced by `_` (e.g., `2820-25995` → `2820_25995`)
-- `BRANCH_NAME` = `feature/${JIRA_ISSUE}-GH${N}-N${NODE_UNDERSCORE}-${COMPONENT_KEBAB}`
-
-Print:
-
-```
--------------------------------------------
-  Issue:      #<N>
-  Component:  <COMPONENT_PASCAL>
-  Jira:       <JIRA_ISSUE>
-  Node ID:    <NODE_ID>
-  Branch:     feature/<JIRA_ISSUE>-GH<N>-N<NODE_UNDERSCORE>-<COMPONENT_KEBAB>
-  Base:       develop (main repo) / iteration/develop (submodules)
--------------------------------------------
-```
-
----
-
-## STEP 0.5  -  Confirm Pipeline Mode
-
-> **If `--tour` is set → SKIP this step.** Tour mode delegates mode selection to `/performance-tour`.
-
-After parsing the issue, **always ask the user** to confirm which pipeline mode to use  -  regardless of whether `--lean` was passed as a parameter. This prevents accidental full-pipeline runs when lean was intended, or vice versa.
-
-**Use the ask-questions tool** with these options:
-
-| Header | Question | Options |
-|--------|----------|---------|
-| Pipeline Mode | `<COMPONENT_PASCAL>` implementation  -  which pipeline mode? | **Lean** (skip testing & wiki  -  Phases 5, 7) · **Full** (all 8 phases) |
-
-- If `--lean` was passed in the original command, pre-select **Lean** as the recommended option.
-- If no flag was passed, pre-select **Full** as the recommended option.
-
-**After user responds:**
-- If user picks **Lean** → set internal `LEAN_FLAG = true` (forward `--lean` to `/performance-swiftui`).
-- If user picks **Full** → set internal `LEAN_FLAG = false` (no `--lean` forwarded).
-
-This confirmation overrides whatever was passed on the command line.
-
----
-
-## STEP 1  -  Fetch Latest
-
-> **If `--tour` is set → SKIP this entire step.** Tour mode assumes
-> `/performance-tour` STEP 0e has already fetched and checked out the correct branches.
-
-Ensure all repos are up to date with remote:
-
-```bash
-cd ${MAIN_REPO}
-git fetch origin
-git checkout develop
-git pull --no-recurse-submodules origin develop
-
-cd ${COMMON}
-git fetch origin
-git checkout iteration/develop
-git pull origin iteration/develop
-
-cd ${UICOMPONENTS}
-git fetch origin
-git checkout iteration/develop
-git pull origin iteration/develop
-```
-
----
-
-## STEP 2  -  Create Feature Branches
-
-> **If `--tour` is set → SKIP this entire step.** Tour mode stays on
-> `iteration/develop` with local commits. No feature branches are created.
-
-Create feature branches on **submodules only**. Do NOT create branches on the main repo  -  it stays on `develop`. The main repo never receives commits from this workflow; submodule refs are updated separately.
-
-```bash
-# Common (tokens, localization, accessibility, testing identifiers)
-cd ${COMMON}
-git checkout -b ${BRANCH_NAME}
-
-# UIComponents (SwiftUI views, tests, snapshots)
-cd ${UICOMPONENTS}
-git checkout -b ${BRANCH_NAME}
-```
-
-Wiki submodule stays on `master`  -  wiki changes are committed directly.
-
----
-
-## STEP 3  -  Registry Lookup
-
-```bash
-cd ${COMMON}
-.build/debug/FigmaRegistryUtility lookup --node-id <NODE_ID>
-```
-
-Collect:
-- `suggestedComponentLocation`  -  where the Swift files will go
-- `suggestedArtifactPath`  -  where implementation artifacts go
-
-Print:
-
-```
-Component Location: <suggestedComponentLocation>
-Artifact Path:      <suggestedArtifactPath>
-```
-
----
-
-## STEP 3.5  -  Save Specs Artifact
-
-If the issue has acceptance criteria (not `_No response_`), save them as an artifact that the implementation pipeline can consume.
-
-```bash
-mkdir -p ${REPO_ROOT}/${suggestedArtifactPath}/pass0
-```
-
-Write `${suggestedArtifactPath}/pass0/specs.md`:
-
-```markdown
-# Implementation Specs: {ComponentName}
-
-## Source
-- Issue: #{N}
-- Figma: {FIGMA_URL}
-
-## Acceptance Criteria
-
-{ACCEPTANCE_CRITERIA from issue body  -  verbatim}
-
-## Implementation Guidance
-
-{Convert the acceptance criteria into actionable implementation instructions for the AI agent:
-- Rephrase checkbox items as concrete requirements
-- Add technical context where the criteria imply Swift/SwiftUI patterns
-- Preserve the user's intent exactly  -  don't add or remove requirements}
-```
-
-If no acceptance criteria → skip this step. No file created.
-
----
-
-## STEP 4  -  Assign to Me
-
-Assign the GitHub issue and linked Jira task (if any) to the current user. Same logic as `/figma-issue assign`:
-
-```bash
-gh issue edit <N> --repo ${GH_REPO} --add-assignee @me
-```
-
-If Jira key exists (from issue body or user-provided `jira id` parameter  -  not `_No response_` and not `DEFAULT_JIRA`):
-
-Use **Python urllib** for all Jira API calls (curl is blocked by terminal auto-approval policy):
-
-```python
-# /tmp/jira_start_<JIRA_KEY>.py
-import subprocess, urllib.request, json
-
-token = subprocess.check_output(
-    ["security", "find-generic-password", "-a",
-     subprocess.check_output(["whoami"]).decode().strip(),
-     "-s", "JIRA_TOKEN", "-w"],
-    stderr=subprocess.DEVNULL
-).decode().strip()
-
-JIRA_KEY = "<JIRA_KEY>"
-FIGMA_URL = "<FIGMA_URL>"
-GITHUB_URL = "https://github.com/{github.componentsRepo}/issues/<N>"
-REGISTRY_NAME = "<REGISTRY_NAME>"
-COMPONENT_NAME = "<COMPONENT_PASCAL>"
-PAGE_NAME = "<FIGMA_PAGE>"
-
-# 1. Get current user
-req = urllib.request.Request(
-    "{jira.baseUrl}/rest/api/2/myself",
-    headers={"Authorization": f"Bearer {token}"}
-)
-resp = urllib.request.urlopen(req, timeout=15)
-username = json.loads(resp.read().decode())["name"]
-print(f"Username: {username}")
-
-# 2. Assign to current user
-data = json.dumps({"name": username}).encode()
-req2 = urllib.request.Request(
-    f"{jira.baseUrl}/rest/api/2/issue/{JIRA_KEY}/assignee",
-    data=data,
-    headers={"Authorization": f"Bearer {token}", "Content-Type": "application/json"},
-    method="PUT"
-)
-try:
-    resp2 = urllib.request.urlopen(req2, timeout=15)
-    print(f"Assigned {JIRA_KEY} to {username} (HTTP {resp2.status})")
-except urllib.error.HTTPError as e:
-    print(f"Assign failed  -  HTTP {e.code}: {e.read().decode()[:200]}")
-
-# 3. Update Jira summary, description, and labels
-description = (
-    "h3. Figma\n"
-    f"[{COMPONENT_NAME}|{FIGMA_URL}]\n\n"
-    "h3. GitHub Issue\n"
-    f"[#{<N>}|{GITHUB_URL}]\n\n"
-    "h3. Component\n"
-    f"* *Registry Name:* {REGISTRY_NAME}\n"
-    f"* *Component Name:* {COMPONENT_NAME}\n"
-    f"* *Page:* {PAGE_NAME}\n\n"
-    "h3. Status\n"
-    "* (x) Implementation\n"
-    "* (x) Testing\n"
-    "* (x) Code Connect\n"
-    "* (x) Documentation"
-)
-summary = f"Implement {COMPONENT_NAME} iOS UI Component"
-update_data = json.dumps({
-    "fields": {
-        "summary": summary,
-        "description": description,
-        "labels": ["redesign_ios_ui_component", "MobRedesign"],
-        "components": [{"name": "TKMOB IOS"}],
-        "fixVersions": [{"name": "no-version"}],
-        "customfield_22025": {"value": "YOK"},
-        "customfield_21400": ["no-version"]
-    }
-}).encode()
-req3 = urllib.request.Request(
-    f"{jira.baseUrl}/rest/api/2/issue/{JIRA_KEY}",
-    data=update_data,
-    headers={"Authorization": f"Bearer {token}", "Content-Type": "application/json"},
-    method="PUT"
-)
-try:
-    resp3 = urllib.request.urlopen(req3, timeout=15)
-    print(f"Updated {JIRA_KEY} content (HTTP {resp3.status})")
-except urllib.error.HTTPError as e:
-    print(f"Update failed  -  HTTP {e.code}: {e.read().decode()[:200]}")
-```
-
-Run: `python3 /tmp/jira_start_<JIRA_KEY>.py`
-
-If Jira token not found or VPN unreachable, skip with warning:
-
-```
-⚠️ Jira update skipped (token missing or VPN unreachable). Update <JIRA_KEY> manually if needed.
-```
-
----
-
-## STEP 5  -  Update Issue Status (required)
-
-**This step is mandatory. Do not skip it and do not defer it.** The issue
-is on the board with Status=Todo after creation. Moving it to Status=In
-Develop is how the board reflects that someone has started working on
-it. If you skip this step, the issue visually stays in the Todo column
-even though work has started.
-
-Set the issue phase to "Implementation" and status to "In Develop" on the Projects V2 board:
-
-```bash
-# Get issue node ID
-ISSUE_NODE_ID=$(gh api graphql -f query='{ repository(owner: "{github.org}", name: "{project.slug}-components") { issue(number: <N>) { id } } }' --jq '.data.repository.issue.id')
-
-# Add to project (if not already). This mutation is idempotent  -  if the
-# item already exists it returns the existing item id.
-ITEM_ID=$(gh api graphql -f query='mutation { addProjectV2ItemById(input: { projectId: "{github.projectV2Id}", contentId: "'"$ISSUE_NODE_ID"'" }) { item { id } } }' --jq '.data.addProjectV2ItemById.item.id')
-
-# Set Status = In Develop (option id: bc6c45f7)
-gh api graphql -f query='mutation { updateProjectV2ItemFieldValue(input: { projectId: "{github.projectV2Id}", itemId: "'"$ITEM_ID"'", fieldId: "{github.projectV2Fields.status}", value: { singleSelectOptionId: "bc6c45f7" } }) { projectV2Item { id } } }'
-
-# Set Phase = Implementation (option id: 0577dcda)
-gh api graphql -f query='mutation { updateProjectV2ItemFieldValue(input: { projectId: "{github.projectV2Id}", itemId: "'"$ITEM_ID"'", fieldId: "{github.projectV2Fields.phase}", value: { singleSelectOptionId: "0577dcda" } }) { projectV2Item { id } } }'
-```
-
-### Verify the move landed
-
-After the mutations return, confirm Status=In Develop is set (this catches
-silent VALIDATION errors from stale option IDs):
-
-```bash
-gh api graphql -f query='{ node(id: "'"$ITEM_ID"'") { ... on ProjectV2Item { fieldValues(first: 20) { nodes { ... on ProjectV2ItemFieldSingleSelectValue { field { ... on ProjectV2SingleSelectField { name } } name } } } } } }' \
-  --jq '.data.node.fieldValues.nodes[] | select(.field.name == "Status") | .name'
-```
-
-Expected output: `In Develop`. If you see anything else (or empty),
-re-fetch the current option IDs and retry  -  do NOT proceed to implementation
-without the Status set correctly.
-
----
-
-## STEP 6  -  Summary + Auto-Launch Pipeline
-
-Print:
-
-```markdown
-Ready to implement:
-
-| Field | Value |
-|-------|-------|
-| Issue | [#N](url) |
-| Component | <COMPONENT_PASCAL> |
-| Jira | <JIRA_ISSUE> |
-| Branch | `<BRANCH_NAME>` |
-| Base | `develop` (main repo) / `iteration/develop` (submodules) |
-| Component Location | <suggestedComponentLocation> |
-| Artifact Path | <suggestedArtifactPath> |
-
-🚀 Auto-launching /performance-swiftui pipeline...
-```
-
-**Immediately after printing the summary**, invoke the `/performance-swiftui` skill with the Figma URL extracted from the issue:
-
-```
-/performance-swiftui <FIGMA_URL>              # if LEAN_FLAG = false (Full mode confirmed in STEP 0.5)
-/performance-swiftui <FIGMA_URL> --lean       # if LEAN_FLAG = true  (Lean mode confirmed in STEP 0.5)
-```
-
-Forward `--lean` based on the user's confirmed selection in **STEP 0.5** (not the raw command-line flag). This starts Phase 0 of the performance-optimized implementation pipeline.
-
-> If any STEP (0-5) failed or was aborted, do NOT auto-launch. Print the error and stop.
-
----
-
-## Error Handling
-
-- **Issue not found**: Print error and stop.
-- **Issue body missing required fields**: Print which fields are missing, stop.
-- **FigmaRegistryUtility not built**: Run `swift build --product FigmaRegistryUtility` in common.
-- **Branch already exists**: Print warning  -  checkout existing branch instead of creating.
-- **Main repo not on develop**: Fetch and checkout automatically.
-- **Submodule not on iteration/develop**: Fetch and checkout automatically.