development agent llm skills - ghdrako/doc_snipets GitHub Wiki
tags:
Development agent llm skills
https://github.com/gregwebs/skills-sdlc/
┌──────────────┐
│ wymaganie │
└──────┬───────┘
↓
┌─────────────────┐
│ grill-with-docs │
│ doprecyzowanie │
└────────┬────────┘
↓
SPEC
↓
TICKETS
↓
PLANOWANIE
↓
IMPLEMENTACJA
↓
TESTY
↓
CODE REVIEW
↓
VERIFICATION
↓
PR
Rozdzielone role:
┌───────────────┐
│ Planner │
│ Opus │
└───────┬───────┘
↓
implementation plan
↓
┌───────────────┐
│ Implementer │
│ Sonnet │
└───────┬───────┘
↓
code
↓
┌───────────────┐
│ Reviewer │
│ adversarial │
└───────────────┘
Czyli jeden agent planuje, drugi implementuje, a kolejny próbuje znaleźć problemy. Repozytorium ma osobne definicje agentów dla Claude i Codex.
GRILL — najważniejszy etap
Grill ma odkryć decyzje zanim powstanie specyfikacja.
W wariancie grill-with-docs agent najpierw patrzy w istniejący kod i dokumentację, zamiast zadawać użytkownikowi pytania, na które odpowiedź już znajduje się w repo. Następnie prowadzi użytkownika przez decyzje jedna po drugiej, porządkując również terminologię.
To jest interview / decision tree.
GRILL → SPEC
Po grillowaniu powstaje spec. W repo odpowiada za to:skills/spec/SKILL.md
Ten skill jest override'em upstreamowego /to-spec. Co ciekawe, skills-sdlc celowo zmienia jedną istotną zasadę: pozwala w specyfikacji umieszczać konkretne ścieżki plików i fragmenty kodu, ale wiąże je z konkretnym commitem, żeby ograniczyć problem starzenia się referencji.
Czyli zamiast:
Należy zmienić moduł odpowiedzialny za CDC.
może być:
src/cdc/replicator.go
commit abc123
zmienić:
processChange()
na:
processChange(...)
To jest bardzo praktyczne.
SPEC → TICKETS
Jeżeli feature jest większy, /tickets dzieli specyfikację na mniejsze kawałki.
SPEC:
CDC PostgreSQL → Oracle
│
├── TICKET 1
│ initial snapshot
│
├── TICKET 2
│ INSERT
│
├── TICKET 3
│ UPDATE
│
├── TICKET 4
│ DELETE
│
└── TICKET 5
retry / recovery
Ticket powinien być możliwie kompletnym kawałkiem funkcjonalności. /tickets bazuje na upstreamowym /to-tickets, ale dodaje m.in. konkretne referencje do kodu powiązane z commitami.
IMPLEMENT
/implement uruchamia oddzielnego plannera.
Schemat:
TICKET
│
▼
┌─────────────┐
│ PLANNER │
│ Opus │
└──────┬──────┘
│
▼
implementation-plan.md
│
▼
┌─────────────┐
│ REVIEW │
│ planu │
└──────┬──────┘
│
▼
┌─────────────┐
│ IMPLEMENTER │
│ Sonnet │
└──────┬──────┘
│
▼
CODE
planner.md definiuje agenta jako model Opus, którego zadaniem jest stworzenie planu, a nie edycja repozytorium.
Implementer jest osobnym agentem opartym domyślnie o Sonnet
SPEC mówi:
CO chcemy osiągnąć
DLACZEGO
jakie są wymagania
ale nie musi mówić dokładnie:
zmień linię 173 w pliku X
IMPLEMENTATION PLAN
mówi:
JAK konkretnie to zrobimy
Np.:
- zmienić src/cdc/reader.go
- dodać OracleSink
- zmienić interface ChangeHandler
- dodać retry
- dodać test...
Plan ma zawierać m.in.:
architekturę,
konkretne pliki,
funkcje,
zmiany typów,
testy,
dokumentację,
verifications,
failure modes,
założenia.
Czyli:
SPEC
│
│ „co”
▼
Implementation Plan
│
│ „jak”
▼
IMPLEMENTER
To bardzo przypomina klasyczny proces:
Requirements
↓
Design
↓
Implementation
tylko design jest generowany przez mocniejszego agenta.
REVIEW
Planner:
Opus
│
▼
implementation-plan.md
potem:
implementation-plan.md
│
▼
adversarial review
│
▼
poprawiony plan
implementation-plan/SKILL.md wymaga niezależnego review planu, poza przypadkiem rzeczywiście trywialnej zmiany. Review ma sprawdzić kolejno:
SPEC
↓
ARCHITECTURE
↓
QUALITY
↓
TESTS
↓
OPERATIONAL RISKS
Czyli implementer nie dostaje planu prosto od plannera bez kontroli.
IMPLEMENTER
Implementer nie dostaje całej historii rozmowy.
Dostaje:
task-brief.md
implementation-plan.md
i sam czyta repozytorium.
/implement wręcz zabrania przekazywania całego transcriptu rozmowy i wymaga uruchamiania subagentów bez odziedziczonego kontekstu
┌───────────────┐
│ PLANNER │
└───────┬───────┘
│
plan artifact
│
▼
┌───────────────┐
│ IMPLEMENTER │
└───────────────┘
To jest artifact-based handoff.
Implementer robi TDD
W instrukcji implementera jest:
Use TDD at the seams the plan identifies
oraz regularne:
typecheck
single tests
full test suite
i na końcu własny code review.
Czyli:
implementation
│
├── test
├── code
├── test
├── code
│
└── full suite
PBT nie jest częścią skills-sdlc jako framework, ale ten workflow jest na tyle otwarty, że można go bardzo sensownie użyć jako jednego z mechanizmów testowych.
DRUGI review
Po implementerze:
CODE
│
▼
implementation-result.md
verifications.md
│
▼
┌─────────────────────────┐
│ independent code review │
└────────────┬────────────┘
│
▼
findings
│
▼
poprawki
Skill /implement deleguje tutaj osobnego agenta do /code-review-with-followup. Review dostaje:
task-brief.md
implementation-plan.md
implementation-result.md
verifications.md
i może dopisać dodatkowe wymagane weryfikacje.
Czyli mamy:
PLAN
│
review plan
│
▼
IMPLEMENT
│
review code
│
▼
VERIFY
Review nie jest tylko „sprawdź czy kod wygląda dobrze”.
Ma porównać:
SPEC
↕
PLAN
↕
CODE
↕
TESTS
VERIFY
Po review uruchamiany jest jeszcze świeży implementer, którego zadaniem nie jest już pisanie feature'a.
Ma:
sprawdzić, czy działa
W szczególności:
happy path
edge cases
failure modes
e2e
i może dodać brakujące testy.
Czyli końcówka:
CODE
│
▼
REVIEW
│
├── problem ──→ implementer ──→ fix
│
▼
VERIFY
│
▼
DONE
Artefakty są kluczowe
W czasie tego procesu powstają pliki tymczasowe:
task-brief.md
│
▼
implementation-plan.md
│
▼
implementation-result.md
│
▼
verifications.md
Można to zobaczyć jako:
┌─────────────────┐
│ task-brief.md │
└────────┬────────┘
│
▼
┌──────────────────────┐
│ implementation- │
│ plan.md │
└────────┬─────────────┘
│
▼
┌──────────────────────┐
│ implementation- │
│ result.md │
└────────┬─────────────┘
│
▼
┌──────────────────────┐
│ verifications.md │
└──────────────────────┘
Co ważne, te artefakty są trzymane w tymczasowym katalogu poza repozytorium i przekazywane agentom przez ścieżki. Nie są normalnym kodem projektu
| Plik | Rola |
|---|---|
| skills/spec/SKILL.md | definiuje /spec |
| skills/tickets/SKILL.md | definiuje /tickets |
| skills/implementation-plan/SKILL.md | jak stworzyć szczegółowy plan |
| skills/implement/SKILL.md | orkiestruje cały proces implementacji |
| skills/code-review-adversarial/SKILL.md | adversarial review |
| skills/code-review-with-followup/... | review + poprawki |
| agents/planner.md | agent planujący |
| agents/implementer.md | agent implementujący |
| .codex/agents/planner.toml | konfiguracja plannera dla Codexa |
| .codex/agents/implementer.toml | konfiguracja implementera dla Codexa |
| AGENTS.md | instrukcje specyficzne dla repo |
| CODING_STANDARDS.md | standardy kodowania/review |
| scripts/install-*.sh | instalacja skills/agentów/standardów |