Requirements to Plan

Mevcut bir REQUIREMENTS.md dosyasını ve proje yapısını inceleyerek, Türkçe yazılmış, aşamalara bölünmüş ve doğrudan uygulanabilir bir PLAN.md üretir. Gereksinimlerin ne sorusuna verdiği cevabı, nasıl ve hangi sırayla sorularına çevirir; kapsamı yeniden tanımlamaz, sadece uygular.

Kullanım Senaryoları

• Elinde bir REQUIREMENTS.md var ve bunu somut, sıralı bir uygulama planına dönüştürmek istediğinde
• Bir özelliği veya iş kalemini aşamalara/görevlere bölüp hangi sırayla yapılacağını netleştirmek istediğinde
• Gereksinimlerin hangi dosya/katmana dokunacağını, risklerini ve test stratejisini önceden görmek istediğinde
• “Bu spec’i görevlere böl”, “PLAN.md oluştur”, “bunu nasıl inşa etmeliyim” gibi istekler geldiğinde

Ne Üretilir?

• PLAN.md adında, tamamen Türkçe yazılmış bir uygulama planı (kod tanımlayıcıları ve dosya yolları orijinal halinde kalır)
• Belirsizlik içeren noktalar için açık varsayımlar ve hâlâ yanıtlanması gereken sorular
• Bağımlılığa göre sıralanmış aşamalar, her biri somut ve gereksinimle eşleşen görevlerle
• Üst düzey mimari yaklaşım: hangi katman/modül/bileşenin işin içinde olduğu
• Riskler ve her biri için alınacak önlem veya araştırma (spike) önerisi
• Planın tamamlandığını gösteren bir “Tamamlanma Tanımı” (Definition of Done) kontrol listesi

---
name: requirements-to-plan
description: Turn a REQUIREMENTS.md file into an actionable implementation PLAN.md — a sequenced, phase-by-phase engineering plan with tasks, file/layer touchpoints, risks, and a testing strategy. Use this skill whenever the user has a requirements document and wants a build plan, an implementation plan, a breakdown, a roadmap, or a PLAN.md — including loose phrasings like "plan out this feature from the requirements", "how should I build what's in REQUIREMENTS.md", "break this spec into tasks", or "create a PLAN.md". Trigger on any pairing of an existing requirements/spec file with a planning, sequencing, or task-breakdown output. The generated PLAN.md is ALWAYS written in Turkish.
---

# REQUIREMENTS.md → PLAN.md

Read a `REQUIREMENTS.md` and produce a `PLAN.md`: a concrete, sequenced plan an engineer can execute. The plan's job is to answer *how* and *in what order*, where the requirements answered *what*. Stay faithful to the requirements — the plan implements them, it does not redefine scope.

> **Output language:** The resulting `PLAN.md` MUST always be written in Turkish, regardless of the language of `REQUIREMENTS.md` or the user's prompt. Translate the template's section headers into Turkish and write all prose, tasks, risks, and checklist items in Turkish. Keep code identifiers, file paths, type/class names, and other technical tokens in their original form — do not translate them.

## Step 1: Read the requirements

Locate and read the source `REQUIREMENTS.md`. If the user named a path, use it; otherwise look in the working directory / repo root. If multiple candidates exist, ask which one. Read the whole file — summary, functional requirements, acceptance criteria, non-functional requirements, out-of-scope, dependencies, and open questions.

If the requirements file has **Open Questions** that materially block planning, surface them at the top of the plan under **Varsayımlar ve Açık Sorular** and state the assumption you're planning against, rather than silently picking one.

If a `REQUIREMENTS.md` doesn't exist yet, say so and offer to generate one first instead of inventing requirements.

## Step 2: Understand the codebase context

Before sequencing, get oriented in the project so tasks point at real code, not generic placeholders. Where a repository is available, scan the structure to learn the architecture, module boundaries, naming conventions, and testing setup. Reference actual file paths, layers, and components in the tasks. If no codebase is available, write the plan against the architecture described in the requirements and mark structural details as assumptions.

## Step 3: Build the plan

Decompose the requirements into **phases** — coherent chunks of work that can be reviewed and merged independently and that build on each other in a sensible order (e.g. data/model layer → service/repository → state management → UI → wiring → polish). Within each phase, list **atomic tasks**: small enough to estimate and verify, each tied back to the requirement(s) it satisfies.

Sequence by dependency, not by document order. Put foundational and high-uncertainty work early so risks surface sooner. Call out where work can proceed in parallel.

For each task, prefer describing the change in terms of files/layers touched and the observable outcome, over vague verbs. Map every functional requirement to at least one task so nothing is dropped, and don't introduce tasks that aren't traceable to a requirement (or are clearly necessary scaffolding — mark those `(scaffolding)`).

## Output template

Always produce a file named `PLAN.md`, **written in Turkish**, with this structure. Keep every header even if a section is short; write "Yok." rather than deleting a section, so the reader knows it was considered.

```markdown
# Uygulama Planı: {Özellik / İş Kalemi Başlığı}

> Kaynak: REQUIREMENTS.md ({varsa ID veya başlık})

## Genel Bakış
2–4 cümle: yaklaşımın sade bir dille açıklaması ve neden bu sıralamayla kurgulandığı.

## Varsayımlar ve Açık Sorular
Belirsizlik karşısında verilen kararlar ve hâlâ teyit edilmesi gereken sorular.
Her varsayım, etkilediği gereksinimi belirtir.

## Mimari ve Yaklaşım
Üst düzey teknik yaklaşım: hangi katmanlar/modüller/bileşenler işin içinde,
izlenecek temel desenler ve eklenen yeni soyutlamalar. Mümkün olduğunca
mevcut kod tabanı kurallarına bağlı kal.

## Aşamalar ve Görevler
### Aşama 1: {ad}
**Hedef:** bu aşamanın neyi teslim ettiği ve neden ilk sırada olduğu.
- [ ] Görev — {ne değişiyor, hangi dosyalar/katman} → GEREKSİNİM #{n} karşılanır
- [ ] Görev — ... → GEREKSİNİM #{n} karşılanır

### Aşama 2: {ad}
...

(Tüm aşamalar için devam et. Paralel yürütülebilecek işleri açıkça belirt.)

## Riskler ve Önlemler
Teknik riskler, bilinmeyenler ve dış bağımlılıklar; her biri için bir önlem
veya araştırma (spike) ile birlikte.

## Tamamlanma Tanımı (Definition of Done)
Tamamen işaretlendiğinde gereksinimlerin karşılandığı anlamına gelen kontrol
listesi: kabul kriterleri sağlandı, dokümanlar/changelog güncellendi vb.
```

## Quality bar

Before finalizing, check the plan against the requirements:

- The plan is written entirely in Turkish (headers, prose, tasks, and checklists), while technical identifiers and file paths remain untranslated.
- Every functional requirement is covered by at least one task (no silent drops).
- Phases are ordered by dependency; foundational/risky work comes early.
- Out-of-scope items from the requirements are not snuck back in as tasks.
- Tasks are concrete enough to act on, with file/layer references where the codebase is known.
- The plan reads as clear, professional Turkish.

## Delivery

Write the result to `PLAN.md` (repo root or the path the user indicates) so it sits next to `REQUIREMENTS.md` and can be committed together. If `PLAN.md` already exists, ask before overwriting or offer a suffixed name.