name: writing-plans description: > Turns an approved scope or idea into a concrete, executable implementation plan. Defines what changes, in what order, with what dependencies, risks flagged, and checkpoints marked. Output feeds directly into executing-plans or dispatching-parallel-agents.
Writing Plans Skill
Ön Koşul
Bu skill başlamadan önce şunlar hazır olmalı:
-
brainstormingtamamlandı ve scope doc var →.agent/SCOPE-<slug>.md - Başarı kriterleri netleşti
- Tech stack kararı verildi
Scope doc'u yükle: .agent/SCOPE-*.md paterninde arama yap ve en son tarihli olanı oku.
Bunlar yoksa önce brainstorming skill'ini çalıştır.
Süreç
Adım 1: Etkilenen Alanları Haritala
Mevcut kod tabanını tara ve neyin değişeceğini belirle:
src/
├── components/ ← Yeni komponent: UserCard
├── services/ ← Değişecek: userService.ts
├── api/ ← Yeni endpoint: POST /api/users
├── db/migrations/ ← Yeni migration: add_users_table
└── tests/ ← Yeni testler: userService.test.ts
Her etkilenen dosya için:
- Yeni mi, değişiyor mu, siliniyor mu?
- Başka ne bu dosyaya bağımlı? (kırmadan değiştirilebilir mi?)
Adım 2: Görevleri Atomik Parçalara Böl
Her görev:
- Tek bir şey yapar
- Bağımsız commit olabilir
- Test edilebilir (tamamlandığını nasıl anlarsın?)
- 2 saatten kısa (daha uzunsa böl)
## Görev Listesi
### T1: Database migration — users tablosu
- Dosya: db/migrations/001_create_users.sql
- İçerik: id, email, password_hash, created_at, deleted_at
- Bağımlılık: Yok (ilk adım)
- Test: Migration up/down çalışıyor
### T2: User model ve repository
- Dosya: src/db/repositories/userRepository.ts
- İçerik: findById, findByEmail, create, softDelete
- Bağımlılık: T1 (migration olmalı)
- Test: repository unit testleri geçiyor
### T3: UserService — iş mantığı
- Dosya: src/services/userService.ts
- İçerik: createUser (hash password), getUser, deleteUser
- Bağımlılık: T2
- Test: service unit testleri geçiyor
### T4: API endpoint — POST /api/users
- Dosya: src/api/routes/users.ts
- İçerik: validation, auth middleware, service çağrısı
- Bağımlılık: T3
- Test: integration test geçiyor
### T5: Frontend — UserCard komponenti
- Dosya: src/components/UserCard/
- İçerik: komponent + test + storybook
- Bağımlılık: T4 (API mock veya gerçek)
- Test: komponent testleri geçiyor
Adım 3: Bağımlılık Grafiği Çiz
T1 (migration)
└── T2 (repository)
└── T3 (service)
└── T4 (API endpoint)
└── T5 (frontend)
Paralel çalışabilecek görevler ayrı kollar olarak işaretle:
T1
├── T2 → T3 → T4 (backend kolu)
└── T5-mock (frontend kolu — mocked API ile başlayabilir)
Adım 4: Risk ve Checkpoint'leri İşaretle
Her görevin yanına:
[RISK]— başarısız olursa diğerleri bloke olur[CHECKPOINT]— bu noktada pause edilebilir, sonuç doğrulanabilir[BREAKING]— mevcut kodu kırar, dikkat gerekir[PARALLEL]— başka görevle aynı anda yapılabilir
### T3: UserService [RISK] [CHECKPOINT]
Bu görev tüm backend'in temelini oluşturuyor.
Burada durup review yapılmalı, sonra API katmanına geçilmeli.
Adım 5: Planı Yaz
implementation_plan.md dosyasına yaz:
# Implementation Plan: <proje adı>
**Tarih:** <YYYY-MM-DD>
**Tahmini Süre:** <X gün/saat>
**Kaynak:** [Scope Doc](.agent/SCOPE-<slug>.md)
## Özet
<2-3 cümle: ne yapılacak, nasıl yapılacak>
## Tech Stack Kararları
| Alan | Seçim | Gerekçe |
|------|-------|---------|
| ORM | Prisma | Type-safe, migration yönetimi iyi |
| Auth | JWT + refresh token | Stateless, ölçeklenebilir |
## Görevler
### 🔵 Aşama 1: Temel (Paralel çalışmaz)
- [ ] **T1:** Database migration `[CHECKPOINT]`
- [ ] **T2:** Repository katmanı
### 🟡 Aşama 2: Çekirdek (T1 ve T2 bitince)
- [ ] **T3:** Service katmanı `[RISK][CHECKPOINT]`
- [ ] **T4:** API endpoint `[BREAKING]`
### 🟢 Aşama 3: UI (T4 veya mock hazırken)
- [ ] **T5:** Frontend komponent `[PARALLEL]`
## Risk Listesi
| Risk | Olasılık | Etki | Önlem |
|------|----------|------|-------|
| Migration geri alınamaz | Düşük | Yüksek | Down migration yaz ve test et |
## Tanımlanmamış Noktalar
- [ ] Email doğrulama akışı: gerekli mi? (karar bekleniyor)
## Sonraki Adım
1. `architecture-review` skill'ini çalıştır — plan onaylanmadan kod başlamaz
2. Onaydan sonra `executing-plans` veya `dispatching-parallel-agents`
Kurallar
- Her görev test kriteriyle biter. "Tamamlandı" = testler geçiyor.
- Hiçbir görev "ve ayrıca" içermez. Varsa böl.
- "Sonra hallederiz" plan'a girmez. Ya göreve dönüştür ya scope dışına at.
- Plan değişirse güncellenir. Eski plan geçerliliğini yitirir — silme, tarih ver.
architecture-reviewatlanamaz. Özellikle[RISK]işaretli görevler varsa zorunludur.