Kiro: pliki specyfikacji, testy właściwości i Kiro Crew

Kiro to platforma AWS do tworzenia oprogramowania z agentami: IDE, CLI, Web, Mobile (preview) i open source’owy Kiro Crew, wszystkie na jednym harnessie agenta. Wyróżniają ją pliki specyfikacji sprawdzane analizą wymagań, testy oparte na właściwościach, które weryfikują kod względem specyfikacji, oraz trwały, harmonogramowany workspace Crew. Zespoły na Claude Code, Codex lub Cursorze mogą przejąć wszystkie trzy bez zmiany narzędzia.

Sprawdzone 26 września 2026

Zweryfikowane w publicznych repozytoriach Kiro na GitHubie (README kirodotdev/Kiro, README kirodotdev/KiroCrew, przewodnik instalacji, dokumentacja konfiguracji i changelog), w npm (cc-sdd 3.1.0, fast-check 4.10.2), w PyPI (hypothesis) i w marketplace Trail of Bits (property-based-testing 1.2.2). Strona kiro.dev była niedostępna ze środowiska, w którym powstał ten tekst, więc szczegóły plików specyfikacji Kiro pochodzą ze źródeł wtórnych i są tak oznaczone.

Ktoś z zespołu pokazuje Kiro: jednozdaniowy pomysł zamienia się w requirements.md, design.md i tasks.md, agent wskazuje dwa sprzeczne wymagania, zanim napisze choć linijkę kodu, a gotowa funkcja przychodzi z testami właściwości powiązanymi z identyfikatorami wymagań. Twój zespół pracuje w Claude Code i Cursorze, a ty musisz zdecydować, czy to uzasadnia drugie narzędzie, czy metodę da się przenieść bez produktu.

Co zyskujesz z tego przewodnika po Kiro

• Datowaną mapę pięciu powierzchni Kiro i funkcji, które ją wyróżniają.
• Wyjaśnienie, jak przepływ specyfikacji Kiro łączy się ze sprawdzaniem poprawności (w Kiro: „correctness”) za pomocą testów opartych na właściwościach i które elementy są zweryfikowane.
• Opis Kiro Crew: czym jest, jak go zainstalować i co dodaje ponad zwykłą sesję czatu.
• Tabelę zapożyczeń: każdy pomysł Kiro przypisany do odpowiednika w Claude Code, Codex i Cursorze, ze zweryfikowanymi komendami instalacji.
• Trzy prompty do wklejenia (analiza wymagań, właściwości z wymagań, specyfikacja poprawki błędu) i listę kontrolną weryfikacji przeniesionej pętli.

Czym jest Kiro we wrześniu 2026?

Kiro zaczynało w 2025 roku jako agentowe IDE, a dziś jest rodziną powierzchni. README mówi, że „one unified agent harness powers every Kiro surface, so your specs, steering, permissions, hooks, MCP servers, and custom agents can follow your project across workflows” (kirodotdev/Kiro, odczyt 2026-09-26).

Powierzchnia	Do czego służy według README	Status
IDE	Lokalna praca z integracją edytora, czatem, specyfikacjami i hookami	Dostępne
CLI (kiro-cli)	Praca w terminalu, automatyzacja bez interfejsu i CI/CD	Dostępne
Web	Delegowanie zadań obejmujących wiele repozytoriów do izolowanych sandboksów w chmurze	Dostępne
Mobile	Śledzenie zadań, przegląd pull requestów, praca z agentami w drodze	Preview
Crew	Trwały, open source’owy workspace z pamięcią, harmonogramem i dostępem z wielu kanałów	Open source, Apache-2.0

Wokół przepływu specyfikacji README wymienia własne agenty, Steering (konwencje projektu), Agent Skills, Hooks, Powers (narzędzia i wiedza ładowane na żądanie), MCP, uprawnienia, plik .kiroignore dla wrażliwych ścieżek, checkpointy z cofaniem, sesje w chmurze (preview) i zarządzanie na poziomie organizacji. Kod produktu jest zamknięty: kirodotdev/Kiro to publiczny tracker zgłoszeń (4330 gwiazdek 2026-09-26), a nie kod.

Kiro sprzedaje plany oparte na kredytach, z darmowym progiem (źródło wtórne: aitoolpick, wrzesień 2026). Sprawdź cennik producenta, zanim zaplanujesz budżet; ceny planów narzędzi trzymamy w porównaniu kosztów.

Jak przepływ specyfikacji Kiro zamienia intencję w zadania?

Specyfikacja w Kiro to trzy pliki Markdown na funkcję, generowane po kolei, z ludzką akceptacją między etapami. Według źródeł wtórnych (fragmenty kiro.dev z wyszukiwarki, wrzesień 2026) leżą w .kiro/specs/<feature>/:

Plik	Zawiera	Kto akceptuje
requirements.md	Historyjki użytkownika z kryteriami akceptacji w formie EARS: „WHEN [warunek] THE SYSTEM SHALL [zachowanie]”	Product owner lub tech lead
design.md	Architektura, model danych, interfejsy i obsługa błędów dla tych wymagań	Tech lead
tasks.md	Ponumerowane zadania implementacyjne, każde powiązane z identyfikatorami wymagań	Developer, który je wykonuje

Te same źródła opisują trzy warianty: Feature Specs (najpierw wymagania albo najpierw projekt), Bugfix Specs (przyczyna źródłowa, projekt poprawki i zachowanie, które musi zostać bez zmian) oraz Quick Plan, który pisze wszystkie trzy pliki bez bramek. Kiro CLI współdzieli .kiro/specs/ z IDE.

Dwa elementy tego przepływu są potwierdzone w README samego Kiro. Requirements Analysis przegląda specyfikację, żeby znaleźć sprzeczności, niejasności i luki, zanim powstanie kod (README: „find contradictions, ambiguities, and gaps before coding begins”). Następny krok to correctness with property-based testing.

Wymaganie w formie EARS jest przydatne, bo maszyna może je sprawdzić. Porównaj dwie wersje:

.kiro/specs/cart-discounts/requirements.md (fragment)

### CART-3: Discounted total stays in range
WHEN a discount code is applied to a cart
THE SYSTEM SHALL return a total that is a whole number of cents,
not less than 0 and not greater than the undiscounted subtotal.

Example: subtotal 1999, code SAVE100PCT (100%) → total 0.

Zdanie „rabaty mają działać poprawnie” nie daje agentowi niczego do przetestowania. CART-3 nazywa klasę danych wejściowych, obserwowalny wynik i dwie granice, czyli dokładnie to, czego potrzebuje test właściwości.

Jak Kiro sprawdza kod względem specyfikacji?

README Kiro nazywa to „correctness with property-based testing”: agent zamienia wymagania w wykonywalne właściwości i sprawdza je „across generated inputs that example-based tests may miss” (kirodotdev/Kiro, odczyt 2026-09-26). README nie podaje, jakiej biblioteki Kiro używa w danym języku, a kiro.dev było niedostępne, więc tu żadnej nie wymieniamy.

Pomysł da się przenieść i przy agentach ma większe znaczenie niż bez nich. Agent, który pisze i kod, i testy przykładowe, może wybrać przykłady, które jego kod przechodzi. W teście właściwości dane wejściowe wybiera biblioteka, zwykle 100 lub więcej na przebieg, a każdą porażkę zmniejsza do minimalnego kontrprzykładu. Dla CART-3 w TypeScripcie z fast-check 4.10.2 i @fast-check/vitest. Najpierw zainstaluj oba pakiety; @fast-check/vitest wymaga Vitesta 4.1 lub nowszego (zakres peer w npm, sprawdzone 2026-09-26):

npm install -D fast-check @fast-check/vitest

Potem napisz właściwość:

tests/pricing/apply-discount.property.test.ts

import { expect } from 'vitest';
import { fc, test } from '@fast-check/vitest';
import { applyDiscount } from '../../src/pricing/apply-discount';

const lineCents = fc.array(fc.integer({ min: 1, max: 1_000_000 }), { minLength: 1, maxLength: 50 });
const discount = fc.oneof(
  fc.record({ kind: fc.constant('percent' as const), value: fc.integer({ min: 0, max: 100 }) }),
  fc.record({ kind: fc.constant('fixed' as const), value: fc.integer({ min: 0, max: 5_000_000 }) }),
);

// CART-3: WHEN a discount code is applied THE SYSTEM SHALL return a whole-cent total in [0, subtotal].
test.prop([lineCents, discount])('CART-3 discounted total stays in range', (lines, code) => {
  const subtotal = lines.reduce((sum, cents) => sum + cents, 0);
  const total = applyDiscount(lines, code);
  expect(Number.isInteger(total)).toBe(true);
  expect(total).toBeGreaterThanOrEqual(0);
  expect(total).toBeLessThanOrEqual(subtotal);
});

Identyfikator wymagania w nazwie testu to powiązanie śledzące: recenzent czyta requirements.md i listę przechodzących właściwości, a nie diff. Pełną metodę, z wersjami dla Hypothesis i proptest oraz sposobem utrwalania zmniejszonych kontrprzykładów jako testów regresji, opisuje property-based testing dla kodu pisanego przez agenty.

Czym jest Kiro Crew i co dodaje?

Kiro Crew to „a persistent workspace for development work that self-improves and continues beyond one session” (README kirodotdev/KiroCrew, odczyt 2026-09-26). To projekt open source na licencji Apache-2.0, utworzony 2026-07-16, który miał około 4200 gwiazdek (GitHub, 2026-09-26). Działa na macOS, Linuksie lub Windowsie, w lokalnym kontenerze albo na zdalnej maszynie, którą kontrolujesz (README, 2026-09-26).

Proces Gateway trzyma na hoście sesje, pamięć, harmonogramy, akceptacje i punkty kontrolne zadań, a do tej samej pracy dochodzisz z aplikacji desktopowej, panelu WWW, CLI, Slacka lub Discorda. README wymienia, co Crew dodaje ponad sesję czatu:

• Długie zadania. Dajesz Crew specyfikację zadania; planuje, wykonuje, sprawdza każdy krok, ponawia nieudane i wznawia od punktu kontrolnego. Przykład z README: „Implement this migration plan and stop if the tests fail.”
• Praca bez nadzoru. Zadania agenta według harmonogramu, deterministyczne skrypty bez wywołania modelu, heartbeaty, które pilnują systemu, aż coś będzie wymagało uwagi, oraz reakcje na zdarzenia z komunikatorów i uwierzytelnione webhooki.
• Uczenie się. Poprawki i nieudane zadania stają się trwałymi lekcjami, opcjonalnie ograniczonymi do jednego repozytorium przez repo_scope.
• Samorozwijające się skille. Powtarzające się wzorce zamieniają się w skille, które możesz przejrzeć, poprawić albo usunąć.
• Obrona warstwowa. Akceptacja narzędzi, sandboks systemu operacyjnego tam, gdzie jest dostępny, ochrona wrażliwych ścieżek i poświadczeń, reguły zakazu, zdarzenia audytowe i profile zarządzania. Panel domyślnie nasłuchuje tylko na loopbacku.

Crew steruje agentem przez Agent Client Protocol (ACP). Świeża konfiguracja używa kiro-cli, więc domyślna ścieżka wymaga logowania do Kiro. Ustawienie agent.acp_backend wybiera inny harness: dokumentacja konfiguracji wymienia oprócz domyślnego kas (Kiro Agent przez relay kiro-cli), claude (Claude Code przez publiczny adapter claude-agent-acp), codex (Codex), opencode, pi i goose (kirodotdev/KiroCrew src/kiro_crew/docs/configuration.md, odczyt 2026-09-26). Changelog oznacza te backendy jako Preview: Claude Code i Codex doszły w 0.6.0, OpenCode w 0.7.0, a włączasz je w Settings → Developer (Developer Mode, domyślnie wyłączony). Najnowsze wydanie to 0.7.1 (2026-09-24).

To zmienia pytanie o zapożyczenia. Zespół na Claude Code lub Codex może wypróbować trwałość i harmonogramy Crew bez zmiany agenta, z dwoma zastrzeżeniami z tego samego changelogu: narzędzie wstępnie zatwierdzone we własnych ustawieniach Claude Code nigdy nie trafia na ścieżkę akceptacji Crew (changelog: „never reaches Crew’s approval path”), więc reguły deny i log audytu Crew tego wywołania nie widzą; a Codex nie wystartuje, dopóki sandbox Crew jest wyłączony.

Żeby wypróbować go na stacji roboczej (terminal):

# Najpierw zainstaluj kiro-cli według dokumentacji Kiro CLI, potem zaloguj się:
kiro-cli login

# Zainstaluj podpisaną wersję Stable Crew i sprawdź konfigurację
curl -fsSL https://download.crew.kiro.dev/cli.sh | sh
kirocrew doctor
kirocrew gateway            # panel pod http://localhost:5476

# Crew domyślnie wysyła jeden anonimowy heartbeat dziennie; wyłączenie:
kirocrew telemetry disable

Dla stale działającego serwera README udostępnia obraz Dockera ghcr.io/kirodotdev/kirocrew:stable, publikowany na 127.0.0.1:5476. Zostaw go na loopbacku i łącz się przez tunel SSH albo VPN zamiast publicznego portu.

Co zespół na Claude Code, Codex albo Cursorze może przejąć od Kiro?

Każdy pomysł Kiro ma przenośny odpowiednik. Metoda się przenosi, a bramki egzekwowane przez produkt nie, więc egzekwujesz je w CI i w review.

Pomysł Kiro	Przejmij jako	Claude Code	Codex	Cursor
Specyfikacja w trzech plikach z bramkami	Skille cc-sdd 3.1.0 albo jeden spec.md na funkcjonalność	npx cc-sdd@latest (domyślny cel)	npx cc-sdd@latest --codex-skills	npx cc-sdd@latest --cursor-skills (beta)
Requirements Analysis	Pierwszy prompt poniżej, uruchomiony przed projektem	Plan mode (/plan)	Plan mode (/plan)	Plan Mode
Poprawność przez właściwości	fast-check lub Hypothesis w zestawie testów plus skill property-based-testing od Trail of Bits	Plugin	Plugin	npx skills add
Bugfix Spec, zachowane zachowanie	Testy charakteryzujące przed poprawką	Testy charakteryzujące	tak samo	tak samo
Steering	Pliki instrukcji projektu	CLAUDE.md	AGENTS.md	Rules
Harmonogramy i heartbeaty Crew	Własny scheduler narzędzia albo sam Crew z agent.acp_backend ustawionym na claude lub codex (preview)	Routines	Automations	Cloud agents i automations
Lekcje Crew	Pamięć i pliki instrukcji, które przeglądasz	Wzorce pamięci	tak samo	tak samo

Ustaw przeniesioną pętlę specyfikacji i właściwości

1. Zainstaluj skille specyfikacji. cc-sdd (specyfikacje „w stylu Kiro” dla innych agentów, npm 3.1.0 na 2026-09-26) tworzy ten sam kształt: requirements.md (EARS), design.md i tasks.md. Najpierw podejrzyj, co zapisze, z --dry-run. cc-sdd zapisuje też CLAUDE.md (Claude Code) albo AGENTS.md (Codex, Cursor) oraz .kiro/settings/; jeśli masz już plik instrukcji, uruchom z --overwrite skip albo --backup i scal zmiany ręcznie.

   Claude Code

   npx cc-sdd@latest --dry-run
   npx cc-sdd@latest            # skille Claude Code to domyślny cel

   Potem w Claude Code: /kiro-discovery CSV export of the audit log for team admins.

   Codex

   npx cc-sdd@latest --codex-skills

   Skille trafiają do .agents/skills/ i wywołujesz je jako $kiro-discovery, $kiro-spec-init i tak dalej (przewodnik zgodności cc-sdd, 2026-09-26). Używaj --codex-skills: starszy tryb --codex jest zablokowany.

   Cursor

   npx cc-sdd@latest --cursor-skills

   cc-sdd oznacza adapter dla Cursora jako betę. Sprawdź, czy skille kiro-* pojawiają się w Cursorze, zanim na nich oprzesz pracę; jeśli nie, trzymaj zwykły spec.md, jak opisuje spec-driven development.

2. Uruchom discovery, a potem po jednej fazie. Przepływ cc-sdd to kiro-discovery → kiro-spec-init → kiro-spec-requirements → kiro-spec-design → kiro-spec-tasks → kiro-impl. Zatrzymaj się po kiro-spec-requirements i uruchom poniższy prompt analizy wymagań, zanim cokolwiek zaakceptujesz.

3. Zainstaluj skill do property-based testing. Plugin property-based-testing od Trail of Bits (1.2.2) pisze, przegląda i diagnozuje testy właściwości dla Hypothesis, fast-check, proptest i innych. Do chwili użycia w kontekście siedzi tylko opis skilla.

   Claude Code

   claude plugin marketplace add trailofbits/skills
   claude plugin install property-based-testing@trailofbits

   Codex

   codex plugin marketplace add trailofbits/skills
   codex plugin add property-based-testing@trailofbits

   Cursor

   npx skills add trailofbits/skills --skill property-based-testing -a cursor

4. Napisz właściwości przed implementacją. Użyj drugiego promptu poniżej. Zacommituj testy właściwości razem z zaakceptowanymi wymaganiami, żeby zadanie implementacyjne startowało od czerwonych testów.

5. Implementuj zadanie po zadaniu. kiro-impl daje każdemu zadaniu świeżego wykonawcę pracującego w cyklu red-green TDD i niezależnego recenzenta, gdy host ma subagenty; w przeciwnym razie działa w głównym kontekście. Testy właściwości są warunkiem zatrzymania.

6. Postaw bramkę na pull requeście. CI uruchamia testy właściwości z domyślną liczbą przebiegów przy każdym pull requeście i głębszy przebieg co noc. Żeby liczbę przebiegów dało się ustawić, zarejestruj plik setup w konfiguracji Vitesta i wywołaj w nim fc.configureGlobal:

   vitest.config.ts

   import { defineConfig } from 'vitest/config';
   
   export default defineConfig({
     test: { setupFiles: ['tests/setup/fast-check.ts'] },
   });

   tests/setup/fast-check.ts

   import fc from 'fast-check';
   
   fc.configureGlobal({ numRuns: Number(process.env.FC_NUM_RUNS ?? 100) });

   W nocnym jobie ustaw FC_NUM_RUNS=10000. Pull request wymienia każdy identyfikator wymagania z testem, który go dowodzi.

Prompt do wklejenia: analiza wymagań przed projektem

Read .kiro/specs/audit-log-export/requirements.md. Do not write design or code yet.

Act as Kiro's requirements-analysis pass. Report, as a table with columns
ID | Problem type | Evidence (quote) | Question for the product owner:
1. Contradictions: two requirements that cannot both hold for the same input.
2. Ambiguities: any requirement without an observable outcome, a unit, a bound,
   or an actor (words like "fast", "correctly", "appropriate", "as needed").
3. Gaps: inputs the requirements never mention (empty result, max size, concurrent
   calls, a missing permission, a timezone boundary, a retry after failure).
4. Untestable requirements: anything that cannot become a property or an example test.

Then propose a rewrite of each flagged requirement in EARS form
(WHEN <condition> THE SYSTEM SHALL <observable behaviour>), each with one concrete example.
Stop after the report. I approve the rewrites before you touch design.md.

Prompt do wklejenia: właściwości z wymagań EARS

Use the property-based-testing skill. Read the approved requirements in
.kiro/specs/audit-log-export/requirements.md.

For every requirement, decide whether it is a property (holds for all inputs of a class),
an example (one specific case), or neither. For each property:
- Name the invariant in one sentence and the requirement ID it comes from.
- Write the generator for the full input domain, including empty, boundary and
  unicode cases. Do not narrow generators to make the test pass.
- Write the test with fast-check and @fast-check/vitest in tests/audit-export/,
  named "<REQ-ID> <invariant>".
Prefer round-trip, bounds, idempotence and "matches a simple reference model" properties.
Do not assert anything that restates the implementation.

The implementation does not exist yet, so the tests must fail for the right reason.
Run them, show me the failure output, and list any requirement you could not
turn into a test, with the reason.

Prompt do wklejenia: specyfikacja poprawki w stylu Kiro

Bug: CSV exports of the audit log drop rows whose actor name contains a comma.

Before any fix, write .kiro/specs/fix-audit-csv-commas/bugfix.md with three sections:
1. Root cause: reproduce it with a failing test in tests/audit-export/, and quote
   the line responsible.
2. Fix design: the smallest change that makes the failing test pass.
3. Preserved behaviour: every current behaviour of the export that must not change
   (column order, header row, date format, streaming, authorisation). For each one,
   add a characterization test that passes on the current code.
Show me the report and the test run. Wait for approval, then apply the fix and rerun
the whole tests/audit-export/ suite.

Jak udowodnić, że przeniesiona pętla działa, bez czytania każdej linijki?

Kiro egzekwuje swoje bramki w produkcie. Gdy przejmujesz samą metodę, dowody muszą być jawne, a każda bramka potrzebuje właściciela:

Bramka	Dowód	Kto zatwierdza
Wymagania	Tabela z analizy wymagań nie ma otwartych wierszy; każde wymaganie jest w formie EARS z przykładem	Product owner lub tech lead akceptuje requirements.md
Siła wyroczni	Każde wymaganie ma nazwany test właściwości lub przykładowy; plik testów zmienił się w tym samym pull requeście co requirements.md, a nie po kodzie	Tech lead, na podstawie listy powiązań w pull requeście
Poprawność	Testy właściwości przechodzą w CI z domyślną liczbą przebiegów; nocny głęboki przebieg jest zielony; każdy zmniejszony kontrprzykład jest utrwalony jako przypadek regresji	CI
Dryf	Zmiana zachowania bez delty specyfikacji nie przechodzi review, jak w spec-driven development	Recenzent

Dwie dodatkowe kontrole utrzymują wyrocznię w uczciwości. Testy mutacyjne na testowanym module pokazują, czy właściwości w ogóle mogą się wyłożyć; Trail of Bits ma w tym samym marketplace skill mutation-testing. A agent, który implementuje zadanie, nie może w tej samej sesji edytować testów właściwości: reguły hooków i review, które to wymuszają, opisuje ochrona wyroczni, a sposób pomiaru — siła wyroczni.

Czy twój zespół powinien przejść na Kiro, czy tylko od niego pożyczyć?

Sytuacja	Rekomendacja
Zespół pracuje na Claude Code, Codex albo Cursorze i podoba mu się dyscyplina specyfikacji	Pożycz: cc-sdd plus testy właściwości w CI. Bez drugiego narzędzia i drugiego formatu instrukcji
Chcesz, żeby bramki egzekwował produkt, a nie konwencja, a stos jest mocno oparty na AWS	Zrób pilotaż Kiro w jednym zespole według protokołu porównawczego na prawdziwych zamkniętych zgłoszeniach
Chcesz stale działającego agenta na własnym sprzęcie, z pamięcią i harmonogramem	Wypróbuj Kiro Crew na zapasowej maszynie. Domyślny harness wymaga logowania do Kiro; harnessy Claude Code i Codex są w wersji preview. Najpierw porównaj go ze schedulerem swojego narzędzia
Potrzebujesz jednego harnessu dla wielu agentów	Zostań przy przenośnych rozwiązaniach: Agent Skills i jeden plik instrukcji działają w wielu narzędziach; zobacz lock-in i przenośność

Co się psuje, gdy przejmujesz przepływ specyfikacji i właściwości z Kiro?

Właściwości, które powtarzają implementację. Agent pisze expect(applyDiscount(l, d)).toBe(subtotal - discountFor(l, d)), co przechodzi przy każdym błędzie, który ta funkcja pomocnicza dzieli z kodem. Jak naprawić: zabroń wywoływania testowanego modułu po stronie oczekiwanego wyniku; akceptuj tylko granice, round-tripy, idempotencję albo osobny prosty model referencyjny. Uruchom ponownie drugi prompt z tą regułą w treści.

Generatory zawężane, aż test zzielenieje. Nieprzechodząca właściwość zostaje „naprawiona” przez zawężenie zakresu danych do wartości, które kod obsługuje. Jak naprawić: przeglądaj zmiany generatorów równie starannie jak zmiany kodu i blokuj pull request, gdy dziedzina generatora się kurczy bez odpowiadającej zmiany w requirements.md.

EARS w formie, nie w treści. „WHEN the user exports THE SYSTEM SHALL export correctly” ma właściwy kształt i zero treści. Jak naprawić: prompt analizy wymagań wyłapuje brak wyniku, jednostek i granic; nie akceptuj projektu, dopóki jego tabela nie będzie pusta.

Specyfikacja i kod rozjeżdżają się po pierwszym wydaniu. Trzy pliki opisują funkcję taką, jaka była planowana, a kolejne pull requesty zmieniają zachowanie bez ich ruszania. Jak naprawić: wymagaj delty specyfikacji w każdym pull requeście zmieniającym zachowanie i regularnie audytuj dryf, jak opisuje spec-driven development.

cc-sdd zainstalowane w starym trybie. --claude, --cursor i inne tryby komend są przestarzałe, a --codex jest zablokowany (cc-sdd 3.1.0). Jak naprawić: zainstaluj ponownie z flagą --*-skills, a jeśli dostosowałeś stare pliki, najpierw zrób --dry-run w pustym katalogu.

Lekcje i skille Crew rosną bez przeglądu. Samorozwijające się skille i lekcje zmieniają późniejsze zachowanie. Jak naprawić: regularnie przeglądaj je w panelu, usuwaj wszystko, czego nie przyjąłbyś w pull requeście, i ograniczaj lekcje do jednego repozytorium przez repo_scope.

Crew wystawiony poza loopback. Port opublikowany na 0.0.0.0 daje każdemu w sieci agenta z twoimi poświadczeniami. Jak naprawić: nasłuchuj na 127.0.0.1, łącz się przez tunel SSH lub VPN i przeczytaj model bezpieczeństwa Crew, zanim poszerzysz dostęp. Zobacz uprawnienia i sandboksy.

Claude Code pod Crew omija ścieżkę akceptacji Crew. Przy agent.acp_backend ustawionym na claude każde narzędzie wstępnie zatwierdzone we własnych ustawieniach Claude Code (użytkownika, projektu, lokalnych lub zarządzanych) działa bez udziału reguł deny i logu audytu Crew (changelog Crew 0.6.0). Jak naprawić: na hoście Crew trzymaj listę allow Claude Code na minimum, reguły deny wpisz zarówno w ustawieniach Claude Code, jak i Crew, i traktuj log audytu Crew dla tego backendu jako niepełny.

Szczegóły producenta zmieniają się pod tobą. Warianty specyfikacji i komendy CLI Kiro opisane wyżej pochodzą ze źródeł wtórnych, a Kiro wydaje często. Jak naprawić: sprawdź kiro.dev, zanim ustandaryzujesz konkretną komendę, i przypnij przetestowaną wersję.

Dokąd dalej z pomysłami Kiro

Spec-driven development Jak utrzymać spec.md jako źródło prawdy: delta specyfikacji w każdym pull requeście, wykrywanie dryfu i zwykły Markdown kontra Kiro, Spec Kit, OpenSpec i BMAD.

Property-based testing dla kodu agentów Wymagania zamienione w niezmienniki w fast-check, Hypothesis i proptest oraz utrwalanie każdego zmniejszonego kontrprzykładu.

Porównanie frameworków spec-driven cc-sdd, Spec Kit, OpenSpec i reszta: ceremonia, artefakty i kiedy nie używać żadnego.

Agenci kodujący poza wielką trójką Gdzie Kiro stoi obok Copilota, Gemini CLI, OpenCode i Devina oraz protokół porównawczy do ich oceny.