# Sample MVP Plan Prompt

> Source: <https://gist.github.com/zaferayan/8bc328cdba7004d3d0d9ee82b145b120>
> Published: 2026-07-21 14:17:00+00:00

Bu repository için “Ne Pişirsem?” adlı Expo React Native mobil uygulamasının MVP planını hazırla.

Henüz uygulama kaynak kodu yazma veya mevcut uygulama dosyalarını değiştirme.

Önce aşağıdaki dosyaları oku:

`CLAUDE.md`

`.claude/agents/architect.md`

`.claude/skills/project-conventions/SKILL.md`

`docs/architecture.md`

`docs/agent-workflow.md`

`tasks/task.schema.json`

Repository’nin gerçek yapısını incele. Paket yöneticisi, Expo sürümü, routing sistemi, lint ve test komutları gibi bilgileri mevcut dosyalardan tespit et. Bilgi uydurma.

Uygulamanın adı:

**Ne Pişirsem?**

Kullanıcı, evinde bulunan malzemeleri kaydeder. Uygulama bu malzemelerle hazırlanabilecek yemek tariflerini eşleşme oranına göre gösterir.

Kullanıcı eksik malzemeleri alışveriş listesine ekleyebilir, tarifleri favorileyebilir ve adım adım pişirme modunu kullanabilir.

İlk sürümde aşağıdaki özellikler bulunmalı:

- Ana sayfada tarif listesi
- Tarif arama
- Kategoriye göre filtreleme
- Tarif detay ekranı
- Evdeki malzemeleri yönetme
- Tariflerin malzemelerle eşleşme yüzdesini gösterme
- Eksik malzemeleri gösterme
- Eksik malzemeleri alışveriş listesine ekleme
- Alışveriş listesindeki ürünleri işaretleme ve silme
- Tarifleri favorilere ekleme
- Favori tarifleri listeleme
- Porsiyon sayısını değiştirme
- Malzeme miktarlarını porsiyona göre hesaplama
- Adım adım pişirme modu
- Uygulama verilerini cihazda saklama
- Temel unit ve component testleri

İlk sürümde aşağıdakileri ekleme:

- Kullanıcı hesabı
- Authentication
- Backend
- Supabase
- Firebase
- Harici tarif API’si
- AI entegrasyonu
- Kamera
- Fotoğraftan malzeme algılama
- Push notification
- Sosyal özellikler
- Ödeme
- Reklam
- Analytics
- Cloud synchronization
- Çoklu dil desteği

Tarif verileri repository içinde bulunan yerel, deterministik ve typed mock data üzerinden sağlanmalı.

Repository’nin mevcut yapısı aksini gerektirmiyorsa şu teknolojileri kullan:

- Expo
- React Native
- TypeScript
- Expo Router
- Zustand
- Zod
- Expo SQLite veya uygun bir Expo local storage çözümü
- React Native Testing Library
- Jest

Yeni dependency eklenmesi gereken her durumda:

- Dependency adını belirt.
- Neden gerektiğini açıkla.
- Mevcut dependency ile çözülemeyeceğini doğrula.
- Plan aşamasında dependency yükleme.

Uygulama modern, temiz ve sıcak bir yemek uygulaması görünümünde olmalı.

Temel tasarım yaklaşımı:

- Açık renkli arka plan
- Sıcak turuncu ve yeşil vurgu renkleri
- Büyük yemek görselleri
- Yuvarlatılmış tarif kartları
- Kolay okunabilir tipografi
- Belirgin kategori chip’leri
- Büyük ve erişilebilir dokunma alanları
- Loading, empty ve error state’leri
- Küçük ekranlarda taşmayan responsive düzen

Henüz ayrıntılı görsel tasarım üretme. Yalnızca design token ve ortak UI bileşenlerinin planını çıkar.

En az şu ekranları planla:

```
Home
Search
Recipe Details
Pantry
Shopping List
Favorites
Cooking Mode
Settings
```

Settings ekranı yalnızca yerel verileri sıfırlama ve uygulama hakkında bilgisi içerebilir.

Tab navigation için şu alanları değerlendir:

```
Ana Sayfa
Malzemelerim
Alışveriş
Favoriler
```

Recipe Details ve Cooking Mode ekranları tab dışında stack ekranı olabilir.

Repository’nin mevcut routing yapısına göre kesin navigation planını oluştur.

En az aşağıdaki domain modellerini planla:

```
type IngredientCategory =
  | "vegetable"
  | "fruit"
  | "meat"
  | "dairy"
  | "grain"
  | "legume"
  | "spice"
  | "other";

type Ingredient = {
  id: string;
  name: string;
  normalizedName: string;
  category: IngredientCategory;
};

type MeasurementUnit =
  | "g"
  | "kg"
  | "ml"
  | "l"
  | "piece"
  | "tbsp"
  | "tsp"
  | "cup"
  | "slice";

type RecipeIngredient = {
  ingredientId: string;
  amount: number;
  unit: MeasurementUnit;
  optional?: boolean;
  note?: string;
};

type RecipeStep = {
  id: string;
  order: number;
  instruction: string;
  timerSeconds?: number;
};

type RecipeCategory =
  | "breakfast"
  | "soup"
  | "main"
  | "salad"
  | "dessert"
  | "snack";

type Recipe = {
  id: string;
  title: string;
  description: string;
  category: RecipeCategory;
  image: string;
  servings: number;
  prepMinutes: number;
  cookMinutes: number;
  difficulty: "easy" | "medium" | "hard";
  ingredients: RecipeIngredient[];
  steps: RecipeStep[];
};

type PantryItem = {
  ingredientId: string;
  quantity?: number;
  unit?: MeasurementUnit;
};

type ShoppingListItem = {
  id: string;
  ingredientId: string;
  amount?: number;
  unit?: MeasurementUnit;
  checked: boolean;
  sourceRecipeIds: string[];
};

type FavoriteRecipe = {
  recipeId: string;
  createdAt: string;
};
```

Modellerde değişiklik yapabilirsin ancak her değişikliğin gerekçesini dokümante et.

Malzeme eşleştirmesi görünen ad üzerinden değil, `ingredientId`

üzerinden yapılmalı.

Mock data hazırlanırken:

- Aynı malzemenin farklı yazımları ayrı kayıtlar oluşturmamalı.
- Türkçe karakterler korunmalı.
- Görünen ad ile normalize edilmiş ad ayrılmalı.
- Kullanıcıya gösterilen metinler Türkçe olmalı.

İlk sürümde synonym veya fuzzy matching yapma.

İlk sürüm için basit ve deterministik bir algoritma kullan:

```
eşleşme yüzdesi =
pantry içinde bulunan zorunlu malzeme sayısı
/
tarifte bulunan toplam zorunlu malzeme sayısı
× 100
```

Kurallar:

- Opsiyonel malzemeler skoru etkilememeli.
- Miktar yeterliliği ilk sürümde hesaplanmamalı.
- Eşleşme
`ingredientId`

üzerinden yapılmalı. - Sonuç 0–100 arasında tam sayı olmalı.
- Tarifin zorunlu malzemesi yoksa bölme hatası oluşmamalı.
- Eksik malzemeler ayrıca döndürülmeli.
- Algoritma UI’dan bağımsız pure function olmalı.

Önerilen çıktı:

```
type RecipeMatchResult = {
  percentage: number;
  matchedIngredientIds: string[];
  missingIngredientIds: string[];
  requiredIngredientCount: number;
  matchedIngredientCount: number;
};
```

Tarifin temel porsiyon değeri üzerinden malzeme miktarlarını hesaplayan pure function planla.

Örnek:

```
temel porsiyon: 2
seçilen porsiyon: 4
temel tavuk miktarı: 300 g
hesaplanan miktar: 600 g
```

Kurallar:

- Sonuçlar negatif veya sıfır olmamalı.
- Floating point gösterimi kullanıcı dostu olmalı.
- Domain hesabı ile görsel formatlama ayrılmalı.
- Orijinal recipe verisi mutate edilmemeli.

State’i en az şu alanlara ayırmayı değerlendir:

```
pantry
shoppingList
favorites
recipeFilters
cookingSession
```

Server state bulunmadığı için TanStack Query kullanılması zorunlu değil.

Kalıcı ve geçici state’i ayır:

Kalıcı:

- Pantry
- Shopping list
- Favorites

Geçici:

- Search query
- Category filter
- Seçili porsiyon
- Cooking mode aktif adımı

Storage katmanı UI’dan bağımsız olmalı.

Şunları planla:

- Storage adapter interface
- Typed serialization
- Başlangıçta hydrate işlemi
- Bozuk veya eski veride güvenli fallback
- Storage version alanı
- Gelecekte migration eklenebilecek yapı
- Uygulama verilerini sıfırlama

MVP için gereksiz karmaşık migration sistemi oluşturma.

İlk sürüm için 12–20 adet Türkçe tarif planla.

Tarifler farklı kategorilerden olmalı:

- Kahvaltı
- Çorba
- Ana yemek
- Salata
- Tatlı
- Atıştırmalık

Mock data şu senaryoları kapsamalı:

- Pantry ile tamamen eşleşen tarif
- Tek malzemesi eksik tarif
- Birden fazla malzemesi eksik tarif
- Opsiyonel malzemesi bulunan tarif
- Timer içeren cooking step
- Timer içermeyen cooking step
- Farklı porsiyon sayıları
- Farklı zorluk seviyeleri

Plan aşamasında tüm tarif içeriklerini yazmak zorunda değilsin. Mock data üretimi için ayrı görev oluştur.

Planı şu prensiplere göre oluştur:

- Feature-based klasörleme
- Domain logic ile UI ayrımı
- Küçük ve tekrar kullanılabilir component’ler
- Pure domain functions
- Typed navigation
- UI’dan bağımsız storage
- Deterministik mock data
- Test edilebilir state işlemleri
- Dependency inversion yalnızca gerçekten faydalıysa
- Gereksiz abstraction oluşturmama
- Barrel export kullanımını sınırlı tutma
- Feature’lar arasında kontrolsüz çapraz bağımlılık oluşturmama
- Mevcut Expo ve React Native standartlarına uyma

Örnek klasör yapısını repository’ye göre değerlendir:

```
app/
src/
  components/
  features/
    recipes/
    pantry/
    shopping-list/
    favorites/
    cooking/
  domain/
  storage/
  theme/
  test/
```

Bunu doğrudan kabul etme. Repository’nin mevcut yapısını analiz ederek uygun klasör yapısını öner.

En az şu bileşenlerin gerekip gerekmediğini değerlendir:

```
Screen
AppText
AppButton
IconButton
RecipeCard
IngredientRow
CategoryChip
SearchInput
EmptyState
ErrorState
LoadingState
SectionHeader
QuantityStepper
MatchBadge
CheckboxRow
```

Her bileşen ayrı görev olmak zorunda değil. İlgili ve birbirine yakın bileşenleri aynı görev altında grupla.

En az şu test alanlarını kapsa:

- Malzeme eşleşme algoritması
- Eksik malzeme hesaplama
- Opsiyonel malzeme davranışı
- Boş zorunlu malzeme listesi
- Porsiyon hesaplama
- Storage serialization
- State action’ları

- Tarif kartı render
- Arama ve filtreleme
- Pantry’ye malzeme ekleme
- Eksik malzemeyi alışveriş listesine ekleme
- Favori butonu
- Porsiyon stepper
- Cooking mode adım geçişi
- Empty state

Test komutlarını repository’de mevcut olan gerçek script’lere göre belirle. Bulunmayan komutları gerçekmiş gibi yazma.

Görevlerin acceptance criteria alanlarına uygun yerlerde şunları ekle:

- Dokunulabilir alanlar için accessibility label
- Butonlar için uygun role
- Salt renge dayalı durum anlatımından kaçınma
- Dinamik metin boyutunda kullanılabilir layout
- Görsellere uygun accessibility açıklaması
- Form ve arama alanlarında erişilebilir etiketler

Architect olarak işi küçük ve uygulanabilir görevlere böl.

Her görev:

`tasks/task.schema.json`

ile uyumlu olmalı.- Tek bir ana sorumluluğa sahip olmalı.
- Mümkünse 1–5 dosyalık değişiklik içermeli.
- Açık ve test edilebilir acceptance criteria içermeli.
- İzin verilen dosya veya glob sınırlarını belirtmeli.
- Yasaklanan dosya veya glob sınırlarını belirtmeli.
- Gerçek doğrulama komutlarını belirtmeli.
- Bağımlılıklarını açıkça tanımlamalı.
- Uygun agent’a atanmalı.
- Aynı dosyayı değiştirecek paralel görevler üretmemeli.
- Gereksiz refactor içermemeli.
- Yeni dependency gerekiyorsa riski belirtmeli.
- En fazla 2 otomatik denemeye izin vermeli.

Varsayılan eş zamanlı implementation worker sayısı en fazla 3 olsun.

En az şu alanları kapsayan görevler üret:

- Proje klasör yapısı ve temel mimari
- Tema ve design token’ları
- Ortak UI bileşenleri
- Ingredient ve Recipe domain modelleri
- Mock ingredient ve recipe verileri
- Recipe repository
- Tarif listeleme
- Tarif arama
- Kategori filtresi
- Tarif detay ekranı
- Pantry state ve ekranı
- Malzeme eşleşme algoritması
- Eşleşme oranlarının tarif listesine entegrasyonu
- Alışveriş listesi state ve ekranı
- Eksik malzemeleri alışveriş listesine ekleme
- Favoriler state ve ekranı
- Porsiyon hesaplama
- Cooking mode
- Local persistence
- Settings ve local data reset
- Unit testleri
- Component testleri
- Accessibility review
- Final integration ve review

Görev sayısını yapay biçimde artırma. Birbirine çok yakın küçük işleri tek görevde birleştirebilirsin.

- Aynı dosyayı değiştiren görevler paralel olamaz.
- Ortak type dosyaları tamamlanmadan ilgili feature görevleri başlamamalı.
- Ortak UI altyapısı tamamlanmadan ekran görevleri başlamamalı.
- State ve domain görevleri mümkün olduğunda UI görevlerinden önce tamamlanmalı.
- Test worker, ilgili implementation tamamlanmadan implementation dosyasını değiştirmemeli.
- Final integration bütün feature görevlerinden sonra çalışmalı.
- Reviewer production kodu değiştirmemeli.

Yalnızca aşağıdaki plan ve dokümantasyon dosyalarını oluştur:

```
docs/product-spec.md
docs/mvp-architecture.md
docs/task-dependency-graph.md
docs/testing-strategy.md
tasks/task-index.json
tasks/TASK-001.json
tasks/TASK-002.json
tasks/TASK-003.json
...
```

Uygulama kaynak kodunu değiştirme.

Şunları içersin:

- Ürün amacı
- Hedef kullanıcı
- Problem tanımı
- MVP özellikleri
- Kapsam dışı özellikler
- Ana kullanıcı akışları
- Ekranlar
- Domain kuralları
- Başarı kriterleri
- Bilinen sınırlamalar

Şunları içersin:

- Repository analizi
- Önerilen klasör yapısı
- Navigation
- Domain katmanı
- State yönetimi
- Storage katmanı
- Mock repository
- UI bileşenleri
- Veri akışları
- Error ve empty state yaklaşımı
- Dependency değerlendirmesi
- Mimari riskler

Şunları içersin:

- Mermaid dependency graph
- Kritik bağımlılık zinciri
- Paralel çalışabilecek görev grupları
- Conflict riski taşıyan görevler
- Önerilen execution dalgaları

Örnek dalgalar:

```
Wave 1
- Foundation
- Domain models
- Theme

Wave 2
- Mock data
- UI components
- Storage adapter

Wave 3
- Recipe list
- Pantry
- Favorites
```

Gerçek dalgaları oluşturulan görevlere göre belirle.

Şunları içersin:

- Unit test kapsamı
- Component test kapsamı
- Mock yaklaşımı
- Storage test yaklaşımı
- Navigation test yaklaşımı
- Accessibility kontrolü
- Test komutları
- MVP için kapsam dışı test türleri

Şunları içersin:

- Tüm görevlerin sırası
- Başlıkları
- Atanan agent
- Bağımlılıkları
- Paralel çalışma grubu
- Risk seviyesi
- Tahmini değişiklik alanları
- Durum
- Önerilen execution wave

Dosyaları oluşturduktan sonra:

- Bütün task JSON dosyalarını parse et.
- Her task dosyasını
`tasks/task.schema.json`

ile doğrula. - Her dependency ID’sinin gerçekten var olduğunu kontrol et.
- Circular dependency olmadığını kontrol et.
- Paralel görevlerin
`filesAllowed`

alanlarının çakışmadığını kontrol et. - Aynı görevin hem dependency hem paralel grup içinde yanlış tanımlanmadığını kontrol et.
- Task index ile task dosyalarının tutarlı olduğunu doğrula.
`git diff --stat`

çalıştır.- Uygulama kaynak kodunun değişmediğini doğrula.

Sorun varsa düzelt ve doğrulamaları yeniden çalıştır.

İşlem sonunda şunları raporla:

- Önerilen mimari
- Toplam görev sayısı
- Kritik bağımlılık zinciri
- Execution wave’leri
- İlk paralel çalışabilecek görevler
- En riskli görevler
- Yeni dependency önerileri
- Repository’de doğrulanamayan varsayımlar
- İlk uygulanması önerilen üç görev
- Çalıştırılan doğrulamalar

Kod yazma. Yalnızca ürün specification’ı, mimari plan, test stratejisi ve görev dosyalarını oluştur.
