Tryb TEAM - Orkiestrowana implementacja z subtaskami

Przegląd

Tryb TEAM implementuje szczegółowy plan poprzez:

Utworzenie priorytetowych subtasków
Orkiestrację równoległego wykonania
Zarządzanie zależnościami między subtaskami
Automatyczną weryfikację (task, visual, run)
Generowanie grafów zależności (Mermaid)

INPUT:  task.md (szczegółowy plan)
          ↓
      /team command
          ↓
    Claude tworzy subtaski:
    - START (inicjalizacja)
    - P0 (krytyczne)
    - P1 (ważne)
    - P2 (weryfikacja)
    - P3 (opcjonalne)
    - END (finalizacja)
          ↓
    Wykonanie z dependency resolution
          ↓
OUTPUT: - Zaimplementowany kod
        - Subtaski w /subtasks/
        - Dependency graph (Mermaid)
        - Diffs w /diffs/

Kiedy używać TEAM?

Używaj TEAM gdy:

Masz szczegółowy plan implementacji (np. z PLAN mode)
Zadanie wymaga modyfikacji wielu plików
Potrzebujesz równoległego wykonania subtasków
Chcesz mieć dependency graph implementacji
Implementacja ma wyraźne fazy (P0, P1, P2, P3)

NIE używaj TEAM gdy:

Zadanie jest trywialne (1-2 linie kodu)
Nie masz szczegółowego planu (użyj najpierw PLAN)
Wszystko mieści się w jednym subtagsku (użyj zwykłego Claude)

Przepływ TEAM mode

1. Przygotowanie (prepare_task_spec.sh)

bash

bash /workspace/files/helpers/prepare_task_spec.sh

Co robi:

Tworzy /task/.spec/{TASK_ID}/ directory
Kopiuje /task/task.md → /task/.spec/{TASK_ID}/task.md
Przygotowuje workspace dla TEAM mode
Tworzy strukturę katalogów dla artefaktów

Struktura po prepare:

/task/
  .spec/
    DEV-1_7/
      task.md           # Kopia szczegółowego planu

2. Implementacja z subtaskami (/plugin-codegen:team)

bash

/plugin-codegen:team .spec/DEV-1_7/task.md

Przepływ Claude:

markdown

1. READ task.md (szczegółowy plan z PLAN mode)

2. ANALIZA priorytetów:
   - Priority P0 → subtaski MUST
   - Priority P1 → subtaski SHOULD
   - Priority P2 → subtaski VERIFICATION
   - Priority P3 → subtaski OPTIONAL

3. UTWORZENIE SUBTASKÓW:
   - Każdy subtask = osobny plik w /subtasks/{priority}/todo/
   - Format: {role}_{hash}.md
   - Dependencies między subtaskami

4. WYKONANIE orkiestrowane:
   START → P0 → P1 → P2 → P3 → END
   (równoległe wykonanie w ramach priorytetu)

5. GENEROWANIE ARTEFAKTÓW:
   - Diffs w /diffs/
   - Status subtasków
   - Verification reports

Przykład task.md (INPUT):

markdown

# Zmiana Koloru Paska Super Administratora

## 📝 Plan Implementacji

### Priority P0: Zmiana Koloru Paska

**Subtask 1: Zmień kolor w SCSS**
Zmiana background-color w container.component.scss

**Weryfikacja:**
- [ ] Pasek jest ciemnoniebieskim (#1a3a5c)

### Priority P1: Wykorzystanie Design Tokens

**Subtask 2: Dodaj token do _colors.scss**
Dodanie $admin-bar-super-admin: #1a3a5c;

**Subtask 3: Użyj tokena w komponencie**
Import i użycie tokena zamiast hardcoded color

### Priority P2: Build Verification

**Subtask 4: Uruchom build**
npm run build i weryfikacja

### Priority P3: Documentation

**Subtask 5: Dodaj komentarz**
Dokumentacja w kodzie

3. Rozwiązywanie zależności (/plugin-codegen:resolve_dependencies)

bash

/plugin-codegen:resolve_dependencies /task

Co robi:

Skanuje wszystkie subtaski w /task/subtasks/
Czyta pole Dependencies z każdego subtasku
Weryfikuje czy zależności istnieją
Tworzy plik dependencies.json

Przykład dependencies.json:

json

{
  "subtasks": {
    "dev_a1b2c3d4": {
      "file": "subtasks/P0/done/dev_a1b2c3d4.md",
      "role": "dev",
      "priority": "P0",
      "dependencies": [],
      "status": "done"
    },
    "test_e5f6g7h8": {
      "file": "subtasks/P2/done/test_e5f6g7h8.md",
      "role": "test",
      "priority": "P2",
      "dependencies": ["dev_a1b2c3d4"],
      "status": "done"
    }
  },
  "execution_order": [
    ["dev_a1b2c3d4"],
    ["test_e5f6g7h8"]
  ]
}

4. Mapa zależności (create_dependency_map.sh)

bash

bash /workspace/files/helpers/create_dependency_map.sh DEV-1_7

Co robi:

Czyta dependencies.json
Generuje dependency_map.txt (tekstowa reprezentacja)
Pokazuje execution order i dependencies

Przykład dependency_map.txt:

=== DEPENDENCY MAP: DEV-1_7 ===

Execution Order:
  Wave 1: dev_a1b2c3d4
  Wave 2: test_e5f6g7h8

Dependencies:
  dev_a1b2c3d4 → (none)
  test_e5f6g7h8 → dev_a1b2c3d4

Status:
  Total: 2 subtasks
  Done: 2
  In Progress: 0
  Todo: 0

5. Graf zależności Mermaid (create_mermaid_graph.sh)

bash

bash /workspace/files/helpers/create_mermaid_graph.sh DEV-1_7

Co robi:

Czyta dependencies.json
Generuje dependency_graph.mmd (Mermaid syntax)
Wizualizacja grafu zależności

Przykład dependency_graph.mmd:

6. Weryfikacje

task_verification (weryfikacja subtasków)

bash

/plugin-codegen:task_verification /task

Sprawdza czy wszystkie subtaski są w done/
Weryfikuje czy wszystkie checklisty są zaznaczone
Raport: task_verification_report.md

visual_verification (weryfikacja wizualna)

bash

/plugin-codegen:visual_verification /task

Tworzy screenshoty przed/po (jeśli UI)
Porównuje wizualnie rezultaty
Raport: visual_verification_report.md

run_verification (weryfikacja runtime)

bash

/plugin-codegen:run_verification /task

Uruchamia build (npm run build)
Uruchamia testy (npm test)
Raport: run_verification_report.md

7. Git operations

bash

# Commit
bash /workspace/files/helpers/git_commit.sh DEV-1_7 "feat: Change admin bar color"

# Create PR (opcjonalnie)
bash /workspace/files/helpers/create_pr.sh DEV-1_7

start_commands dla TEAM mode

json

{
  "ai": {
    "start_commands": [
      {
        "id": "prepare_task_spec",
        "catalog": "START",
        "executor": "bash",
        "command": "bash /workspace/files/helpers/prepare_task_spec.sh",
        "dependencies": []
      },
      {
        "id": "team_implement",
        "catalog": "START",
        "executor": "claude",
        "command": "/plugin-codegen:team .spec/DEV-1_7/task.md",
        "dependencies": ["prepare_task_spec"]
      },
      {
        "id": "resolve_dependencies",
        "catalog": "START",
        "executor": "claude",
        "command": "/plugin-codegen:resolve_dependencies /task",
        "dependencies": ["team_implement"]
      },
      {
        "id": "create_dependency_map",
        "catalog": "START",
        "executor": "bash",
        "command": "bash /workspace/files/helpers/create_dependency_map.sh DEV-1_7",
        "dependencies": ["resolve_dependencies"]
      },
      {
        "id": "create_dependency_graph",
        "catalog": "START",
        "executor": "bash",
        "command": "bash /workspace/files/helpers/create_mermaid_graph.sh DEV-1_7",
        "dependencies": ["create_dependency_map"]
      },
      {
        "id": "task_verification",
        "catalog": "VERIFY",
        "executor": "claude",
        "command": "/plugin-codegen:task_verification /task",
        "dependencies": ["team_implement"]
      },
      {
        "id": "visual_verification",
        "catalog": "VERIFY",
        "executor": "claude",
        "command": "/plugin-codegen:visual_verification /task",
        "dependencies": ["team_implement"]
      },
      {
        "id": "run_verification",
        "catalog": "VERIFY",
        "executor": "claude",
        "command": "/plugin-codegen:run_verification /task",
        "dependencies": ["team_implement"]
      },
      {
        "id": "git_status",
        "catalog": "GIT",
        "executor": "bash",
        "command": "git status",
        "dependencies": ["run_verification"]
      },
      {
        "id": "git_diff",
        "catalog": "GIT",
        "executor": "bash",
        "command": "git diff > /task/diffs/git_diff_full.txt",
        "dependencies": ["git_status"]
      },
      {
        "id": "git_commit",
        "catalog": "GIT",
        "executor": "bash",
        "command": "bash /workspace/files/helpers/git_commit.sh DEV-1_7 'feat: Change admin bar color to dark blue'",
        "dependencies": ["git_diff"]
      }
    ]
  }
}

Struktura subtasków

Format pliku subtasku

markdown

# Production Build Test and SCSS Compilation Validation

## Role
test

## Command
/plugin-team:test .

## Priority
P2

## Objective
Run npm start to test development build, check for SCSS compilation errors,
and ensure the new dark blue admin bar color (#1a3a5c) is properly compiled.

## Dependencies
dev_b1462b9c

## Acceptance Criteria
- [ ] npm start executes without errors
- [ ] SCSS compiles successfully
- [ ] No compilation warnings for admin bar styles
- [ ] Development server starts on http://localhost:4200
- [ ] Admin bar color is visible in browser

## Verification
- Build output shows no SCSS errors
- Console shows successful compilation
- Browser displays dark blue admin bar

Pola subtasku:

# Title - Krótki tytuł subtasku
## Role - Rola wykonująca (dev, test, qa, deploy, etc.)
## Command - Komenda Claude do wykonania
## Priority - P0/P1/P2/P3
## Objective - Szczegółowy opis celu
## Dependencies - Lista ID subtasków (np. dev_a1b2c3d4)
## Acceptance Criteria - Checklista do weryfikacji
## Verification - Jak zweryfikować sukces

Role subtasków:

Implementacja:

frontend - Implementacja UI (Angular, React, Vue, Templ)
backend - Implementacja API (Laravel, Go, Express, FastAPI)
database - Bazy danych, migracje, optymalizacja
integration - Integracje zewnętrzne (API, webhooks, OAuth)
migration - Migracje danych, ETL
refactor - Refaktoryzacja kodu

Testy i QA:

test - Testy automatyczne (unit, integration, e2e)
qa - Quality assurance, manual testing
performance - Testy wydajnościowe
accessibility - Testy dostępności (WCAG)

Infrastruktura:

setup - Konfiguracja środowiska
deploy - Deployment, build, CI/CD

Review:

critic - Code critic
reviewer_tech - Technical review
reviewer_product - Product review

Analiza:

analytic_business - Analiza biznesowa
analytic_system - Analiza systemowa

Biznes:

po - Product Owner
business - Business acceptance
verify - Weryfikacja końcowa
finalize - Finalizacja, dokumentacja

Priorytety subtasków:

P0 - START (Inicjalizacja)

Przygotowanie workspace
Fetch z Jira/GitHub
Setup środowiska

P0 - MUST (Krytyczne)

Minimalna działająca funkcjonalność
Core business logic
Bez tego feature nie działa

P1 - SHOULD (Ważne)

Best practices
Refactoring
Wzorce (Design Tokens, services)

P2 - VERIFICATION (Weryfikacja)

Build & compilation
Testy automatyczne
Linting, code quality

P3 - OPTIONAL (Nice-to-have)

Dokumentacja
Komentarze
Accessibility
Performance optimizations

END - Finalizacja

Git commit
Create PR
Powiadomienia

Struktura katalogów subtasków

/task/
  subtasks/
    START/
      todo/
      in_progress/
      done/
        init_a1b2c3d4.md
    P0/
      todo/
      in_progress/
      done/
        dev_b2c3d4e5.md
        dev_c3d4e5f6.md
    P1/
      todo/
      in_progress/
      done/
        dev_d4e5f6g7.md
        refactor_e5f6g7h8.md
    P2/
      todo/
      in_progress/
      done/
        test_f6g7h8i9.md
        qa_g7h8i9j0.md
    P3/
      todo/
      in_progress/
      done/
        docs_h8i9j0k1.md
    END/
      todo/
      in_progress/
      done/
        git_i9j0k1l2.md

Cykl życia subtasku:

todo/ → in_progress/ → done/

todo/ - Subtask utworzony, oczekuje na wykonanie
in_progress/ - Subtask w trakcie wykonania
done/ - Subtask zakończony, wszystkie kryteria spełnione

Dynamiczne tworzenie subtasków

Wszystkie role mogą dynamicznie tworzyć nowe subtaski podczas wykonywania zadania, gdy wykryją potrzebę zmian w innym obszarze.

Jak tworzyć subtaski:

bash

bash /workspace/files/helpers/create_team_subtask.sh \
  "$TASK_ID" \
  "PRIORITY" \
  "ROLE" \
  "$(openssl rand -hex 4)" \
  "TITLE" \
  "OBJECTIVE" \
  "DEPENDENCIES"

Przykład - Frontend potrzebuje API:

bash

bash /workspace/files/helpers/create_team_subtask.sh \
  "$TASK_ID" \
  "P0" \
  "backend" \
  "$(openssl rand -hex 4)" \
  "Create GET /api/users/:id/profile endpoint" \
  "Frontend UserProfile needs endpoint returning {avatar, bio, settings}. Currently 404." \
  "None"

Typowe scenariusze:

Rola źródłowa	Tworzy dla	Priorytet	Przykład
frontend	backend	P0	Brak endpoint API
backend	database	P0	Brakująca migracja
test	frontend/backend	P0	Test failuje
reviewer_tech	backend	P0	Problem bezpieczeństwa
performance	backend	P1	N+1 queries
accessibility	frontend	P1	Brak ARIA labels

Dependency Management

Typy zależności:

Sequential (kolejność):

dev_a → dev_b → test_c

dev_b czeka na dev_a
test_c czeka na dev_b

Parallel (równolegle):

    ┌─ dev_a ─┐
dev → dev_b ──→ test
    └─ dev_c ─┘

dev_a, dev_b, dev_c wykonują się równocześnie
test czeka na wszystkie

Diamond (złożone):

       dev_a
      ↙     ↘
  dev_b    dev_c
      ↘     ↙
      test_d

dev_b i dev_c zależą od dev_a
test_d zależy od dev_b AND dev_c

Przykład Dependencies w subtasku:

markdown

## Dependencies
dev_a1b2c3d4, dev_b2c3d4e5

Oznacza: Ten subtask wymaga zakończenia obu subtasków przed rozpoczęciem.

Artefakty TEAM mode

Po zakończeniu TEAM tworzy:

/task/
  task.md                           # Szczegółowy plan (INPUT)

  .spec/
    DEV-1_7/
      task.md                       # Kopia planu

  subtasks/
    START/done/...
    P0/done/...
    P1/done/...
    P2/done/...
    P3/done/...
    END/done/...

  diffs/
    dev_a1b2c3d4.diff
    dev_b2c3d4e5.diff
    git_diff_full.txt

  dependencies.json                 # Mapa zależności (JSON)
  dependency_map.txt                # Mapa zależności (TEXT)
  dependency_graph.mmd              # Graf zależności (Mermaid)

  task_verification_report.md       # Raport weryfikacji subtasków
  visual_verification_report.md     # Raport weryfikacji wizualnej
  run_verification_report.md        # Raport weryfikacji runtime

Komendy Claude w TEAM mode

/plugin-codegen:team

Parametry:

bash

/plugin-codegen:team <task_spec_path>

Przykład:

bash

/plugin-codegen:team .spec/DEV-1_7/task.md

Co robi:

Czyta szczegółowy plan z task_spec_path
Analizuje priorytety (P0, P1, P2, P3)
Tworzy subtaski dla każdego elementu planu
Wykonuje subtaski w kolejności priorytetów
Zarządza dependency resolution
Generuje diffs dla każdego subtasku
Finalizuje implementację

/plugin-codegen:resolve_dependencies

Parametry:

bash

/plugin-codegen:resolve_dependencies <task_path>

Co robi:

Skanuje /task/subtasks/**/*.md
Parsuje pole Dependencies z każdego subtasku
Buduje graf zależności
Weryfikuje czy wszystkie dependencies istnieją
Generuje dependencies.json

/plugin-team:* (role-specific commands)

Komendy:

/plugin-team:dev - Implementacja kodu
/plugin-team:test - Uruchamianie testów
/plugin-team:qa - Quality assurance
/plugin-team:deploy - Deployment
/plugin-team:refactor - Refactoring

Przykład:

bash

/plugin-team:dev .

Wykonuje implementację w bieżącym katalogu zgodnie z Objective i Acceptance Criteria subtasku.

Weryfikacje

1. Task Verification

Komenda:

bash

/plugin-codegen:task_verification /task

Sprawdza:

Czy wszystkie subtaski są w done/
Czy wszystkie checklisty (Acceptance Criteria) są zaznaczone
Czy brak subtasków w todo/ lub in_progress/

Raport:

markdown

# Task Verification Report

## Status: ✅ PASSED

### Subtasks Summary:
- Total: 5
- Done: 5 (100%)
- In Progress: 0
- Todo: 0

### Acceptance Criteria:
- dev_a1b2c3d4: ✅ All 3 criteria met
- dev_b2c3d4e5: ✅ All 2 criteria met
- test_c3d4e5f6: ✅ All 4 criteria met
- test_d4e5f6g7: ✅ All 2 criteria met
- docs_e5f6g7h8: ✅ All 1 criteria met

## Conclusion:
All subtasks completed successfully. Ready for git commit.

2. Visual Verification (UI changes)

Komenda:

bash

/plugin-codegen:visual_verification /task

Sprawdza (jeśli UI):

Porównanie screenshotów przed/po
Zgodność z mockupami/wymaganiami
Brak regresji wizualnych

Raport:

markdown

# Visual Verification Report

## Status: ✅ PASSED

### Changes Detected:
- Admin bar color: #ff0000 → #1a3a5c ✅

### Screenshots:
- Before: /task/screenshots/admin_bar_before.png
- After: /task/screenshots/admin_bar_after.png

### Visual Regression:
- No layout shifts detected ✅
- No unintended color changes ✅
- Consistent across viewports ✅

## Conclusion:
Visual changes match requirements. No regressions detected.

3. Run Verification (Build & Tests)

Komenda:

bash

/plugin-codegen:run_verification /task

Sprawdza:

Build compilation (npm run build)
Tests execution (npm test)
Linting (npm run lint)

Raport:

markdown

# Run Verification Report

## Status: ✅ PASSED

### Build:

npm run build ✓ Build completed successfully (23.4s) ✓ No compilation errors ✓ No warnings


### Tests:

npm test ✓ 127 tests passed ✓ 0 tests failed ✓ Coverage: 87%


### Linting:

npm run lint ✓ No linting errors


## Conclusion:
All verifications passed. Code is ready to commit.

Przykład: Pełny przepływ TEAM

INPUT (task.md z PLAN):

markdown

# Change Admin Bar Color

## Priority P0: Core Change
**Subtask 1:** Change SCSS color

## Priority P1: Best Practices
**Subtask 2:** Add design token
**Subtask 3:** Use token in component

## Priority P2: Verification
**Subtask 4:** Build verification

TEAM wykonuje:

1. Tworzy subtaski:

subtasks/
  P0/todo/dev_a1b2c3d4.md  ← "Change SCSS color"
  P1/todo/dev_b2c3d4e5.md  ← "Add design token"
  P1/todo/dev_c3d4e5f6.md  ← "Use token"
  P2/todo/test_d4e5f6g7.md ← "Build verification"

2. Wykonuje P0:

P0/in_progress/dev_a1b2c3d4.md
  ↓ (modyfikuje container.component.scss)
P0/done/dev_a1b2c3d4.md ✅

3. Wykonuje P1 (równolegle):

P1/in_progress/dev_b2c3d4e5.md + P1/in_progress/dev_c3d4e5f6.md
  ↓ (dodaje token + używa tokena)
P1/done/dev_b2c3d4e5.md ✅ + P1/done/dev_c3d4e5f6.md ✅

4. Wykonuje P2:

P2/in_progress/test_d4e5f6g7.md
  ↓ (npm run build)
P2/done/test_d4e5f6g7.md ✅

5. Generuje artefakty:

dependencies.json
dependency_map.txt
dependency_graph.mmd
task_verification_report.md
run_verification_report.md

6. Git operations:

bash

git add .
git commit -m "feat(admin): Change admin bar color to dark blue"

Workflow: PLAN → TEAM sequence

┌─────────────────────────────────────────────────────────────┐
│ 1. PLAN mode                                                │
│    Input: task.md (prosta wersja)                          │
│    Output: task_plan.md (szczegółowa)                      │
└─────────────────────────────────────────────────────────────┘
                            ↓
┌─────────────────────────────────────────────────────────────┐
│ 2. User review (opcjonalnie)                               │
│    Weryfikacja i akceptacja task_plan.md                   │
└─────────────────────────────────────────────────────────────┘
                            ↓
┌─────────────────────────────────────────────────────────────┐
│ 3. TEAM mode                                                │
│    Input: task_plan.md (szczegółowa)                       │
│    Process: Subtaski + Implementation + Verification       │
│    Output: Zaimplementowany kod + artefakty                │
└─────────────────────────────────────────────────────────────┘

Zalety sekwencji:

Transparency: Plan jest widoczny PRZED implementacją
Control: User może zmodyfikować plan przed TEAM
Context: TEAM ma pełen kontekst z eksploracji PLAN
Traceability: Każdy subtask ma jasne pochodzenie z planu

FAQ

Q: Czy TEAM może pracować bez PLAN? A: Tak, jeśli task.md jest już szczegółowy. PLAN nie jest wymagany.

Q: Co jeśli subtask nie powiedzie się? A: Pozostaje w in_progress/. Można ręcznie debugować i przenieść do done/.

Q: Jak dodać własny subtask ręcznie? A: Utwórz plik w /task/subtasks/{priority}/todo/ zgodnie z formatem.

Q: Czy mogę pominąć P1-P3? A: Tak. TEAM wykonuje wszystkie, ale możesz usunąć subtaski przed uruchomieniem.

Q: Jak działa równoległe wykonanie subtasków? A: Subtaski w ramach tego samego priorytetu bez dependencies wykonują się równolegle.

Q: Co to jest dependency graph? A: Wizualizacja Mermaid pokazująca kolejność i zależności subtasków.

Q: Gdzie są helper scripts? A: docker/{worker}/files/helpers/

prepare_task_spec.sh - przygotowanie .spec/
create_dependency_map.sh - mapa zależności (tekst)
create_mermaid_graph.sh - graf zależności (Mermaid)
git_commit.sh - commit zmian

Q: Jak długo trwa TEAM? A: Zależy od liczby subtasków. Zwykle 5-30 minut dla typowego zadania.

Q: Co jeśli build nie przechodzi? A: run_verification wykryje błąd. Można debugować i naprawić przed git commit.

Tryb TEAM - Orkiestrowana implementacja z subtaskami ​

Przegląd ​

Kiedy używać TEAM? ​

Przepływ TEAM mode ​

1. Przygotowanie (prepare_task_spec.sh) ​

2. Implementacja z subtaskami (/plugin-codegen:team) ​

3. Rozwiązywanie zależności (/plugin-codegen:resolve_dependencies) ​

4. Mapa zależności (create_dependency_map.sh) ​

5. Graf zależności Mermaid (create_mermaid_graph.sh) ​

6. Weryfikacje ​

task_verification (weryfikacja subtasków) ​

visual_verification (weryfikacja wizualna) ​

run_verification (weryfikacja runtime) ​

7. Git operations ​

start_commands dla TEAM mode ​

Struktura subtasków ​

Format pliku subtasku ​

Pola subtasku: ​

Role subtasków: ​

Priorytety subtasków: ​

Struktura katalogów subtasków ​

Cykl życia subtasku: ​

Dynamiczne tworzenie subtasków ​

Jak tworzyć subtaski: ​

Przykład - Frontend potrzebuje API: ​

Typowe scenariusze: ​

Dependency Management ​

Typy zależności: ​

Przykład Dependencies w subtasku: ​

Artefakty TEAM mode ​

Komendy Claude w TEAM mode ​

/plugin-codegen:team ​

/plugin-codegen:resolve_dependencies ​

/plugin-team:* (role-specific commands) ​

Weryfikacje ​

1. Task Verification ​

2. Visual Verification (UI changes) ​

3. Run Verification (Build & Tests) ​

Przykład: Pełny przepływ TEAM ​

INPUT (task.md z PLAN): ​

TEAM wykonuje: ​

Workflow: PLAN → TEAM sequence ​

FAQ ​

Tryb TEAM - Orkiestrowana implementacja z subtaskami

Przegląd

Kiedy używać TEAM?

Przepływ TEAM mode

1. Przygotowanie (prepare_task_spec.sh)

2. Implementacja z subtaskami (/plugin-codegen:team)

3. Rozwiązywanie zależności (/plugin-codegen:resolve_dependencies)

4. Mapa zależności (create_dependency_map.sh)

5. Graf zależności Mermaid (create_mermaid_graph.sh)

6. Weryfikacje

task_verification (weryfikacja subtasków)

visual_verification (weryfikacja wizualna)

run_verification (weryfikacja runtime)

7. Git operations

start_commands dla TEAM mode

Struktura subtasków

Format pliku subtasku

Pola subtasku:

Role subtasków:

Priorytety subtasków:

Struktura katalogów subtasków

Cykl życia subtasku:

Dynamiczne tworzenie subtasków

Jak tworzyć subtaski:

Przykład - Frontend potrzebuje API:

Typowe scenariusze:

Dependency Management

Typy zależności:

Przykład Dependencies w subtasku:

Artefakty TEAM mode

Komendy Claude w TEAM mode

/plugin-codegen:team

/plugin-codegen:resolve_dependencies

/plugin-team:* (role-specific commands)

Weryfikacje

1. Task Verification

2. Visual Verification (UI changes)

3. Run Verification (Build & Tests)

Przykład: Pełny przepływ TEAM

INPUT (task.md z PLAN):

TEAM wykonuje:

Workflow: PLAN → TEAM sequence

FAQ