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

Sprawdź swój poziom — za darmo Wypróbuj za darmo Wypróbuj Odblokuj wszystkie przewodniki Odblokuj Otwórz przewodniki Czytaj
Menu nawigacji
Wypróbuj za darmo Sprawdź swój poziom — za darmo Odblokuj wszystkie przewodniki Otwórz przewodniki Zaloguj się

Współpraca zespołowa ze wspólną konfiguracją Claude Code

EN

Poziom 3 Poradnik Zaktualizowano

Współpraca zespołowa w Claude Code polega na commitowaniu konfiguracji agenta do repozytorium: CLAUDE.md i .claude/rules/ na instrukcje, .claude/settings.json na reguły uprawnień i hooki, .mcp.json na serwery MCP oraz .claude/skills/ na wspólne przepływy pracy. Świeży klon zachowuje się wtedy u wszystkich tak samo, a każdą zmianę w tej konfiguracji pilnuje code review.

Ta strona jest dla tech leada, który odpowiada za konfigurację Claude Code w repozytorium, i dla deweloperów, którzy w nim pracują. Jednej osobie wszystko działa; następna kopiuje fragment konfiguracji z czatu, serwery MCP nigdy się nie łączą, agent pyta o zgodę przy każdym npm test i w końcu pada wniosek, że narzędzie nie działa. Różnicą nigdy nie był model. Nic z działającego setupu nie było współdzielone, przejrzane ani przetestowane.

Co daje zespołowi wspólna konfiguracja Claude Code

Dział zatytułowany „Co daje zespołowi wspólna konfiguracja Claude Code”
  • Jasny podział na to, co commituje repozytorium, i to, co każdy trzyma lokalnie.
  • Politykę uprawnień w .claude/settings.json i .mcp.json bez sekretów, gotowe do commita.
  • Przepływy pracy zespołu jako skille, które każdy klon dostaje jako tę samą komendę /nazwa.
  • Job w CI i pięciominutowy smoke test, które dowodzą, że wspólna konfiguracja działa, bez ponownego czytania plików.
  • Tabelę naprawczą na typowe awarie wspólnej konfiguracji.

Co commitować, a co zostawić dla siebie

Dział zatytułowany „Co commitować, a co zostawić dla siebie”

Claude Code łączy ustawienia z pięciu poziomów, od najważniejszego: managed, wiersz poleceń, .claude/settings.local.json, .claude/settings.json i ~/.claude/settings.json. Klucze tablicowe, takie jak permissions.allow, są sklejane między poziomami. Dzięki temu zespół commituje wspólne minimum, a każdy dokłada do niego własne wyjątki. Pełne zasady pierwszeństwa opisuje strona o konfiguracji Claude Code.

PlikCommitować?Co zawiera
CLAUDE.md (lub AGENTS.md)TakKomendy build i test, konwencje oraz to, co Claude robi źle, jeśli mu nie powiesz
.claude/rules/*.mdTakInstrukcje dla jednej części drzewa, ładowane dopiero, gdy Claude czyta pasującą ścieżkę
CLAUDE.local.mdNie, dodaj do .gitignoreTwój URL sandboksa, konto testowe i lokalny port; w repozytorium, które trzyma tylko AGENTS.md, zacznij go od @AGENTS.md
.claude/settings.jsonTakReguły uprawnień, hooki i projektowe marketplace’y pluginów
.claude/settings.local.jsonNieTwoje prywatne reguły allow; Claude Code dopisuje plik do globalnych wykluczeń gita, gdy tworzy go po raz pierwszy
.mcp.jsonTakSerwery MCP z odwołaniami ${VAR} zamiast poświadczeń
.claude/skills/<nazwa>/SKILL.mdTakPrzepływy zespołu wywoływane jako /<nazwa>
.claude/agents/*.mdTakSubagenci z własnym promptem, narzędziami i modelem
managed-settings.jsonNie w repozytorium aplikacjiPolityka organizacji, której nikt nie nadpisze; zobacz integrację w przedsiębiorstwie

Dwa ograniczenia wyznaczają, co repozytorium może ustawić. Po pierwsze, plik projektu nie wybierze zespołowi startowego trybu uprawnień: defaultMode ustawione na auto lub bypassPermissions jest w .claude/settings.json ignorowane i musi trafić do ustawień użytkownika albo managed (dokumentacja Claude Code, sprawdzone na v2.1.283). Repozytorium kontroluje reguły. Po drugie, zacommitowane reguły allow i marketplace’y pluginów zadeklarowane w pliku czekają, aż każda osoba zaakceptuje okno zaufania do workspace’u, a reguły deny i ask działają od razu, bo tylko ograniczają. Od v2.1.283 (oba kanały wydań na 2026-10-12) sesje interaktywne na obsługiwanych modelach startują w trybie auto, w którym akcje ocenia klasyfikator zamiast pytać ciebie, chyba że któryś plik ustawień ustawia disableAutoMode. Pasująca reguła ask nadal wymusza pytanie także w trybie auto, więc zacommitowane reguły zachowują sens w każdym trybie.

Zbuduj wspólną konfigurację agenta w jednym pull requeście

Dział zatytułowany „Zbuduj wspólną konfigurację agenta w jednym pull requeście”

Dostarcz całą konfigurację agenta jako jeden przejrzany pull request, żeby zespół przyjął przetestowany zestaw, a nie pięć plików, które spływają w różnym czasie.

  1. Napisz krótki CLAUDE.md. Cel Anthropic to mniej niż 200 linii na plik. Zostaw tylko to, co Claude inaczej zrobiłby źle: dokładne komendy testów i lintera, granice katalogów i zakazane wzorce. Reguły dla jednego obszaru, na przykład migracji albo komponentów Reacta, przenieś do .claude/rules/ z frontmatterem paths. Plik, w którym każda linia jest potrzebna, pokazuje strona o systemie pamięci.

  2. Zacommituj politykę uprawnień. Zezwól na komendy, które projekt uruchamia codziennie, pytaj przed wszystkim, co wychodzi poza maszynę, i zablokuj sekrety:

    .claude/settings.json
    {
      "$schema": "https://json.schemastore.org/claude-code-settings.json",
      "permissions": {
        "allow": [
          "Bash(npm run lint)",
          "Bash(npm run test *)",
          "Bash(npx tsc --noEmit)",
          "Bash(git status)",
          "Bash(git diff *)",
          "Bash(git log *)"
        ],
        "ask": [
          "Bash(git push *)",
          "Bash(npm install *)",
          "Bash(npm publish *)"
        ],
        "deny": [
          "Read(./.env)",
          "Read(./.env.*)",
          "Read(./secrets/**)",
          "Bash(npm run deploy *)"
        ]
      }
    }

    Reguła ma postać Tool lub Tool(specyfikator). Claude Code sprawdza najpierw deny, potem ask, potem allow, a bardziej szczegółowa reguła allow nie wytnie wyjątku z szerszej reguły deny. Reguła deny dla Bash dopasowuje tekst komendy, który pisze Claude, więc sh -c 'npm run deploy' przez nią przejdzie. Traktuj ją jak łapacz literówek, a poświadczenia do wdrożeń trzymaj w ogóle poza środowiskami deweloperów.

  3. Zacommituj .mcp.json ze zmiennymi, nie sekretami. Claude Code rozwija ${VAR} i ${VAR:-default} w polach command, args, env, url i headers:

    .mcp.json
    {
      "mcpServers": {
        "github": {
          "type": "http",
          "url": "https://api.githubcopilot.com/mcp/",
          "headers": { "Authorization": "Bearer ${GITHUB_PAT}" }
        },
        "sentry": { "type": "http", "url": "https://mcp.sentry.dev/mcp" },
        "linear": { "type": "http", "url": "https://mcp.linear.app/mcp" }
      }
    }

    Sentry i Linear uwierzytelniają się przez OAuth przy pierwszym użyciu, więc nie potrzebują żadnej zmiennej. Wypisz każdą zmienną, której wymaga serwer, w CLAUDE.md albo w README. Wybór serwerów i zakresy omawia konfiguracja MCP w Claude Code.

  4. Dodaj powtarzalne przepływy zespołu jako skille. Skill w .claude/skills/<nazwa>/SKILL.md staje się komendą /<nazwa> dla każdego, kto sklonuje repozytorium. Istniejące pliki .claude/commands/*.md nadal działają, ale nowe przepływy pisz jako skille. Skill do standupu poniżej to kompletny przykład.

  5. Chroń te pliki przez CODEOWNERS. Te pliki decydują, co agent może uruchomić na maszynie każdej osoby w zespole, więc ich zmiana wymaga takiego samego review jak konfiguracja CI:

    .github/CODEOWNERS
    CLAUDE.md        @acme/platform-leads
    /.claude/        @acme/platform-leads
    /.mcp.json       @acme/platform-leads @acme/security
    /.github/        @acme/platform-leads

    Zastąp @acme/platform-leads i @acme/security własnymi zespołami. Linia /.github/ obejmuje bramkę w CI opisaną niżej, a CODEOWNERS blokuje merge dopiero wtedy, gdy ochrona gałęzi albo ruleset wymaga review właściciela kodu.

  6. Zignoruj pliki prywatne. Dodaj CLAUDE.local.md do .gitignore. Claude Code wyklucza .claude/settings.local.json sam tylko wtedy, gdy sam tworzy ten plik; jeśli utworzyłeś go ręcznie, też go zignoruj.

Udostępnij przepływ zespołu jako skill

Dział zatytułowany „Udostępnij przepływ zespołu jako skill”

Skille zamieniają rytuały, które zespół powtarza, w jedną komendę o jednym zachowaniu. Ten skill pisze podsumowanie na standup z historii gita, a nie z pamięci. disable-model-invocation: true sprawia, że Claude uruchamia go tylko wtedy, gdy ktoś wpisze /standup, a allowed-tools z góry zatwierdza komendy gita tylko do odczytu, i to wyłącznie na tę jedną turę.

.claude/skills/standup/SKILL.md
---
name: standup
description: Write my daily standup update from real git activity.
disable-model-invocation: true
allowed-tools: Bash(git log *) Bash(git branch *) Bash(git status)
---
Write my standup from real signals, not guesses.


Yesterday: run git log --author="$(git config user.name)" --since="1 day ago"
--oneline --all and summarise what changed in 3 to 5 bullets, grouped by feature.


Today: read the current branch name and git status, and list the 2 or 3 most
likely next tasks.


Blockers: name any failing check you saw in this session, or say "none".
Keep the whole update under 120 words. Do not invent work that is not in git.

Argumenty, kontrolę wywołania i opcję context: fork, która przekazuje ciężką pracę subagentowi, opisuje strona o własnych komendach i skillach. Do review zacznij od wbudowanego skilla /code-review i dopisz reguły zespołu we własnym skillu, jak pokazuje automatyzacja code review, zamiast pisać recenzenta od zera.

Żeby współdzielić skille, hooki i serwery MCP między wieloma repozytoriami, spakuj je jako plugin w prywatnym marketplace. Zarejestruj marketplace w repozytorium komendą claude plugin marketplace add acme/acme-plugins --scope project, która zapisuje go w .claude/settings.json, i zacommituj ten plik. Każda osoba zobaczy marketplace dopiero wtedy, gdy zaufa folderowi. Budowę i hosting opisuje strona o zespołowym marketplace pluginów.

W skrypcie albo w obrazie CI instaluj bez otwierania /plugin. claude plugin install PLUGIN --marketplace acme/acme-plugins instaluje plugin z tego marketplace’u i najpierw dodaje marketplace do twoich ustawień użytkownika, gdy go brakuje (v2.1.292, na 2026-10-12 tylko kanał latest). --config KEY=VALUE ustawia opcję zadeklarowaną w manifeście pluginu i można go powtarzać; forma SERVER.KEY=VALUE ustawia opcję, którą deklaruje dołączony serwer MCP .mcpb, i wymaga v2.1.285 lub nowszej (oba kanały na 2026-10-12). claude plugin configure PLUGIN pokazuje opcje pluginu i które z nich są jeszcze nieustawione, a jego flaga --values-stdin zapisuje wartości z obiektu JSON na standardowym wejściu (v2.1.285). Wynika to z claude plugin install --help i claude plugin configure --help w wersji 2.1.296, sprawdzonych 2026-10-12. Zastąp PLUGIN nazwą pluginu. Poświadczenie przekaż do --values-stdin z magazynu sekretów zamiast wpisywać je po --config, żeby nie trafiło do historii powłoki ani logów.

Skąd wiesz, że wspólna konfiguracja działa?

Dział zatytułowany „Skąd wiesz, że wspólna konfiguracja działa?”

Wspólna konfiguracja jest coś warta tylko wtedy, gdy ładuje się na każdej maszynie. Udowodnij to dwoma sprawdzeniami, które nie wymagają czytania plików linijka po linijce.

Bramka w CI przy każdej zmianie konfiguracji agenta. Ten job działa bez sekretów i bez uruchamiania Claude Code, więc jest bezpieczny dla pull requestów z dowolnej gałęzi:

.github/workflows/claude-config.yml
name: claude-config
on:
  pull_request:
    paths: ['CLAUDE.md', 'AGENTS.md', '.claude/**', '.mcp.json']
permissions:
  contents: read
jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
        with:
          persist-credentials: false
      - name: Settings and MCP config parse as JSON
        run: for f in .claude/settings.json .mcp.json; do [ ! -f "$f" ] || jq empty "$f"; done
      - name: No literal credentials in .mcp.json
        run: |
          if [ -f .mcp.json ] && grep -nE '(ghp_|github_pat_|sk-|xox[abp]-)[A-Za-z0-9_-]{10,}' .mcp.json; then
            echo "::error::.mcp.json contains a literal token. Use \${VAR} instead."
            exit 1
          fi
      - name: Secrets stay denied
        run: |
          [ ! -f .claude/settings.json ] || jq -e '.permissions.deny | index("Read(./.env)")' .claude/settings.json
      - name: CLAUDE.md and AGENTS.md stay under 200 lines
        run: |
          for f in CLAUDE.md AGENTS.md; do
            [ ! -f "$f" ] || test "$(wc -l < "$f")" -le 200
          done

Każdy krok pada na prawdziwej regresji: zabłąkany przecinek, który psuje ustawienia wszystkim, wklejony token, pull request usuwający regułę deny dla .env albo CLAUDE.md lub AGENTS.md, który rośnie, aż Claude ignoruje jego połowę. Każdy krok pomija plik, którego repozytorium nie ma, więc repozytorium z samym AGENTS.md albo bez .mcp.json przechodzi bramkę. Przy wyzwalaczu pull_request GitHub uruchamia ten plik workflow z merge refu pull requesta, więc pull request może zmienić albo usunąć sprawdzenie, którym jest oceniany. Bramka trzyma tylko wtedy, gdy /.github/ jest w CODEOWNERS, a review właściciela kodu jest wymagane, jak w kroku 5.

Smoke test na maszynie każdej osoby. Nowa osoba w zespole albo ktoś, komu setup działa dziwnie, uruchamia to raz po sklonowaniu:

  1. W terminalu uruchom claude mcp list. Zatwierdzone serwery z .mcp.json przechodzą health check; serwer oznaczony jako oczekujący na zatwierdzenie nie został jeszcze zaakceptowany w sesji interaktywnej i nie jest połączony.
  2. Uruchom claude w repozytorium i zaakceptuj okno zaufania do workspace’u.
  3. Uruchom /permissions. Każda reguła jest wypisana razem z plikiem ustawień, z którego pochodzi, więc potwierdzisz, że reguły zespołu przyszły z .claude/settings.json.
  4. Uruchom /context, żeby zobaczyć, ile okna kontekstu zajmują CLAUDE.md, skille i narzędzia MCP, zanim zacznie się jakakolwiek praca.
  5. Wklej poniższy prompt i porównaj odpowiedź z plikami.

Jeśli odpowiedź podaje złą komendę testów, poprawka należy do CLAUDE.md, a nie do kolejnej wiadomości w czacie. Zmiany w konfiguracji agenta zatwierdza tech lead, który jest właścicielem wpisów w CODEOWNERS. Bramka w CI i smoke test to dowody, na podstawie których podpisuje zmianę.

Utrzymuj CLAUDE.md w zgodzie z kodem

Dział zatytułowany „Utrzymuj CLAUDE.md w zgodzie z kodem”

CLAUDE.md opisujący konwencje sprzed kwartału jest gorszy niż brak pliku, bo Claude mu ufa. Po każdym sprincie zrób krótki przegląd i traktuj jego wynik jak każdy inny pull request.

Wdróż nową osobę na wspólny setup

Dział zatytułowany „Wdróż nową osobę na wspólny setup”

Gdy konfiguracja agenta jest w repozytorium, onboarding jest krótki i taki sam dla wszystkich:

  1. Zainstaluj Claude Code natywnym instalatorem albo menedżerem pakietów zespołu, jak opisuje instalacja Claude Code, i zaloguj się komendą /login w sesji.
  2. Wyeksportuj zmienne środowiskowe, do których odwołuje się .mcp.json, w profilu powłoki, nigdy w zacommitowanym pliku.
  3. Sklonuj repozytorium, uruchom w nim claude, zaakceptuj okno zaufania i zatwierdź projektowe serwery MCP.
  4. Przeprowadź smoke test opisany wyżej.
  5. Zostań przy domyślnym modelu. Zasada zespołu: zacznij od domyślnego modelu Claude Code, podnieś effort przez /effort, zanim zmienisz model, i zmieniaj model dopiero wtedy, gdy wskażą to twoje własne ewaluacje. Aktualne modele i ceny są w przeglądzie modeli; /usage pokazuje twoje wydatki i limity.

Uzgodnijcie jeden kanał wydań dla zespołu. Claude Code ma kanał latest i kanał stable, który jest za nim mniej więcej o tydzień (2026-10-12: v2.1.296 i v2.1.287), więc funkcje od v2.1.288 mogą się między nimi różnić. Ustaw autoUpdatesChannel raz, najlepiej w ustawieniach managed, żeby dwie osoby nigdy nie debugowały dwóch różnych wersji. Jeśli chcesz w pełni identycznego zestawu narzędzi, uruchamiaj Claude Code w zespołowym dev containerze.

Kiedy psuje się wspólna konfiguracja Claude Code

Dział zatytułowany „Kiedy psuje się wspólna konfiguracja Claude Code”
ObjawPrawdopodobna przyczynaNaprawa
Projektowe serwery MCP nigdy się nie łączą u nowej osobyNikt ich nie zatwierdził w sesji interaktywnej albo ta osoba je odrzuciłaUruchom claude w repozytorium i zatwierdź; claude mcp reset-project-choices czyści wcześniejsze decyzje, więc pytanie pojawi się znowu
.mcp.json działa na jednej maszynie, a na innej nie${VAR} nie jest ustawiona w powłoce, z której uruchomiono claude, albo brakuje komendy serwera (npx, Docker)Uruchom komendę serwera w zwykłym terminalu, wyeksportuj zmienną i zrestartuj; wypisz wymagane zmienne w CLAUDE.md
Reguły allow zespołu wyglądają na ignorowane i każdy test wymaga zgodyOsoba nie zaakceptowała okna zaufania, więc zacommitowane reguły allow nie są jeszcze aktywneZrestartuj w repozytorium, zaakceptuj okno i sprawdź /permissions
Ktoś ustawia "defaultMode": "auto" w .claude/settings.json i nic się nie zmieniaUstawienia projektu nie mogą ustawić auto ani bypassPermissions jako trybu domyślnegoUstaw tryb w ustawieniach użytkownika albo wymuś go dla wszystkich w ustawieniach managed
CLAUDE.md ma konflikty w każdym pull requeście i ciągle rośnieJeden plik trzyma wszystko, łącznie z prywatnymi notatkamiPrzenieś reguły dla obszarów do .claude/rules/ z paths, prywatne notatki do CLAUDE.local.md, a konflikty rozwiązuj sekcjami
Zespołowe reguły z AGENTS.md znikają u jednej osobyUtworzyła CLAUDE.local.md, który przełącza Claude Code na pliki CLAUDE.mdZaimportuj rdzeń przez @AGENTS.md na początku CLAUDE.local.md albo trzymaj prywatne notatki w ~/.claude/CLAUDE.md
Ktoś pracuje z --dangerously-skip-permissions na współdzielonej maszynieZa dużo pytań o zgodę, więc obszedł politykęRozszerz listę allow; ustaw disableBypassPermissionsMode: "disable" w ustawieniach managed, a bypass stosuj tylko w jednorazowym kontenerze z ograniczoną siecią
Wybrałeś „Yes, and don’t ask again”, a ta sama komenda dalej pyta o zgodęTen wybór zapisał regułę allow w twoim pliku lokalnym, a lokalna reguła allow nie wygrywa z regułą ask z ustawień projektu ani managedZostaw pytanie, jeśli reguła ask jest celowa; w przeciwnym razie zmień regułę projektu w przejrzanym pull requeście
Job w CI z claude -p pada na komendach, które obejmuje lista allow zespołuclaude -p nigdy nie pokazuje okna zaufania, więc zacommitowane reguły permissions.allow nie działają w folderze, któremu nikt nie zaufałPrzekaż komendy przez --allowedTools w workflow, a poświadczenia joba ogranicz do odczytu; zobacz Claude Code w CI/CD
.claude/ z obcego repozytorium uruchamia hooki, łączy serwery MCP albo zatwierdza narzędzia, których się nie spodziewaszHooki i blok env działają po zaufaniu folderowi; w claude -p działają bez żadnego kroku zaufania, a każdy serwer z .mcp.json łączy się bez pytania; allowed-tools skilla nigdy nie zależy od zaufania (dokumentacja uprawnień Claude Code, v2.1.283)Przeczytaj .claude/settings.json, .claude/skills/ i .mcp.json, zanim zaufasz obcemu repozytorium albo uruchomisz na nim skrypt; zobacz automatyzację hookami

Błędy spoza wspólnej konfiguracji, na przykład z uwierzytelnianiem, siecią albo instalacją, opisuje rozwiązywanie problemów z Claude Code.

Co dalej ze wspólną konfiguracją Claude Code

Dział zatytułowany „Co dalej ze wspólną konfiguracją Claude Code”
Wszystkie 577 przewodników Bezpłatne zasoby: Porównaj narzędzia Słownik Według roli

Autor:

Zobacz co nowego na platformie.

Polityka prywatności Regulamin Ustawienia cookie