Scorecard Tech Leada: klucz odpowiedzi

Klucz odpowiedzi do Scorecardu Tech Leada przypisuje każde z 25 pytań Scorecardu Tech Leada do strony, która poprawia tę odpowiedź, i nazywa dowód potrzebny do odpowiedzi za 3 punkty. Jest napisany dla tech leada lub engineering managera, który ma wynik jednego zespołu i musi zdecydować, które trzy luki zamknąć najpierw i jak udowodnić, że się zamknęły.

Wynik mówi Poziom 2 · W parze, 31 punktów na 75, z nagłówkiem „Team Enabler”. Dwie osoby uruchamiają agentów równolegle i oddają czyste pull requesty; pozostała szóstka wkleja kod do czatu i przynosi ci diffy do czytania. Kolejka code review jest wąskim gardłem, a 25 stron z omówieniami pytań to za dużo lektury przed poniedziałkiem. Ten klucz wybiera trzy pierwsze pytania i mówi, co liczy się jako „zrobione”.

Jak liczy się wynik Scorecardu Tech Leada

25 pytań jednokrotnego wyboru, od 0 do 3 punktów każde, razem 75 punktów, w sześciu sekcjach: wspólne standardy (12 punktów), review i bramki jakości (12), wdrożenie i adopcja (15), workflow w skali zespołu (12), rozwój i mentoring (12) oraz operacje zespołu (12). Strona wyników dodaje listę największych ryzyk, plan na 30, 60 i 90 dni po podaniu adresu e-mail oraz kartę Popraw te odpowiedzi, która linkuje stronę dla każdej odpowiedzi poniżej 3 punktów. Te linki to kolumna Zacznij od poniżej.

Co oznacza każdy z przedziałów poziomów 1–4 dla zespołu?

Przedziały zapożyczają nazwy z drabiny autonomii, ale mierzą coś innego: praktyki wokół pracy jednego zespołu z agentami, tak jak je deklarujesz. Drabina mierzy, jak każda pętla dostarcza zmergowane zmiany. Jedna mapa pokazuje, jak umieścić zespół według tego, co naprawdę trafia na produkcję, więc sprawdź nią zadeklarowany przedział. Odpowiadaj za typowego programistę w zespole, nie za najmocniejszego.

Przedział	Punkty	Nagłówek na stronie wyników	Pierwszy ruch
Poziom 1 · Z pomocą	0–18	Samotny Wilk: u ciebie działa, teraz spraw, by działało w zespole	Sekcja 1: zacommituj jeden wspólny, wersjonowany plik reguł do najaktywniejszego repozytorium.
Poziom 2 · W parze	19–37	Team Enabler: wyspy spójności, połącz je	Sekcja 2: te same automatyczne bramki na każdym pull requeście, niezależnie od tego, kto lub co go napisało.
Poziom 3 · Menedżer review	38–56	Force Multiplier: zespół pracuje w jeden sposób	Sekcje 4 i 6: równoległe agenty z limitem współbieżności oraz koszty i sekrety z przypisanym właścicielem.
Poziom 4 · Menedżer specyfikacji	57–75	Org Amplifier: samopodtrzymujący się system zespołu	Naucz tego systemu inny zespół. Pozostaje odejście zespołu od czytania każdego diffa.

Jak wybrać trzy pierwsze pytania do poprawy?

1. Podziel punkty każdej sekcji przez jej maksimum. 6 na 15 we wdrożeniu (40%) to większa luka niż 6 na 12 w rozwoju (50%).
2. Weź dwie sekcje z najniższym odsetkiem. W każdej wybierz pytanie, w którym twoja odpowiedź jest najdalej od 3 punktów.
3. Jeśli review i bramki jakości (pytania 5–8) mają mniej niż połowę punktów, niech jedno z trzech pytań pochodzi z tej sekcji, nawet gdy inna sekcja wypada gorzej. Więcej pracy agentów przy słabych bramkach tylko wydłuża kolejkę code review. Z tego samego powodu workflow w skali zespołu (pytania 14–17) podnoś dopiero wtedy, gdy bramki trzymają.
4. Dla każdego pytania zapisz w pliku planu poniżej docelową odpowiedź i artefakt, który ją udowodni. Wyznacz jednego właściciela na pytanie.
5. Wypełnij scorecard ponownie po czterech tygodniach. Porównuj odsetki sekcji, nie przedział: pytanie, które przeszło z 1 na 3 punkty, rzadko zmienia przedział, ale widać je w jego sekcji.

Zacommituj plan do głównego repozytorium zespołu, obok wspólnych reguł agentów, żeby jego zmiany przechodziły review jak każda inna:

# .agents/scorecard-plan.yaml — jeden wpis na każde pytanie, nad którym pracuje zespół
- question: 7          # Jakie automatyczne bramki działają na kodzie z AI?
  current_points: 1    # "Tylko lint"
  target_points: 3     # "Warstwowo: AI review + CI + bramki pokrycia"
  evidence: "Branch protection wymaga lintu, typów, testów, pokrycia i agenta review; trzy zmergowane PR-y agenta mają wszystkie pięć na zielono"
  owner: "priya"
  check_on: 2026-10-26

Która strona odpowiada na które pytanie?

Każda tabela podaje pytanie, stronę linkowaną przez kartę wyników (Zacznij od), drugą stronę, która idzie głębiej, i dowód, który daje 3 punkty. Deklaruj 3 punkty tylko wtedy, gdy możesz ten dowód podlinkować.

Wspólne standardy i kontekst (pytania 1–4, 12 punktów)

#	Pytanie	Zacznij od · Idź głębiej	Dowód na 3 punkty
1	Czy zespół dzieli wspólny config agenta?	Wspólne reguły agentów · Zwięzły kontekst repozytorium	Przejrzany AGENTS.md lub CLAUDE.md w każdym aktywnym repozytorium, zmieniany wyłącznie przez pull requesty
2	Jak kontekst projektu jest dostępny dla agenta każdej osoby?	Dokumentacja jako kontekst · Współpraca w zespole	Dokumenty architektury i konwencji podlinkowane z pliku reguł i aktualizowane w tym samym pull requeście co kod, który opisują
3	Czy wzorce promptów i workflow są dzielone w zespole?	Wspólne skille · Budowa własnych skilli	Katalog skilli lub komend w repozytorium, z jednym właścicielem na wpis
4	Jak szybko nowa osoba jest produktywna z waszym setupem?	Onboarding programistów · Ścieżka dewelopera	Jedno polecenie, które konfiguruje świeży klon, i spisana ścieżka pierwszego tygodnia, którą przeszła ostatnio zatrudniona osoba

Review i bramki jakości (pytania 5–8, 12 punktów)

#	Pytanie	Zacznij od · Idź głębiej	Dowód na 3 punkty
5	Jak spójna jest jakość kodu z AI w całym zespole?	Bramki jakości kodu · Funkcje dopasowania architektury	Te same wymagane checki na każdym pull requeście i reguły architektury egzekwowane w CI
6	Czy macie standardy review specyficzne dla PR-ów z AI?	Automatyzacja review PR w zespole · Kolejka code review	Spisany standard dla pull requestów agentów, którego mechaniczne części egzekwuje CI
7	Jakie automatyczne bramki działają na kodzie z AI?	Warstwowe review pull requestów · Pakiet dowodów	Branch protection, które przed merge’em wymaga CI, bramki pokrycia i review AI
8	Jak łapiecie kod wiarygodny, ale błędny, przed merge’em?	Test: daj sesji pętlę informacji zwrotnej · Wyłapywanie kodu wiarygodnego, ale błędnego	Testy, które agent musi przejść, zanim skończy, plus przebieg review adwersarialnego z osobnym promptem

Wdrożenie i adopcja (pytania 9–13, 15 punktów)

#	Pytanie	Zacznij od · Idź głębiej	Dowód na 3 punkty
9	Jaki odsetek zespołu aktywnie używa narzędzi agentowych?	Poziom adopcji w zespole · Onboarding i adopcja w zespole	Codzienne użycie przez ponad 80% zespołu, odczytane z raportu użycia, a nie z podniesionych rąk
10	Jak przebiegła adopcja w twoim zespole?	Mapa drogi adopcji · Projektowanie pilotażu	Spisane wdrożenie z repozytorium pilotażowym, osobą odpowiedzialną za wsparcie i kryterium wyjścia
11	Czy mierzysz wpływ AI?	Panel metryk AI · Frameworki metryk	Dashboard z poziomem bazowym sprzed wdrożenia i celem, przeglądany w ustalonym terminie
12	Jak sceptycy i seniorzy podchodzą do AI?	Onboarding i adopcja w zespole · Sceptycy i seniorzy	Seniorzy są autorami lub zatwierdzającymi wspólnych reguł i bramek
13	Kto odpowiada za decyzje i budżet na narzędzia?	Polityka narzędziowa · Zarządzanie kosztami	Spisany właściciel, pozycja w budżecie i termin przeglądu

Workflow w skali zespołu (pytania 14–17, 12 punktów)

#	Pytanie	Zacznij od · Idź głębiej	Dowód na 3 punkty
14	Czy zespół używa równoległych agentów lub worktree?	Równoległość w zespole · Równoległe agenty w worktree	Opisana konwencja worktree z limitem współbieżności na programistę
15	Jak zautomatyzowana jest pętla PR, review i merge?	Ograniczona pętla review i poprawek PR · Automatyzacja review PR w zespole	Agent otwiera pull request i poprawia uwagi z review przez ograniczoną liczbę rund; merge robi człowiek
16	Czy używacie wspólnych serwerów MCP w zespole?	Wewnętrzne serwery MCP · Niezbędne serwery MCP	Konfiguracja MCP w repozytorium, z właścicielem każdego serwera
17	Jak ogarniacie duże, przekrojowe zmiany?	Strategie dla milionowych baz kodu · Backlog przygotowany dla agentów	Plan przejrzany przed wykonaniem i zmiana podzielona na zadania, które agent może skończyć i zweryfikować

Rozwój i mentoring (pytania 18–21, 12 punktów)

#	Pytanie	Zacznij od · Idź głębiej	Dowód na 3 punkty
18	Jak podnosisz umiejętności AI zespołu?	Ścieżka dewelopera · Podnoszenie kompetencji zespołu	Program z ćwiczeniami i review ich wyników oraz zapis, kto go ukończył
19	Czy prowadzicie wewnętrzny knowledge-sharing o workflow AI?	Dzielenie się wiedzą · Transformacja workflow	Cykliczna sesja w kalendarzu i artefakty, które każda z nich wytworzyła
20	Gdy ktoś znajdzie świetny workflow, jak się rozchodzi?	Wspólne skille · Skille agentów	Workflow istnieje jako skill w repozytorium i został pokazany na sesji
21	Jak utrzymujesz zespół na bieżąco, gdy narzędzia się zmieniają?	Roadmapa narzędzi AI · Jak utrzymać zespół na bieżąco	Osoba, która przegląda nowe wydania, piaskownica do ich sprawdzania i zapisane decyzje „wdrażamy” albo „pomijamy”

Operacje i governance zespołu (pytania 22–25, 12 punktów)

#	Pytanie	Zacznij od · Idź głębiej	Dowód na 3 punkty
22	Jak zarządzasz kosztem AI w całym zespole?	Zarządzanie kosztami · Routing modeli oparty na dowodach	Koszt per osoba lub per repozytorium przeglądany co miesiąc i spisane wytyczne wyboru modelu
23	Jak obsługujecie sekrety i uprawnienia agentów i MCP w zespole?	Bezpieczeństwo MCP · Tożsamość agentów i sekrety	Sekrety z menedżera sekretów, osobny token o ograniczonym zakresie dla każdej integracji agenta i spisana polityka
24	Czy macie politykę tego, czego AI nie może dotykać?	Governance i autonomia · Hooki jako deterministyczne zabezpieczenia	Spisane ograniczenia egzekwowane przez ustawienia uprawnień lub hooki, a nie tylko przez instrukcje w prompcie
25	Jak decydujecie, na jakich narzędziach zespół się standaryzuje?	Polityka narzędziowa · Porównanie narzędzi	Próba na zadaniach własnego zespołu, wybrany standard i termin ponownej oceny

Jak udowodnić wyższą odpowiedź bez czytania każdego diffa?

Każda odpowiedź za 3 punkty wskazuje artefakt, a nie zamiar: eksport branch protection, config w repozytorium, dashboard z poziomem bazowym, zmergowane pull requesty z pakietem dowodów. Właściciel z pliku planu przygotowuje artefakt, a drugi inżynier sprawdza go przed ponownym wypełnieniem scorecardu. Czytanie dowodów zamiast kodu wyjaśnia, dlaczego to sprawdzenie zastępuje czytanie każdego diffa.

Agent może zebrać większość tych dowodów z repozytorium, pod warunkiem że działa tylko do odczytu. Nie polegaj na samym prompcie; uruchom agenta w trybie, który nie edytuje plików (sposób dla każdego narzędzia poniżej).

Claude Code

Rozpocznij sesję w trybie planowania, w którym agent analizuje kod bez edytowania plików: claude --permission-mode plan (sprawdzone w claude --help, v2.1.283). Bez tej flagi interaktywne sesje od v2.1.283 (kanał latest) zwykle startują w trybie auto, który może edytować pliki. Wklej jeden z promptów poniżej.

Codex

Uruchom prompt nieinteraktywnie w piaskownicy tylko do odczytu: codex exec --sandbox read-only "PROMPT" (sprawdzone w codex exec --help, v0.157.1), gdzie PROMPT to jeden z promptów poniżej. To starsza flaga piaskownicy; profile uprawnień (beta) wybierają to samo przez -c default_permissions=":read-only". Te dwa systemy się nie łączą, więc używaj jednego z nich.

Cursor

Przełącz agenta w Plan Mode, który przygotowuje plan przed napisaniem jakiegokolwiek kodu, i nie zatwierdzaj kroku budowania; wklej jeden z promptów poniżej.

Tekst promptu jest taki sam we wszystkich trzech narzędziach.

Prompt do skopiowania: dowody dla standardów i bramek (pytania 1–8)

Read-only task. Do not edit files, run git commands that write, or call any network API.
I am answering Tech Lead Scorecard questions 1-8 for this repository. List the evidence that exists today:
- Agent rules files (AGENTS.md, CLAUDE.md, .cursor/rules, nested copies): where they are, when each last changed (git log -1), and whether they reference architecture or convention docs
- Shared skills or commands directories, and who is named as owner, if anyone
- A bootstrap script or setup command for a fresh clone
- CI workflow files: each job that runs on pull requests and what makes it fail (lint, types, tests, coverage threshold, AI review)
- PR templates or checks that ask for test evidence or a risk description
Cite each item as path:line. Then, per question, state the answer on the 0-3 scale the evidence supports and what is missing for 3. Write "not found" rather than guessing.

Prompt do skopiowania: dowody dla operacji zespołu (pytania 16, 22–24)

Read-only task. Do not edit files, print secret values, or call any network API.
I am answering Tech Lead Scorecard questions 16, 22, 23 and 24 for this repository. Find:
- MCP configuration files (.mcp.json, .cursor/mcp.json, .codex/config.toml): each server, how it authenticates, and whether a credential appears inline instead of as an environment variable reference
- Agent permission settings (.claude/settings.json, Codex sandbox or permission settings, Cursor rules): what is denied and what is allowed
- Hooks or CI steps that block agent changes to protected paths, production config, migrations or secrets
- Any written guidance on model choice or spend
Cite each item as path:line and name any credential by file and key only. Per question, state the answer on the 0-3 scale the evidence supports and what is missing for 3.

Branch protection, wymagani recenzenci i raporty użycia są w ustawieniach hostingu Git i w konsolach administracyjnych narzędzi, nie w repozytorium. Wyeksportuj je i dołącz do tego samego wpisu w planie.

Kiedy wynik Scorecardu Tech Leada wprowadza w błąd?

• Oceniasz zamiary. Checklista review, której nikt nie egzekwuje, dostaje tę samą odpowiedź co wymagany check, jeśli na to pozwolisz. Naprawa: każdą odpowiedź, której nie potwierdzasz podlinkowanym artefaktem, oceń o punkt niżej; ta suma to twój prawdziwy punkt startu.
• Odpowiadasz za dwie najmocniejsze osoby. Ich równoległe agenty nie robią z zespołu poziomu 3. Naprawa: odpowiadaj za typowego programistę i sprawdź to raportem użycia z pytania 9.
• Workflow urósł przed bramkami. Więcej równoległych agentów i automatycznie otwieranych pull requestów przy tej samej przepustowości review wydłuża kolejkę, aż recenzenci zaczynają akceptować bez patrzenia. Naprawa: ogranicz liczbę równoczesnych pull requestów agentów na osobę, najpierw popraw pytania 6–8, dopiero potem podnieś limit.
• Seniorzy zostali obejści, a nie włączeni. Adopcja rośnie, pytanie 12 stoi na 1 punkcie, a seniorzy po cichu recenzują wszystko jeszcze raz. Naprawa: oddaj im własność reguł i bramek, tak jak opisuje strona o sceptykach i seniorach.
• Przedział stał się celem. Skok o cały przedział w cztery tygodnie zwykle oznacza optymistyczne odpowiedzi. Naprawa: sprawdź każdą zmienioną odpowiedź z jej artefaktem i raportuj przełożonemu odsetki sekcji, a nie przedział.

Dokąd iść dalej z wynikiem Scorecardu Tech Leada

Wypełnij Scorecard Tech Leada 25 pytań, około 8 minut: przedział poziomów 1–4, największe ryzyka i plan na 30, 60 i 90 dni.

Ścieżka tech leada Uporządkowany plan czytania: wspólny harness, projekt weryfikacji, przepustowość review.

Prowadzenie zespołu Wdrożenie, wspólny harness, review i przepływ pracy oraz ludzie: sekcja, na której opiera się ten klucz.

Scorecard CTO: klucz odpowiedzi Te same decyzje w skali organizacji, dla lidera, któremu raportujesz plan.