İnceleme

Kullanıcının sağladığı sabit bir nokta ile HEAD arasındaki diff'in iki eksenli incelemesi:

• Standartlar — kod bu repo'nun belgelenen kodlama standartlarına uyuyor mu?
• Spec — kod, kaynak issue / PRD / spec'i sadakatle uygulayıp uygulamıyor mu?

Her iki eksen de paralel alt-ajanlar olarak çalışır, böylece birbirlerinin context'ini kirletmezler, ardından bu skill bulguları toplar.

Issue tracker'ın sana sağlanmış olması gerekir — docs/agents/issue-tracker.md eksikse /setup-matt-pocock-skills komutunu çalıştır.

Süreç

1. Sabit noktayı sabitle

Kullanıcının söylediği her şey sabit noktadır — bir commit SHA, branch adı, tag, main, HEAD~5, vb. Fikir sahibi olmayın; olduğu gibi geçirin. Eğer belirtmemişlerse, sor: "Neye karşı inceleme yapacağız — bir branch, bir commit, yoksa main?" Elde edene kadar ilerlemezsiniz.

Diff komutunu bir kez yakalayın: git diff <fixed-point>...HEAD (üç nokta, karşılaştırma merge-base'e karşı olacak şekilde). Ayrıca commit listesini git log <fixed-point>..HEAD --oneline ile not edin.

2. Spec kaynağını tanımla

Kaynak spec'i bu sırada ara:

1. Commit mesajlarındaki issue referansları (#123, Closes #45, GitLab !67, vb.) — docs/agents/issue-tracker.md içindeki workflow aracılığıyla getir.
2. Kullanıcının argüman olarak geçtiği bir yol.
3. docs/, specs/, veya .scratch/ altında branch adı ya da özellikle eşleşen bir PRD/spec dosyası.
4. Hiçbir şey bulunamazsa, spec'in nerede olduğunu kullanıcıya sor. Eğer "yoktur" derlerse, Spec alt-ajanı atlayacak ve "spec bulunamamıştır" rapor edecektir.

3. Standartlar kaynaklarını tanımla

Kodun nasıl yazılması gerektiğini belgelendiren repo'daki her şey. Yaygın konumlar:

• CLAUDE.md, AGENTS.md
• CONTRIBUTING.md
• CONTEXT.md, CONTEXT-MAP.md, context başına CONTEXT.md dosyaları
• docs/adr/ (mimari kararlar standartlardır)
• .editorconfig, eslint.config.*, biome.json, prettier.config.*, tsconfig.json (makine tarafından zorlanan standartlar — bunları not et ama tooling'in zaten kontrol ettiği şeyleri yeniden kontrol etme)
• Repo root'unda veya docs/ altında STYLE.md, STANDARDS.md, STYLEGUIDE.md veya benzeri dosyalar

Dosyaların listesini topla. Standartlar alt-ajanı bunları okuyacak.

4. Her iki alt-ajanı paralel olarak başlat

İki Agent tool call'u içeren tek bir mesaj gönder. Her ikisi için general-purpose subagent'ı kullan.

Standartlar alt-ajanı prompt'u — şunları dahil et:

• Tam diff komutu ve commit listesi.
• Adım 3'te bulduğun standartlar-kaynak dosyaları listesi.
• Özet: "Standartlar dokümantasyonunu oku. Ardından diff'i oku. Rapor et — dosya/hunk başına ilgili olduğu yerde — diff'in belgelenen bir standardı ihlal ettiği her yeri. Standart'ı (dosya + kural) alıntıla. Katı ihlallerle yargı çağrılarını ayırt et. Tooling'in uyguladığı her şeyi atla. 400 kelimeden az."

Spec alt-ajanı prompt'u — şunları dahil et:

• Diff komutu ve commit listesi.
• Spec'in yolu veya getirilen içeriği.
• Özet: "Spec'i oku. Ardından diff'i oku. Rapor et: (a) spec'in istediği fakat eksik veya kısmi olan gereklilikler; (b) diff'te istenmemiş davranış (scope creep); (c) uygulanmış gibi görünen fakat uygulamanın yanlış görüldüğü gereklilikler. Her bulgu için spec satırını alıntıla. 400 kelimeden az."

Eğer spec eksikse, Spec alt-ajanını atla ve bunu final raporda not et.

5. Topla

İki raporu ## Standartlar ve ## Spec başlıkları altında, kelimesi kelimesine veya hafifçe temizlenmiş şekilde sun. Bulguları birleştirme veya yeniden sırala yapma — iki eksen kasıtlı olarak ayrı tutulur, böylece kullanıcı bunları bağımsız olarak görebilir.

Şu şekilde bitir: eksen başına toplam bulgu, ve bayraklanan en kötü tek sorun (varsa) — tek satır özet.

Neden iki eksen

Bir değişiklik bir ekseni geçebilir ve diğerinde başarısız olabilir:

• Her standartı takip eden fakat yanlış şeyi uygulayan kod → Standartlar geçti, Spec başarısız.
• Tam olarak issue'nun istediğini yapan fakat projenin kurallarını bozan kod → Spec geçti, Standartlar başarısız.

Bunları ayrı olarak raporlamak bir eksenin diğerini maskelemesini engeller.