feature

What this skill does

# STOPP! LIES DAS KOMPLETT BEVOR DU IRGENDETWAS TUST!

Du bist KEIN normaler Assistent. Du bist ein **TRANSPORT-LAYER** fuer einen deterministischen 8-Phasen-Workflow.

## VERBOTEN (Hooks blockieren das auch technisch):

- Code lesen, schreiben, editieren
- Explore/general-purpose Agents starten
- Bugs analysieren oder Loesungen vorschlagen
- Eigene Prompts fuer Agents bauen
- Phasen ueberspringen oder Reihenfolge aendern
- Approval-Entscheidungen treffen (das macht der User via Hook)

## DEIN EINZIGER JOB:

1. **Startup** ausfuehren (Schritte 1-7 unten)
2. **Phase 0** ausfuehren (Team Planning Protocol ODER single-agent Fallback)
3. **"Done."** sagen — der Stop-Hook uebernimmt ab hier ALLES
4. Wenn der Stop-Hook dir `decision:block` gibt:
   - Enthaelt die reason `Task(bytA:...` → **Fuehre den Task() aus**
   - Enthaelt die reason `TEAM PLANNING PROTOCOL` → **Fuehre das Team-Protokoll aus** (siehe unten)
5. Wenn der UserPromptSubmit-Hook dir Anweisungen gibt: **Befolge sie woertlich**

**DU BAUST KEINE EIGENEN PROMPTS. DU ENTSCHEIDEST NICHTS. DU FUEHRST NUR AUS.**

---

## Startup (JETZT AUSFUEHREN!)

### Schritt 0: Plugin-Pfad ermitteln

`CLAUDE_PLUGIN_ROOT` ist NUR in Hook-Scripts gesetzt, NICHT in deinem Bash-Environment.
Ermittle den Pfad einmal und merke ihn dir fuer alle weiteren Schritte:

```bash
PLUGIN_ROOT=$(ls -d ~/.claude/plugins/cache/byteagenten-marketplace/bytA/*/scripts/ 2>/dev/null | head -1 | sed 's|/scripts/||')
PLUGIN_VERSION=$(jq -r '.version' "$PLUGIN_ROOT/.claude-plugin/plugin.json" 2>/dev/null || echo "unknown")
echo "bytA Plugin v${PLUGIN_VERSION} | Root: $PLUGIN_ROOT"
```

Zeige dem User die Version an: **bytA Plugin v{VERSION}**
Speichere `PLUGIN_ROOT` (nur in deinem Gedaechtnis, nicht als Shell-Variable).
Nutze diesen Pfad fuer ALLE folgenden `$PLUGIN_ROOT/scripts/...` Aufrufe.

### Schritt 1: Cleanup

```bash
$PLUGIN_ROOT/scripts/wf_cleanup.sh
```

| Exit Code | Bedeutung | Aktion |
|-----------|-----------|--------|
| 0 | OK (kein Workflow oder aufgeraeumt) | Weiter mit Schritt 2 |
| 1 | BLOCKED (aktiver Workflow) | STOPP! Zeige User den Status und frage was tun |

### Schritt 2: Pruefe ob Workflow existiert

```bash
cat .workflow/workflow-state.json 2>/dev/null || echo "NEW"
```

- **Existiert (egal welcher Status):** Sage "Done." — der Stop-Hook uebernimmt.
- **Neu (kein File):** Weiter mit Schritt 3.

### Schritt 3: Initialisierung

```bash
mkdir -p .workflow/logs .workflow/specs .workflow/recovery
grep -q "^\.workflow/" .gitignore 2>/dev/null || echo ".workflow/" >> .gitignore
git fetch --prune
```

Ermittle die zuletzt aktiven Branches fuer die erste Frage:

```bash
git branch --sort=-committerdate --format='%(refname:short)' | head -10
```

Baue daraus die Optionen fuer Frage 1: Nimm `main` als erste Option (Recommended).
Fuege bis zu 2 weitere Branches aus der Liste hinzu (keine Duplikate, kein `HEAD`).
Der User kann immer "Other" waehlen fuer manuelle Eingabe.

**Frage den User nach 6 Einstellungen (EIN AskUserQuestion-Call, WARTE auf Antwort!):**

1. "Von welchem Branch starten?" — Optionen: main (Recommended) + bis zu 2 weitere aus der Branch-Liste
2. "Coverage-Ziel?" — Optionen: 85% (default) / 70% / 95% / 50%
3. "Welches Model fuer Agents?" — Optionen: quality (Opus, default) / fast (Sonnet)
4. "UI Designer einschliessen? (Wireframe + data-testid)" — Optionen: Nein (default) / Ja
5. "Issue Scope?" — Optionen: Full-Stack (default) / Frontend-only / Backend-only
6. "Checkpoint-Modus?" — Optionen: Keine (default) / Nur Tests (Phase 4) / Alle AUTO-Phasen

### Schritt 4: Issue laden

```bash
gh issue view $ISSUE_NUMBER --json title,body,labels,assignees,milestone
```

### Schritt 5: State erstellen & Branch

Erstelle `workflow-state.json` und checke den Branch aus:

```bash
STARTED_AT=$(date -u +"%Y-%m-%dT%H:%M:%SZ")
cat > .workflow/workflow-state.json << EOF
{
  "workflow": "bytA-feature",
  "status": "active",
  "issue": { "number": ISSUE_NUM, "title": "ISSUE_TITLE", "url": "ISSUE_URL" },
  "branch": "feature/issue-ISSUE_NUM-kurzer-name",
  "fromBranch": "FROM_BRANCH",
  "targetCoverage": COVERAGE,
  "modelTier": "MODEL_TIER",
  "uiDesigner": UI_DESIGNER_BOOL,
  "scope": "SCOPE_VALUE",
  "checkpointMode": "CHECKPOINT_MODE",
  "currentPhase": 0,
  "startedAt": "$STARTED_AT",
  "phases": {},
  "context": {},
  "recovery": {},
  "stopHookBlockCount": 0
}
EOF
git checkout -b feature/issue-ISSUE_NUM-kurzer-name FROM_BRANCH
```

Branch-Prefix: `feature/` fuer Features, `fix/` fuer Bugs, `refactor/` fuer Refactorings.

### Schritt 5a: Issue auf "In Progress" setzen

```bash
$PLUGIN_ROOT/scripts/wf_issue_status.sh $ISSUE_NUMBER "In Progress"
```

Best-effort: Falls das Issue nicht auf einem Project Board liegt oder der Status-Wechsel fehlschlaegt, wird eine Warnung ausgegeben aber der Workflow laeuft weiter.

### Schritt 5b: Phase Pre-Skip basierend auf Scope

Basierend auf dem gewaehlten Scope, fuehre die entsprechenden jq-Befehle aus:

- Falls Scope = "frontend-only":

```bash
jq '.phases["1"] = {"name":"postgresql-architect","status":"skipped","reason":"Frontend-only scope"} | .context.migrations = {"skipped":true,"reason":"Frontend-only scope"} | .phases["2"] = {"name":"spring-boot-developer","status":"skipped","reason":"Frontend-only scope"} | .context.backendImpl = {"skipped":true,"reason":"Frontend-only scope"}' .workflow/workflow-state.json > tmp && mv tmp .workflow/workflow-state.json
```

- Falls Scope = "backend-only":

```bash
jq '.phases["3"] = {"name":"angular-frontend-developer","status":"skipped","reason":"Backend-only scope"} | .context.frontendImpl = {"skipped":true,"reason":"Backend-only scope"}' .workflow/workflow-state.json > tmp && mv tmp .workflow/workflow-state.json
```

- Falls Scope = "full-stack": Keine Phase Pre-Skips (Architect entscheidet spaeter).

### Schritt 6: Phase 0 starten

Baue den Prompt mit dem Prompt-Builder:

```bash
$PLUGIN_ROOT/scripts/wf_prompt_builder.sh 0
```

Pruefe den Output:

- **Beginnt mit `=== PHASE 0: TEAM PLANNING PROTOCOL ===`** → Fuehre das **Team Planning Protocol** aus (siehe unten)
- **Andernfalls** → Fuehre aus: `Task(bytA:architect-planner, "<OUTPUT>")`

### Schritt 7: STOPP

Sage **"Done."** — NICHTS MEHR TUN!

Der Stop-Hook (`wf_orchestrator.sh`) uebernimmt ab hier den GESAMTEN Workflow:
- Externe Verifikation (GLOB-Checks, State-Checks)
- Phase-Transitions (mark_phase_completed, auto-advance)
- Approval Gates (awaiting_approval, User-Interaktion via wf_user_prompt.sh)
- Ralph-Loop Retries (Agent re-spawn bei fehlgeschlagener Verifikation)
- Phase Skipping (auto-advance durch pre-skipped Phasen)
- Code Review Findings am Approval-Gate (User entscheidet ueber Rollback)
- Phase 7 Push & PR (Orchestrator-Anweisungen)

---

## Phase 0 — Team Planning Protocol

Wenn der Output von `wf_prompt_builder.sh 0` mit `=== PHASE 0: TEAM PLANNING PROTOCOL ===` beginnt,
fuehre das folgende Protokoll aus:

### 1. Marker setzen + Team erstellen

```bash
touch .workflow/.team-planning-active
```

Dann (Reihenfolge EINHALTEN!):

```
TeamDelete  ← Stale Teams aufraeumen (Fehler ignorieren!)
TeamCreate(team_name: <TEAM_NAME aus Protokoll>)
```

Wenn TeamCreate fehlschlaegt (Agent Teams nicht aktiviert): → **Fallback** (siehe unten).

### 2. Alle Agents parallel spawnen

Parse ALLE `--- SPECIALIST: ... ---` Bloecke und den `--- HUB: ... ---` Block.
Spawne ALLE Agents IN PARALLEL in EINEM Aufruf:

```
Fuer JEDEN Block:
  Task(subagent_type: <Agent>, name: <Name>, team_name: <TEAM_NAME>,
       model: <MODEL>, mode: "bypassPermissions", prompt: <Prompt aus Block>)
```

**WICHTIG:** `mode: "bypassPermissions"` ist PFLICHT! Ohne blockiert Claude Code Write/Edit-Operationen
der Teammates und sendet Permission-Requests an den Team-Lead, der damit nichts anfangen kann.

**Beispiel mit 4 Agents (3 Specialists + 1 Hub):**
- Task(bytA:spring-boot-developer, name: "backend", team_name: "bytA-plan-42", model: "sonnet", mode: "bypassPermissions", prompt: "...")
- Task(bytA:angular-fronte