| Dimension | Shared | Only in A | Only in B | Overlap |
|---|---|---|---|---|
| Sections | 1 | 5 | 4 | 10% |
| Commands | 0 | 0 | 0 | — |
| Section tags | 2 | 1 | 1 | 50% |
What each file covers
Sections
1 shared · 5 only in A · 4 only in B- − Communication style
- − Development workflow
- − Coding best practices
- − Project context
- − Other guidelines
- + Plan Structure and Hierarchy
- + Analysis and Alternatives
- + Style and Markdown Rules
- + Tone and Approach
- Brief overview
Commands
neither file has anySection tags
2 shared · 1 only in A · 1 only in B- − agent-behaviour
- + do-not
- code-style
- architecture
Line diff
Winterus20/PenceAI · .clinerules/genel-kurallar.md
@@ −1 @@
1## Brief overview
2Bu dosya, proje için genel iletişim tercihlerini, geliştirme iş akışlarını ve kodlama standartlarını tanımlar. Kullanıcı izole edilmiş ve net kurallar talep etmiştir.
3
4## Communication style
5- Yapay zeka (Cline) her zaman Türkçe (tr) konuşmalıdır.
6- Yanıtlar her zaman kısa, net ve doğrudan konuya odaklı olmalıdır.
7- Konuşkanlıktan (conversational tone) kaçınılmalı, tamamen teknik ve çözüm odaklı bir dil kullanılmalıdır.
8
9## Development workflow
10- Görevler küçük, yönetilebilir ve mantıksal adımlara (step-by-step) bölünmelidir.
11- Her adımın başarılı olduğu doğrulanmadan bir sonrakine geçilmemelidir.
12- Dosya değişikliklerinde projenin mevcut dosya yapısına uygun olarak hareket edilmelidir.
13
14## Coding best practices
15- Temiz kod (Clean Code) prensiplerine sıkı sıkıya bağlı kalınmalıdır.
16- İsimlendirmeler açıklayıcı olmalı ve projedeki mevcut isimlendirme standartlarıyla tutarlılık göstermelidir.
17- Her kod değişikliğinde güvenlik, performans ve okunabilirlik göz önünde bulundurulmalıdır.
18
19## Project context
20- PenceAI projesi içerisinde çalışılmakta olup, çeşitli ajansal (agent, llm, memory) yapılar bulunmaktadır.
21- Mevcut mimari yapıya saygı gösterilmeli ve yeni dosyalar doğru dizinlere (örneğin src/ altına) yerleştirilmelidir.
22
23## Other guidelines
24- Görev tamamlama işlemi her zaman kullanıcı onayı ve test güvencesi ile kapatılmalıdır.
25- Sistem komutları çalıştırılırken (execute_command) proje kök dizini yapısı dikkate alınmalıdır.
Winterus20/PenceAI · .clinerules/implementation-plan-format.md
@@ +1 @@
1## Brief overview
2Bu dosya, projede oluşturulacak "Implementation Plan" (Uygulama Planı) süreçleri için zorunlu yapı, stil, içerik ve yaklaşım standartlarını tanımlar.
3
4## Plan Structure and Hierarchy
5- Planlar yapısal bölümlerden oluşmalı ve her bölüm başlığının hemen altında bir yatay çizgi (`---`) bulunmalıdır.
6- **[Goal Description]:** Görevin özeti, arka planı ve ulaşılmak istenen hedef kısa ve öz bir şekilde açıklanmalıdır.
7- **User Review Required:** Onay gerektiren mimari kararlar ve riskli değişiklikler belirtilmelidir. Bu bölümde GitHub tarzı Alert kartları (`> [!IMPORTANT]`, `> [!WARNING]`, `> [!CAUTION]`) zorunludur.
8- **Proposed Changes:** Değişiklikler bileşenlere veya servis katmanlarına göre gruplandırılmalıdır. Detaylar şu formatta verilmelidir:
9 - `#### [NEW] dosya_adi.js`
10 - `#### [MODIFY] dosya_adi.ts`
11 - `#### [DELETE] dosya_adi.css`
12- **Open Questions:** Açığa kavuşmamış teknik sorular ve tasarım kararları listelenmelidir.
13- **Verification Plan:** Değişikliklerin doğrulama adımları her zaman `Automated Tests` ve `Manual Verification` olmak üzere iki alt başlıkta belirtilmelidir.
14
15## Analysis and Alternatives
16- Önerilen her yeni sistem veya teknik değişiklik için artı ve eksi (pros/cons) analizleri açıkça yazılmalıdır.
17- Kullanıcı talep ettiğinde veya mantıklı görüldüğünde mimari veya pratik alternatifler plana dahil edilmelidir.
18
19## Style and Markdown Rules
20- Başlık hiyerarşisi kesinlikle markdown kurallarına uymalıdır (Ana başlıklarda `#`, alt başlıklarda `##` ve `###`).
21- Vurgulanması gereken kritik durumlar hariç gereksiz kalın (bold) yazılardan kaçınılmalı, kritik uyarılarda GitHub Alert yapısı tercih edilmelidir.
22- Gerekli durumlarda değişikliğin anlaşılması için kısa diff'ler veya formatlı kod blokları eklenmelidir.
23- Dosya isimleri ve dizin yolları belirginleştirilmeli, daima projenin hiyerarşik yapısına uygun bir liste izlenmelidir.
24
25## Tone and Approach
26- Ton daima profesyonel, sonuç odaklı ve sıkı bir mühendislik disiplini çerçevesinde olmalıdır.
27- Konuşma dili ve gereksiz dolgu cümleleri kesinlikle kullanılmamalı, doğrudan teknik eksene odaklanılmalıdır.
@@ −1 +1 @@
11 ## Brief overview
2−Bu dosya, proje için genel iletişim tercihlerini, geliştirme iş akışlarını ve kodlama standartlarını tanımlar. Kullanıcı izole edilmiş ve net kurallar talep etmiştir.
2+Bu dosya, projede oluşturulacak "Implementation Plan" (Uygulama Planı) süreçleri için zorunlu yapı, stil, içerik ve yaklaşım standartlarını tanımlar.
33
4−## Communication style
5−- Yapay zeka (Cline) her zaman Türkçe (tr) konuşmalıdır.
6−- Yanıtlar her zaman kısa, net ve doğrudan konuya odaklı olmalıdır.
7−- Konuşkanlıktan (conversational tone) kaçınılmalı, tamamen teknik ve çözüm odaklı bir dil kullanılmalıdır.
4+## Plan Structure and Hierarchy
5+- Planlar yapısal bölümlerden oluşmalı ve her bölüm başlığının hemen altında bir yatay çizgi (`---`) bulunmalıdır.
6+- **[Goal Description]:** Görevin özeti, arka planı ve ulaşılmak istenen hedef kısa ve öz bir şekilde açıklanmalıdır.
7+- **User Review Required:** Onay gerektiren mimari kararlar ve riskli değişiklikler belirtilmelidir. Bu bölümde GitHub tarzı Alert kartları (`> [!IMPORTANT]`, `> [!WARNING]`, `> [!CAUTION]`) zorunludur.
8+- **Proposed Changes:** Değişiklikler bileşenlere veya servis katmanlarına göre gruplandırılmalıdır. Detaylar şu formatta verilmelidir:
9+ - `#### [NEW] dosya_adi.js`
10+ - `#### [MODIFY] dosya_adi.ts`
11+ - `#### [DELETE] dosya_adi.css`
12+- **Open Questions:** Açığa kavuşmamış teknik sorular ve tasarım kararları listelenmelidir.
13+- **Verification Plan:** Değişikliklerin doğrulama adımları her zaman `Automated Tests` ve `Manual Verification` olmak üzere iki alt başlıkta belirtilmelidir.
814
9−## Development workflow
10−- Görevler küçük, yönetilebilir ve mantıksal adımlara (step-by-step) bölünmelidir.
11−- Her adımın başarılı olduğu doğrulanmadan bir sonrakine geçilmemelidir.
12−- Dosya değişikliklerinde projenin mevcut dosya yapısına uygun olarak hareket edilmelidir.
15+## Analysis and Alternatives
16+- Önerilen her yeni sistem veya teknik değişiklik için artı ve eksi (pros/cons) analizleri açıkça yazılmalıdır.
17+- Kullanıcı talep ettiğinde veya mantıklı görüldüğünde mimari veya pratik alternatifler plana dahil edilmelidir.
1318
14−## Coding best practices
15−- Temiz kod (Clean Code) prensiplerine sıkı sıkıya bağlı kalınmalıdır.
16−- İsimlendirmeler açıklayıcı olmalı ve projedeki mevcut isimlendirme standartlarıyla tutarlılık göstermelidir.
17−- Her kod değişikliğinde güvenlik, performans ve okunabilirlik göz önünde bulundurulmalıdır.
19+## Style and Markdown Rules
20+- Başlık hiyerarşisi kesinlikle markdown kurallarına uymalıdır (Ana başlıklarda `#`, alt başlıklarda `##` ve `###`).
21+- Vurgulanması gereken kritik durumlar hariç gereksiz kalın (bold) yazılardan kaçınılmalı, kritik uyarılarda GitHub Alert yapısı tercih edilmelidir.
22+- Gerekli durumlarda değişikliğin anlaşılması için kısa diff'ler veya formatlı kod blokları eklenmelidir.
23+- Dosya isimleri ve dizin yolları belirginleştirilmeli, daima projenin hiyerarşik yapısına uygun bir liste izlenmelidir.
1824
19−## Project context
20−- PenceAI projesi içerisinde çalışılmakta olup, çeşitli ajansal (agent, llm, memory) yapılar bulunmaktadır.
21−- Mevcut mimari yapıya saygı gösterilmeli ve yeni dosyalar doğru dizinlere (örneğin src/ altına) yerleştirilmelidir.
22−
23−## Other guidelines
24−- Görev tamamlama işlemi her zaman kullanıcı onayı ve test güvencesi ile kapatılmalıdır.
25−- Sistem komutları çalıştırılırken (execute_command) proje kök dizini yapısı dikkate alınmalıdır.
25+## Tone and Approach
26+- Ton daima profesyonel, sonuç odaklı ve sıkı bir mühendislik disiplini çerçevesinde olmalıdır.
27+- Konuşma dili ve gereksiz dolgu cümleleri kesinlikle kullanılmamalı, doğrudan teknik eksene odaklanılmalıdır.
