Phases
2
ready-for-dev-Marker im
SOLCOM-Design-System-File als Jira-Sub-Tasks unter P2503-83
anlegt und die Verknüpfung in docs/design/MAPPING.html pflegt.
Orchestrierung durch den neuen Skill, Figma-Scan delegiert an den
bestehenden solcom-design-scanner-Agent.
P2503-83Tracer-Bullet-Slicing in Dependency-Reihenfolge. Phase 1 = Slices 1 + 2 (Schema + Scanner-Erweiterung), Phase 2 = Slices 3 + 4 (Skill MVP + Multi-Frame mit Bündeln).
| Phase / Slice | Title | Type | Blocked by |
|---|---|---|---|
| 1 · S1 | MAPPING-Schema-Erweiterung + ADR | HITL | — |
| 1 · S2 | Scanner-Agent ready-for-dev-Awareness |
AFK | S1 |
| 2 · S3 | Skill-Skelett, ein Frame, kein Bündeln | HITL | S1, S2 |
| 2 · S4 | Multi-Frame-Loop + Bündeln | HITL | S3 |
Jeder Slice ist eigenständig demobar. Akzeptanz-Bullets sind die Verifikations-Checks, mit denen ein Slice „done" deklariert wird.
ADR 0NNN-mapping-figma-status-as-second-dimension.html
dokumentiert die Schema-Entscheidung: zwei Status-Dimensionen
statt eines erweiterten Status-Tupels (z. B. gap-ready-for-dev).
Hard-to-reverse + surprising-without-context + real-trade-off → ADR
wird gemäß solcom-adr-workflow erstellt, mit Konsultation
des customer-lens-reviewer-Agents (≥ 2 Optionen).
solcom-design-mapping-Skill-Doku wird auf das neue
7-Spalten-Schema umgestellt. Bestehendes
docs/design/MAPPING.html wird migriert: zwei neue
<th>-Header (Figma-Status,
Jira Sub-Task), bestehende Rows bekommen zwei leere
<td>-Zellen.
docs/adr/ mit den 4 kanonischen Sektionen und Reviewer-Konsultations-Logsolcom-design-mapping-Skill-Doku zeigt das neue 7-Spalten-Schemadocs/design/MAPPING.html validiert im Browser, alle bestehenden Rows haben zwei zusätzliche Spaltendocs/LOG.html für die Schema-Migration (Op: migrate)ready-for-dev-Awareness
solcom-design-scanner.md bekommt einen neuen
Workflow-Schritt: für jeden Frame wird das Figma-Status-Flag
ermittelt (technische Recherche beim Implementieren: ob
mcp__claude_ai_Figma__get_metadata das exponiert oder
ein anderer MCP-Call gebraucht wird — Sondierung gehört in den
Slice). Werte: ready-for-dev,
wip (Default für nicht-markierte Frames),
archived, - (unbekannt).
Figma-Status-Spalte für jeden Frameready-for-dev
.claude/skills/figma-ready-for-dev-to-jira/SKILL.md
entsteht analog zur Struktur von backlog-to-jira.
Inhalt: Pflichtregeln (AskUserQuestion-Pflicht), Trigger-Phrasen,
REST-API-Setup, ADF-Beschreibungsformat, Pre-Flight (REST + Figma-Auth).
Workflow: Task-Tool ruft
solcom-design-scanner auf → MAPPING.html parsen →
ersten Frame mit Figma-Status = ready-for-dev und
leerer Jira Sub-Task-Spalte nehmen → AskUserQuestion
mit Optionen anlegen / skippen → bei
Anlegen: REST-POST Sub-Task unter P2503-83 (ADF: User
Story + Figma-Frame-Deep-Link, Label figma-node:<id>)
→ MAPPING-Zeile editieren (P2503-Key in Spalte schreiben) →
LOG-Eintrag.
figma-node:<node-id>
Skill iteriert über alle qualifizierten Frames. AskUserQuestion-Optionen
erweitert: anlegen / bündeln /
skippen. Sammler-Logik: Beim ersten
bündeln fragt der Skill nach einem Sammler-Namen,
legt EINEN Sammler-Sub-Task an, merkt sich die Key. Bei späteren
bündeln-Antworten zeigt der Skill die offenen Sammler
zur Auswahl plus „neuer Sammler". Beim Anhängen an einen Sammler:
Figma-Link wird via REST PUT in den Sammler-Body angehängt; alle
MAPPING-Zeilen der gebündelten Frames tragen die Sammler-Key.
Defense-in-Depth: JQL-Bulk-Check via Label figma-node:<id>
beim Skill-Start für Drift-Detection.
docs/agents/skills.html-Inventar referenziert den neuen Skill mit Trigger-PhrasenWer ruft wen auf, welche Datei wird angefasst, an welcher Stelle entsteht der Jira-Sub-Task. Solid = Lese-/Schreib-Pfad. Gestrichelt = AskUserQuestion-Interaktion.
Der Orchestrator-Skill ist die einzige Stelle, die schreibt — MAPPING.html und Jira werden NUR vom Skill verändert.
Der Scanner-Agent schreibt zwar MAPPING.html (Slice 2), aber nicht die Jira Sub-Task-Spalte.
Die zwei Stellen, an denen sich der Skill verbeißen kann: das ADF-Body-Schema für den Sub-Task und die neue 7-Spalten-Geometrie der MAPPING.html.
{
"fields": {
"project": { "key": "P2503" },
"parent": { "key": "P2503-83" },
"issuetype": { "name": "Sub-task" },
"summary": "Komponente: <Frame-Name>",
"labels": ["figma-node:<node-id>"],
"description": {
"type": "doc", "version": 1,
"content": [
{ "type": "paragraph", "content": [
{ "type": "text",
"text": "Als Frontend-Dev möchte ich die Komponente <Frame-Name> als SDC, um sie auf Pages einsetzen zu können." }]},
{ "type": "paragraph", "content": [
{ "type": "text", "text": "Figma: " },
{ "type": "text", "text": "<frame-deep-link>",
"marks": [{ "type": "link",
"attrs": { "href": "<frame-deep-link>" }}]}]}
]
}
}
}<thead> <tr> <th>Figma-Frame</th> <th>Figma-Node-ID</th> <th>SDC / Komposition</th> <th>Status</th> <!-- Impl --> <th>Figma-Status</th> <!-- NEU --> <th>Jira Sub-Task</th> <!-- NEU --> <th>Last verified</th> <th>Notes</th> </tr> </thead> // Werte Figma-Status: // ready-for-dev → in Figma freigegeben // wip → Designer-Default, noch nicht freigegeben // archived → aus Figma entfernt / deprecated // - → unbekannt (z. B. vor Scanner-Update) // Werte Jira Sub-Task: // P2503-<n> → Link/Plain-Text-Key // leer → noch nicht angelegt (Skill-Pickup-Kandidat)
readyForDev nicht als einfaches Node-Property — Scanner-Sondierung scheitert.· dev) oder Figma-Plugin-Export als Quelle. Sondierungs-Ergebnis kommt in den Slice-2-PR.figma-node:<id> beim Skill-Start, Treffer → MAPPING-Zeile auto-heilen + Abbruch mit Hinweis statt POST.figma-bundle:<slug>). Beim Skill-Start lädt der Loop offene Sammler aus Jira, nicht aus In-Memory-State.POST /issue/createmeta validiert, bevor der echte POST läuft. Vorbild: backlog-to-jira.whoami und Jira /project/P2503. Bei Fehler: klare Abort-Message mit Hinweis auf die fehlende Auth.Aus dem Grilling übrig gebliebene kleine Entscheidungen — als Defaults gesetzt, beim Bauen ggf. korrigierbar.
figma-ready-for-dev-to-jirabacklog-to-jira. Lang, aber descriptive. Alternative: figma-rfd-to-jira (kompakter).backlog-to-jira.figma-node:<node-id>backlog:F-30). Sammler bekommen zusätzlich figma-bundle:<slug>.