Przejdź do głównej zawartości
Developer Toolkit Developer Toolkit Developer Toolkit

Współpraca zespołowa: Wskazówki 86-95

Jeden członek zespołu osiąga znakomite wyniki z Claude Code. Następny kopiuje konfigurację ze Slacka, serwery MCP po cichu się nie ładują i taka osoba dochodzi do wniosku, że „to tak naprawdę nie działa”. Problemem nigdy nie jest model — chodzi o to, że nic w waszej konfiguracji nie jest współdzielone, wersjonowane ani domyślnie bezpieczne. Rozwiązaniem jest traktowanie CLAUDE.md, .mcp.json, własnych komend i reguł uprawnień jak infrastruktury zespołowej, która żyje w git.

Co z tego wyniesiesz

Dział zatytułowany „Co z tego wyniesiesz”
  • Wersjonowany układ CLAUDE.md + .mcp.json, dzięki któremu świeży klon jest produktywny pierwszego dnia
  • Poprawny, bezpieczny do skopiowania schemat .mcp.json (ten, który Claude Code faktycznie czyta)
  • Prawdziwą politykę permissions allow/ask/deny zamiast niebezpiecznych flag „na wszystko”
  • Współdzielone komendy slash do standupów, przeglądów i wdrożeń
  • Listę kontrolną „Gdy to się zepsuje” na tryby awarii, w które współdzielone konfiguracje zawsze wpadają

Współdzielona infrastruktura i standardy

Dział zatytułowany „Współdzielona infrastruktura i standardy”

Wskazówka 86: Udostępniaj pliki CLAUDE.md zespołowi

Dział zatytułowany „Wskazówka 86: Udostępniaj pliki CLAUDE.md zespołowi”

Stwórz wspólną bazę wiedzy, która przynosi korzyści wszystkim:

  1. Struktura do użycia zespołowego

    project/
    ├── CLAUDE.md                    # Standardy zespołowe
    ├── CLAUDE.local.md             # Osobiste preferencje (git-ignored)
    ├── docs/
    │   └── claude/
    │       ├── onboarding.md       # Przewodnik nowego członka
    │       ├── patterns.md         # Wspólne wzorce
    │       └── troubleshooting.md  # Znane problemy

  2. Integracja kontroli wersji

    Okno terminala
    # Dodaj pliki zespołowe do git
    git add CLAUDE.md
    git add .claude/commands/
    git add .claude/settings.json
    git add .mcp.json
    

    # Ignoruj pliki osobiste
    echo "CLAUDE.local.md" >> .gitignore
    echo ".claude/personal/" >> .gitignore

  3. Regularne aktualizacje — przeprowadzaj retrospektywę CLAUDE.md po każdym sprincie, aby plik nadążał za tym, jak baza kodu faktycznie się rozwija.

Najlepsze praktyki zespołowego CLAUDE.md

  • Dokumentuj uzgodnione wzorce
  • Uwzględniaj decyzje architektoniczne
  • Określ obszary skupienia przeglądu kodu
  • Wylistuj wspólne komendy i przepływy pracy
  • Aktualizuj na podstawie retrospektyw

Przykład sekcji zespołowego CLAUDE.md:

# Standardy kodowania zespołu


## TypeScript
- ZAWSZE używaj trybu strict
- PREFERUJ interfejsy nad typami dla obiektów
- WYMAGAJ jawnych typów zwracanych
- UŻYWAJ branded types dla ID


## Testowanie
- MINIMUM 80% pokrycia dla nowego kodu
- ZAWSZE testuj ścieżki błędów
- UŻYWAJ data-testid dla testów E2E
- MOCKUJ usługi zewnętrzne

Wskazówka 87: Twórz niestandardowe komendy dla całego zespołu

Dział zatytułowany „Wskazówka 87: Twórz niestandardowe komendy dla całego zespołu”

Standardyzuj wspólne przepływy pracy za pomocą współdzielonych komend:

.claude/commands/feature-start.md
Start a new feature following team process:


Feature: $ARGUMENTS


1. Create branch from latest main
2. Update project board
3. Create feature flag (if needed)
4. Set up monitoring
5. Create initial tests
6. Draft PR description


Follow our feature development checklist.

Więcej przykładów komend zespołowych:

.claude/commands/code-review.md
# .claude/commands/hotfix.md
# .claude/commands/release.md
# .claude/commands/incident-response.md
# .claude/commands/performance-check.md

Wskazówka 88: Ustanów polityki uprawnień zespołu

Dział zatytułowany „Wskazówka 88: Ustanów polityki uprawnień zespołu”

Claude Code czyta uprawnienia z obiektu permissions w .claude/settings.json, który zawiera trzy tablice — allow, ask i deny — oraz opcjonalne defaultMode. Reguły mają postać Tool lub Tool(specyfikator), a specyfikatory Bash to globy ze spacjami (Bash(git diff *)), nigdy rozdzielane dwukropkiem. Reguły są oceniane najpierw deny, potem ask, potem allow. Nie istnieje klucz allowedTools/autoAllow/requireApproval/blocked, a narzędzia to Read/Edit/Write/Bash — nie View/Create/Delete.

{
  "permissions": {
    "defaultMode": "acceptEdits",
    "allow": [
      "Read",
      "Edit",
      "Write",
      "Bash(git status)",
      "Bash(git diff *)",
      "Bash(npm run test *)",
      "Bash(npm run lint)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(npm install *)"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Read(./.env)",
      "Read(./.env.*)"
    ]
  }
}

Dokumentuj uzasadnienie uprawnień:

# Wytyczne uprawnień


## Środowisko deweloperskie
- Pełne uprawnienia do szybkiego rozwoju
- Auto-zezwalaj na bezpieczne operacje odczytu
- Ręczne zatwierdzenie dla operacji destrukcyjnych


## Środowisko stagingowe
- Ograniczone do testowania i debugowania
- Brak bezpośrednich modyfikacji bazy danych
- Wdrożenie wymaga zatwierdzenia


## Środowisko produkcyjne
- Dostęp tylko do odczytu
- Wszystkie zmiany przez CI/CD
- Dostęp awaryjny wymaga dwóch zatwierdzeń

Wskazówka 89: Dokumentuj standardy kodowania zespołu

Dział zatytułowany „Wskazówka 89: Dokumentuj standardy kodowania zespołu”

Używaj CLAUDE.md do wymuszania spójności:

# Standardy kodowania zespołu


## Konwencje nazewnictwa
- Komponenty: PascalCase (UserProfile, LoginForm)
- Narzędzia: camelCase (formatDate, validateEmail)
- Stałe: UPPER_SNAKE_CASE (MAX_RETRIES)
- Pliki: kebab-case (user-service.ts)


## Organizacja kodu
\`\`\`
src/
├── components/     # Komponenty UI
├── services/       # Logika biznesowa
├── utils/          # Współdzielone narzędzia
├── types/          # Typy TypeScript
└── constants/      # Stałe aplikacji
\`\`\`


## Obsługa błędów
\`\`\`typescript
// ZAWSZE używaj niestandardowych klas błędów
class ValidationError extends AppError {
  constructor(field: string, message: string) {
    super(`Validation failed for ${field}: ${message}`);
  }
}


// ZAWSZE obsługuj błędy jawnie
try {
  await riskyOperation();
} catch (error) {
  logger.error('Operation failed', { error, context });
  throw new OperationError('User-friendly message');
}
\`\`\`


## Standardy testowe
- Nazewnictwo plików testowych: *.test.ts lub *.spec.ts
- Bloki describe dla klasy/modułu
- Bloki it dla konkretnych zachowań
- Wzorzec AAA: Arrange, Act, Assert

Wskazówka 90: Udostępniaj konfiguracje MCP

Dział zatytułowany „Wskazówka 90: Udostępniaj konfiguracje MCP”

Standardyzuj dostęp do narzędzi w zespole:

// .mcp.json (commitowane do git)
{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_TOKEN": "${GITHUB_TOKEN}"
      }
    },
    "atlassian": {
      "url": "https://mcp.atlassian.com/v1/mcp",
      "headers": {
        "Authorization": "Bearer ${ATLASSIAN_API_TOKEN}"
      }
    },
    "slack": {
      "command": "npx",
      "args": ["@modelcontextprotocol/server-slack"],
      "env": {
        "SLACK_TOKEN": "${SLACK_TOKEN}"
      }
    }
  }
}

Korzyści zespołowego MCP

  • Spójna dostępność narzędzi
  • Współdzielone możliwości automatyzacji
  • Standardowe integracje
  • Zmniejszony czas konfiguracji
  • Zespołowe zyski produktywności

Przepływy pracy i procesy zespołowe

Dział zatytułowany „Przepływy pracy i procesy zespołowe”

Wskazówka 91: Stwórz dokumentację wdrożeniową

Dział zatytułowany „Wskazówka 91: Stwórz dokumentację wdrożeniową”

Pomóż nowym członkom zespołu szybko stać się produktywnymi:

# Przewodnik wdrożenia Claude Code


## Początkowa konfiguracja (30 minut)
1. Zainstaluj Claude Code: `npm install -g @anthropic-ai/claude-code`
2. Skonfiguruj uwierzytelnianie: uruchom `claude` i użyj `/login` w REPL
3. Sklonuj repozytorium zespołu
4. Uruchom skrypt konfiguracji: `./scripts/claude-setup.sh`


## Zadania pierwszego dnia
1. Przeczytaj plik CLAUDE.md zespołu
2. Wypróbuj przykładowe komendy:
   - `/feature-start my-first-feature`
   - `/team-standards`
3. Sparuj z członkiem zespołu na prawdziwym zadaniu
4. Dołącz do kanału #claude-code Slack


## Najlepsze praktyki
- Używaj zespołowej listy dozwolonych uprawnień w .claude/settings.json (allow/ask/deny)
- Rezerwuj --dangerously-skip-permissions wyłącznie dla środowisk sandboxowych/jednorazowych,
  nigdy dla współdzielonej maszyny deweloperskiej ani niczego, co dotyka produkcji
- Czyść kontekst między niepowiązanymi zadaniami
- Sprawdzaj /cost codziennie, aby zrozumieć użycie
- Używaj komend zespołowych z .claude/commands/


## Częste problemy
- Zbyt wiele monitów o uprawnienia: rozszerz listę allow w settings.json, nie pomijaj uprawnień
- MCP nie działa: uruchom `claude mcp list`, a następnie sprawdź zmienne środowiskowe w .mcp.json
- Nowy serwer w .mcp.json wciąż wyświetla monit: `claude mcp reset-project-choices`
- Wysokie koszty: używaj Sonnet 4.6 do rutynowych zadań, Opus 4.8 do trudnych, Fable 5 (`/model fable`) tylko gdy szczytowa inteligencja uzasadnia koszt (zob. [porównanie modeli](/pl/appendices/model-comparison/))


## Zasoby
- Baza wiedzy zespołu: /docs/claude/
- Tutoriale wideo: /onboarding/claude-code/
- Kanał Slack: #claude-code

Wskazówka 92: Ustanów przepływy pracy przeglądu kodu

Dział zatytułowany „Wskazówka 92: Ustanów przepływy pracy przeglądu kodu”

Zintegruj Claude Code z procesem przeglądu:

Oficjalna akcja to anthropics/claude-code-action@v1 (repozytorium: github.com/anthropics/claude-code-action). Steruj zakresem przeglądu przez wejście prompt, a wszelkie opcje CLI przekazuj przez claude_args. Nie istnieje akcja claude-code-review ani wejścia focus:/ignore:.

.github/workflows/claude-review.yml
name: Claude Code Review


on:
  pull_request:
    types: [opened, synchronize]


jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          prompt: |
            Review this PR for security vulnerabilities, logic errors,
            performance issues, and missing tests. Be specific and suggest
            fixes. Ignore style, naming, and documentation — linting owns those.
          claude_args: "--max-turns 10 --model claude-opus-4-8"

Traktuj automatyczny przegląd jako pierwsze przejście, a nie bramkę: Claude Code niezawodnie wychwytuje brakujące testy i luki w obsłudze błędów, podczas gdy ludzie wciąż odpowiadają za osąd architektoniczny i produktowy.

Wskazówka 93: Dziel się naukami i najlepszymi praktykami

Dział zatytułowany „Wskazówka 93: Dziel się naukami i najlepszymi praktykami”

Stwórz kulturę ciągłego doskonalenia:

  1. Cotygodniowe sesje wskazówek

    # Cotygodniowe wskazówki Claude Code
    - 15-minutowy standup zespołowy
    - Jedna osoba dzieli się odkrytą techniką
    - Dokumentuj w bazie wiedzy zespołu
    - Wypróbuj technikę razem

  2. Pokaz przepływu pracy — w REPL uruchom /export session.md, aby zapisać rozmowę do pliku (pomiń nazwę pliku, aby skopiować ją do schowka), a następnie umieść ją w bazie wiedzy zespołu. Pamiętaj, że /export to komenda slash wewnątrz REPL, więc przyjmuje argument z nazwą pliku, a nie przekierowanie powłoki.

  3. Przeglądy optymalizacji kosztów — przeglądaj użycie za pomocą /cost w REPL oraz panelu analityki twojej organizacji, a następnie dobieraj odpowiednie modele do zadań.

  4. Wydobywanie wzorców — przeprowadzaj kwartalne przejście, aby włączać powtarzające się wzorce do CLAUDE.md.

Wskazówka 94: Koordynuj duże wysiłki refaktoryzacyjne

Dział zatytułowany „Wskazówka 94: Koordynuj duże wysiłki refaktoryzacyjne”

Używaj wielu członków zespołu z Claude Code do dużych projektów:

# Plan migracji mikrousług


## Przydzielenie zespołu
- Alicja: Serwis użytkowników (Terminal 1)
- Bob: Serwis zamówień (Terminal 2)
- Karol: Serwis płatności (Terminal 3)
- Danuta: Testy integracyjne (Terminal 4)


## Koordynacja
1. Poranne synchronizowanie przydziału serwisów
2. Współdzielone definicje interfejsów w .claude/shared/
3. Godzinne sprawdzenia na Slack
4. Końcowy test integracyjny


## Konfiguracja Claude Code
\`\`\`bash
# Każdy programista
claude --add-dir ./services/[assigned-service]
\`\`\`


## Współdzielone zasoby
- Kontrakty API: .claude/shared/api/
- Narzędzia testowe: .claude/shared/testing/
- Przewodnik migracji: .claude/shared/migration.md

Narzędzia koordynacji

  • Współdzielony system plików dla kontraktów
  • Integracja Slack dla aktualizacji
  • Gałęzie Git dla izolacji
  • Regularne spotkania synchronizacyjne
  • Automatyczne testy integracyjne

Wskazówka 95: Twórz komendy slash specyficzne dla zespołu

Dział zatytułowany „Wskazówka 95: Twórz komendy slash specyficzne dla zespołu”

Opracuj komendy dopasowane do przepływu pracy twojego zespołu. Zapisz to jako .claude/commands/team/standup.md, a następnie uruchom /team:standup w REPL, aby wygenerować dzienną aktualizację z prawdziwej historii git.

Więcej komend zespołowych:

Okno terminala
# Planowanie sprintu
.claude/commands/team/sprint-plan.md


# Reakcja na incydenty
.claude/commands/team/incident.md


# Notatki wydania
.claude/commands/team/release-notes.md


# Śledzenie długu technicznego
.claude/commands/team/tech-debt.md

Budowanie kultury Claude Code

Dział zatytułowany „Budowanie kultury Claude Code”

Udana adopcja zespołowa wymaga więcej niż tylko konfiguracji technicznej:

Przywództwo i rzecznictwo

Dział zatytułowany „Przywództwo i rzecznictwo”
  • Zidentyfikuj championów Claude Code
  • Dziel się historiami sukcesu
  • Świętuj zwycięstwa produktywności
  • Otwarcie adresuj obawy

Szkolenia i wsparcie

Dział zatytułowany „Szkolenia i wsparcie”
  • Regularne warsztaty
  • Sesje programowania w parach
  • Dokumentacja wewnętrzna
  • Kanał wsparcia Slack

Metryki i ulepszenia

Dział zatytułowany „Metryki i ulepszenia”
  • Śledź metryki produktywności
  • Monitoruj koszt na programistę
  • Mierz ulepszenia jakości kodu
  • Regularne retrospektywy

Wspólne wzorce adopcji

Dział zatytułowany „Wspólne wzorce adopcji”
Tydzień 1: Indywidualna eksploracja
Tydzień 2: Dzielenie się odkryciami
Tydzień 3: Standardyzacja przepływów pracy
Tydzień 4: Pełna adopcja zespołowa


Skupienie: Szybkie eksperymentowanie

Metryki sukcesu zespołu

Dział zatytułowany „Metryki sukcesu zespołu”

Śledź te wskaźniki udanej adopcji zespołowej:

  1. Wzrost prędkości: Typowo 2-4x
  2. Jakość kodu: Mniej błędów w produkcji
  3. Pokrycie testami: Wyższe i bardziej kompleksowe
  4. Dokumentacja: Zawsze aktualna
  5. Czas wdrożenia: 50% redukcji
  6. Satysfakcja programistów: Zwiększone zaangażowanie

Gdy to się zepsuje

Dział zatytułowany „Gdy to się zepsuje”

Współdzielona konfiguracja zawodzi na kilka przewidywalnych sposobów. Oto jak rozpoznać każdy z nich i się z niego wydostać.

  1. Serwery z .mcp.json członka zespołu się nie ładują. Niemal zawsze to zły klucz najwyższego poziomu — Claude Code czyta mcpServers, a nie servers. Potwierdź działające serwery za pomocą claude mcp list. Jeśli klucz jest poprawny, ale serwera brakuje, przyczyną zwykle jest nierozwinięta zmienna środowiskowa (${GITHUB_TOKEN}) — zobacz następny punkt.

  2. Nowy serwer w zasięgu projektu wciąż prosi o zatwierdzenie albo zatwierdziłeś go raz i chcesz zdecydować ponownie. Claude Code pyta, zanim zaufa serwerom z projektowego .mcp.json. Uruchom claude mcp reset-project-choices, aby wyczyścić te decyzje, a następnie ponownie otwórz projekt i zatwierdź świadomie.

  3. .mcp.json działa na jednej maszynie, a na innej nie. Konfiguracja odwołuje się do zmiennych środowiskowych (${GITHUB_TOKEN}, ${SLACK_TOKEN}), które istnieją w jednym profilu powłoki, a w drugim nie. Udokumentuj wymagane zmienne we wdrożeniu i niech każdy programista wyeksportuje je w swoim pliku rc powłoki; nigdy nie zakodowuj sekretów na sztywno w commitowanym .mcp.json.

  4. Konflikty scalania CLAUDE.md przy każdym PR. Podziel go: trzymaj stabilne, rzadko zmieniające się standardy w commitowanym CLAUDE.md, a osobiste lub szybko zmieniające się notatki przenieś do ignorowanego przez git CLAUDE.local.md. Rozwiązuj konflikty sekcjami, a nie wierszami — to plik prozą, więc preferuj zachowanie obu reguł, chyba że są sprzeczne.

  5. Członek zespołu działa na --dangerously-skip-permissions i zedytował coś, czego nie powinien. Przestań rekomendować tę flagę dla współdzielonych maszyn. Wdróż politykę permissions allow/ask/deny ze Wskazówki 88 w .claude/settings.json i ustaw disableBypassPermissionsMode na "disable" w zarządzanych ustawieniach dla wszystkiego blisko produkcji.

Następne kroki

Dział zatytułowany „Następne kroki”

Po opanowaniu współpracy zespołowej jesteś gotowy na ostatni zestaw wskazówek. Przejdź do Rozwiązywanie problemów i najlepsze praktyki po częste problemy i sprawdzone wzorce długoterminowego sukcesu.

Zobacz co nowego na platformie.

Polityka prywatności Regulamin