commit

Files (1)

• SKILL.md

SKILL.md (first lines)

# Commit Skill

## Kullanılacak destek skiller
- `caveman`, `ponytail` (full) — her zaman aktif.
- `superpowers:finishing-a-development-branch` — commit'ten hemen önce branch temizliği için.

Bu skill pipeline'ın (atdd → test-copilot → code-copilot → verify → red-team) otomatik bir parçası DEĞİLDİR — sadece kullanıcı "commitle"/"pushla" dediğinde çalışır. Son kalite kapısı görevini de üstlenir: yanlış dosya ekleme, kapsam dışı değişiklik gönderme ve gereksiz karmaşıklığı burada yakala.

## Akış (sıra değişmez, atlanamaz)

```
Git Status
  ↓
Scope Review
  ↓
AI Dev Log / Setup Güncellemesi
  ↓
Ready To Commit Checklist
  ↓
Commit Message
  ↓
CAVEMAN Review
  ↓
Show Summary
  ↓
User Approval
  ↓
Stage Explicit Files
  ↓
Commit
  ↓
Push
  ↓
Report
  ↓
Saga/Jira Güncelleme Önerisi
  ↓
Postmortem Eşik Kontrolü (zorunlu karar noktası)
  ↓
Sohbet Temizliği Önerisi
```

## 1. Git Status
`git status` çalıştır. Diff'in tamamını modele gönderme — büyük değişikliklerde pahalı ve gereksiz:
```bash
git diff --stat
git diff --name-status
```
Belirli bir dosyanın gerçek içeriğini görmen gerekiyorsa (kapsam/scope şüphesi, secrets kontrolü vb.) sadece o dosyayı hedefle:
```bash
git diff HEAD -- path/file
```
`git diff`'i (tam, dosya belirtmeden) hiçbir adımda çalıştırma.

## 2. Scope Review
Değişen her dosyayı şu listeye karşı gözden geçir — biri bile işaretlenirse kullanıcıya sor, sessizce stage etme:
- ✓ ilgisiz dosyalar (bu task'ın kapsamına girmeyen)
- ✓ üretilmiş/generated dosyalar
- ✓ geçici dosyalar
- ✓ log dosyaları
- ✓ cache klasörleri
- ✓ build çıktıları
- ✓ IDE ayar dosyaları
- ✓ secrets/credentials

## 2b. AI Dev Log / Setup Güncellemesi — **aktar, yeniden yazma** (2026-09-12)

**Kural değişti:** Bu adım artık "commit anında oturumu hatırlayıp özetle"
DEĞİL — pipeline'ın her adımı zaten kendi kararını/varsayımını/riskini kendi
dosyasına yazmış durumda (`atdd.md`'nin Assumptions/Risks/Rollback'ı,
`plan.md`'nin Kararlar/Migration/Risks'i, `code_diff.md`'nin Varsayımlar/
Kalan Sınırlamalar'ı, `verify_report.md`'nin Coverage notları, `red_team.json`'ın
strengths/risks'i). Bunları commit anında yeniden yorumlayıp sıfırdan yazmak
hem gereksiz bir LLM turu hem de tutarsızlık riski (özetlerken bir nüans
kaybolabilir, orijinaliyle çelişebilir). Bunun yerine **doğrudan aktar**:

| Kaynak dosya | Hangi bölüm | Nereye |
|---|---|---|
| `atdd.md` | `## Risks`, `## Assumptions`, `## Rollback Beklentisi` | `AI_DEVLOG.md` — bilinçli kapsam/mimari kararları |
| `plan.md` | `## Risks`, `## Migration Required?`, (varsa) `## Kararlar` (Sonnet alt-ajanı) | `AI_DEVLOG.md` — teknik karar gerekçeleri |
| `code_diff.md` | "Kalan Sınırlamalar", "Varsayımlar", (varsa) "Review Sürecinde Bulunan ve Düzeltilen Sorun" | `AI_DEVLOG.md` — gerçek zorluk/bug örneği (en değerli kategori, `strix-guvenlik-acigi-duzeltme`'deki CSP-regresyon bulgusu gibi) |
| `verify_report.md` | "Coverage / Quality Notes", (varsa) refactor aday notu | `AI_DEVLOG.md` (önemliyse) |
| `plan.md` | yeni env değişkeni/migration/kurulum adımı geçen her satır | `SETUP.md` — birebir |

Adımlar:
1. Bu commit'in `<task-slug>`'ına ait `obss_project/artifacts/<task-slug>/`
   altındaki dosyaları (yukarıdaki tablo) `Read` et.
2. Yukarıdaki alanlarda gerçekten dolu (varsayım/risk/karar/env değişkeni
   içeren, "yok"/"varsa" gibi boş placeholder olmayan) bir şey var mı bak.
3. **Varsa:** o cümleyi/maddeyi **olduğu gibi veya en fazla küçük bir
   biçim düzenlemesiyle** (madde işareti, başlık ekleme) `AI_DEVLOG.md`/
   `SETUP.md`'ye kopyala — yeniden yorumlama, yeni bir anlatım üretme.
   Kaynağını belirt (`(kaynak: code_diff.md)` gibi kısa bir not, iz sürmek için).
4. **Hiçbiri dolu değilse** (gerçekten rutin bir değişiklikse) atla — icat
   etme, boş madde ekleme.
- Bu ikisi kod/test dosyası DEĞİL, dokümantasyon — `code-copilot`/
  `test-copilot`'un "sadece Copilot yazar" kuralı bunlara uygulanmaz, Claude
  kendisi `Write`/`Edit` ile güncelleyebilir. Ama artık **yazar değil,
  aktarıcı** rolünde — içerik zaten var, sadece doğru yere taşınıyor.
- Güncellenen dosyaları Scope Review listesine ekle; Stage Explicit Files
  adımında commit'e dahil et.

## 3. Ready To Commit Checklist
İlgili task varsa (`obss_project/artifacts/<task-slug>/red_team.json`), kaliteyi burada yeniden değerlendirme — `red-team` skill'i zaten bunu yapıp `ready_to_commit` alanına yazdı. Sadece oku:
- `red_team.json` mevcut mu? Yoksa kullanıcıya söyle: "Bu task için red-team incelemesi yok, önce `red-team` skill'i çalıştırılmalı" ve onay iste (yine de devam et/etme, kullanıcı karar versin).
- `ready_to_commit` alanındaki 8 maddeyi (`atdd_satisfied`, `tests_passed`, `no_critical_findings`, `scope_respected`, `caveman_satisfied`, `security_acceptable`, `maintainability_acceptable`, `no_blocking_risks`) olduğu gibi kullanıcıya göster.
- `verdict` `"block"` ise kullanıcıya açıkça uyar ve onay iste — "red-team block dedi, yine de devam edeyim mi?"
- Ayrıca kendi başına: Secrets yok mu (2. adımdan), temiz git durumu mu (ilgisiz/staged olmayan artık dosya yok) — bunlar commit'e özgü, red-team'in kapsamında değil.

İlgili bir task/artifact yoksa (serbest/ad-hoc commit), bu listeyi "task bağlamı yok" diyerek N/A geç — icat etme.

## 4. Commit Message
Öncelik sırası:
1. Kullanıcı zaten bir Conventional Commit mesajı verdiyse onu kullan.
2. Yoksa Claude kendisi üretir. Hiçbir dış modele (Gemma vb.) bağımlı DEĞİLDİR.

Format — Conventional Commit zorunlu:
```
<type>(<scope>): <kısa özet>

From yutronax/atdd-pipeline-skills, MIT.

More from yutronax/atdd-pipeline-skills