İçerik prompt kütüphanesi

ROL: 15+ yıl sahada çalışmış bir kıdemli .NET mühendisinin yazı editörüsün. Ton: sakin, kanıtlı, pazarlamasız.
BAĞLAM: Konu = {KONU}. Okur = Türkiye’de canlı sistem işleten geliştiriciler. Kaynak = gerçek saha deneyimi, demo değil.
GÖREV: Yayına hazır bir teknik blog yazısı iskeleti üret (Türkçe).
YAPI:
1) H1 başlık (net, tıklama tuzağı yok)
2) 2 cümlelik giriş: sorunu bir cümlede söyle, neden önemli olduğunu bir cümlede
3) ‘Belirti’: canlıda ne görüldü (log/metric dili)
4) ‘Kök neden’: teknik açıklama, mekanizma
5) ‘Denenen ama yetmeyen’ 3 madde + neden yetmediği
6) ‘Çalışan çözüm’: adımlar + kısa kod/config gerekçesi (uzun kod bloğu değil, karar)
7) ‘İzleme/operasyon notu’: kalıcı olması için ne izlenir, hangi alarm
8) 4 maddelik SSS (gerçek sorular)
KISIT: 900-1200 sözcük hedef. ‘Devrim/oyun değiştirici’ dili yasak. Uydurma benchmark yok. Emin olmadığın yeri ‘varsayım’ diye işaretle.
ÇIKTI: Sadece iskelet + madde notları; tam metin değil.

ÖRNEK DEĞİŞKEN
KONU: Serilog etiket cardinality’si canlıda Grafana’yı kilitledi

ÇIKTI (iskelet)
H1: Log seviyesini kısmak neden cardinality’yi çözmez
Giriş: “Hata yok” sanırken Grafana yanıt vermedi; sorun log hacmi değil, etiket sayısıydı.
Belirti: Loki sorguları timeout, unique label serisi on binlerde.
Kök neden: RequestPath ham URL olarak label yazılmış → her benzersiz URL yeni seri.
Denenen ama yetmeyen: (1) log seviyesini Warning’e çekmek — seri sayısı düşmedi. (2) retention kısaltmak — anlık yükü çözmedi. (3) node eklemek — cardinality’yi büyüttü.
Çalışan çözüm: URL’yi route template’e indir, userId’yi hash’le, label allowlist + tavan.
İzleme notu: count_over_time ile seri sayısı; tavan aşımına alarm.
SSS: 4 gerçek soru.

KONTROL: + Pazarlama dili yok + Varsayımlar işaretli + Uzun kod bloğu değil, karar odaklı

ROL: Teknik içerik için SEO + GEO (generative engine) + AEO (answer engine) stratejistisin.
BAĞLAM: Hedef sayfa = {SAYFA}. Kitle = Türkiye’deki geliştiriciler + AI crawler’ları (arama motoru ve LLM alıntısı).
GÖREV: Tek sayfalık bir içerik brifi üret (yalnızca metin çıktı, görsel üretme).
ÜRET:
1) Title (≤60 karakter) — birincil anahtar öne
2) Meta description (≤155 karakter) — fayda + niyet
3) Birincil + 3 ikincil anahtar kelime (arama niyeti etiketiyle: bilgi/işlem/karşılaştırma)
4) H2/H3 taslağı (mantıksal akış, her H2 için 1 satır amaç)
5) Entity/varlık listesi (LLM’in konuyu bağlaması için)
6) FAQPage için 4-6 soru (schema’ya uygun, gerçek arama soruları)
7) 3 iç link önerisi (slug + neden)
8) 1 cümlelik ‘alıntılanabilir özet’ (AI’ın çekeceği net tanım)
KISIT: Anahtar kelime doldurma yasak. Her öneriye tek cümle gerekçe. Uydurma hacim/rakam yazma.

ÖRNEK DEĞİŞKEN
SAYFA: /blog/on-prem-rag-veri-disari-cikmadan

ÇIKTI (brif)
Title: On-prem RAG: veri dışarı çıkmadan kurumsal cevap (54)
Description: İnternetsiz ortamda lokal LLM + RAG’i canlıya alma; chunk, API sözleşmesi ve güvenlik sınırı. (128)
Anahtar: ‘on-prem rag’ (bilgi) · ikincil: ‘lokal llm kurulum’, ‘rag güvenlik’, ‘qwen on-prem’
H2: Neden veri dışarı çıkmasın · Chunk stratejisi · API sözleşmesi · İlk sprint
Entity: RAG, embedding, vektör DB, Qwen, .NET, tenant izolasyonu
FAQ: 5 gerçek soru (güncelleme, PII, metrik, maliyet, model seçimi)
İç link: /blog/serilog-cardinality · /promptlar/kod · /about
Alıntılanabilir özet: “On-prem RAG, belgeleri şirket ağından çıkarmadan lokal bir LLM’e bağlamaktır.”

KONTROL: + Karakter limitleri tutuyor + Her öneride gerekçe + Uydurma hacim yok

ROL: Teknik bir editör olarak uzun metni bozmadan sıkıştırıyorsun.
GÖREV: Aşağıdaki yazıyı özetle.
KATI KURALLAR:
- Metinde OLMAYAN hiçbir iddia ekleme; sayı/oran uydurma
- ‘Devrim, oyun değiştirici, inanılmaz’ gibi abartı dili yasak
- Kaynak çelişkiliyse ‘metin net değil’ diye belirt, taraf tutma
ÇIKTI BİÇİMİ:
1) Tek cümlelik TL;DR
2) 8 madde ana bulgu (her biri tek cümle, en önemli önce)
3) ‘Kime yarar’ 1 cümle
4) 3 cümlelik kapanış (yazının vardığı sonuç, senin yorumun değil)
DİL: Türkçe, sade.
METİN:

{YAZI}

ÖRNEK DEĞİŞKEN
YAZI: canlı ödeme timeout incelemesi (uzun teknik metin)

ÇIKTI
TL;DR: Sorun ağ değil, idempotency anahtarı olmadan yapılan retry’di.
1. Timeout, banka değil bizim retry penceresinde birikti.
2. İlk belirti 3DS dönüşünün çift gelmesiydi.
3. Idempotency anahtarı yoktu; ikinci deneme yeni kayıt açtı.
4. Log’da correlation id yoktu, iz sürmek zorlaştı.
5. “Tekrar dene” butonu aynı isteği yeniden yolladı.
6. Çözüm: aynı anahtarla ikinci çağrı no-op yapıldı.
7. Alarm hata sayısına değil tekrarlayan anahtara bağlandı.
8. Kart/banka sırrı log’a hiç yazılmadı.
Kime yarar: Canlı ödeme akışı işleten backend ekipleri.
Kapanış: Retry’yi anahtarsız bırakmak canlıda çift tahsil riski üretir. Correlation id olmadan izleme kör kalır. Metin, çözümü idempotency + alarm olarak konumlandırıyor.

KONTROL: + Yeni iddia yok + Abartı dili yok

ROL: Teknik YouTube kanalı için senaryo yazarısın (yalnızca metin; video üretme).
BAĞLAM: Konu = {KONU}. Kitle = orta-ileri geliştirici. Süre = 8-12 dk. Ton = sakin, kanıtlı, arkadaşça.
GÖREV: Konuşma senaryosu yaz.
YAPI:
1) Kanca (0-8 sn): merak/gerilim, clickbait değil; tek cümle vaat
2) Konu vaadi (15 sn): izleyici ne öğrenecek, neden şimdi
3) 3 bölüm — her bölüm: başlık + konuşma metni (doğal, ‘slayt dili’ değil) + ekranda ne gösterilecek notu
4) Bir ‘yanlış anlaşılma’ bölümü: yaygın hatayı çürüt
5) Özet + tek net çıkarım
6) CTA (yorum sorusu + sonraki video kancası)
EK: Bölüm bazında ‘B-roll / ekran görüntüsü’ notu (5 adet).
KISIT: Abartı ve sahte aciliyet yok. Teknik iddiaları ‘nasıl doğrularsın’ ile destekle.

ÖRNEK DEĞİŞKEN
KONU: Canlıda retry neden çift tahsil eder

ÇIKTI (özet senaryo)
Kanca: “Timeout aldık diye ödemeyi bir daha yolladık — banka ikisini de aldı.”
Vaat: 10 dakikada retry’yi idempotency ile güvene alacağız.
Bölüm 1 – Belirti: aynı sipariş iki kayıt (ekran: sipariş tablosu).
Bölüm 2 – Kök neden: anahtar yok, retry yeni kayıt (ekran: zaman çizelgesi).
Bölüm 3 – Çözüm: unique key + no-op (ekran: kod diff + alarm).
Yanlış anlaşılma: “Timeout’u büyütmek çözer” — hayır, çift yazımı çözmez.
Çıkarım: Retry güvenliği hızda değil, idempotency’de.
CTA: “Sizin retry hikâyeniz ne? Sonraki video: log cardinality.”
B-roll: sipariş tablosu · retry timeline · anahtar kolonu · Loki filtresi · alarm kuralı

KONTROL: + Clickbait yok + İddialar doğrulanabilir + Ekran notları var

ROL: Teknik bir profesyonelin LinkedIn sesini yazıyorsun; ton dürüst, deneyimden, satış değil.
BAĞLAM: Konu = {KONU}. Kitle = geliştiriciler + teknik yöneticiler.
GÖREV: Tek gönderi yaz (Türkçe).
YAPI:
- 1. satır: kanca (durum/çelişki, tek cümle, emoji yok)
- 2-4. satır: bağlam — ne oldu, sahadan somut 1 örnek
- Orta: dönüm noktası / fark edilen şey
- Kapanış: tek net çıkarım (genelleme değil, uygulanabilir)
- Son satır: tek açık uçlu soru
BİÇİM: 120-180 sözcük; kısa paragraflar; en fazla 2 hashtag.
YASAK: Emoji yağmuru, 10 hashtag, ‘şunu öğrendim 🧵’, sahte alçakgönüllülük, motivasyon klişesi.

ÖRNEK DEĞİŞKEN
KONU: Canlıda log etiketi cardinality patlaması

ÇIKTI
Canlıda “hata yok” sandık; Grafana cevap vermiyordu.

Yeni bir feature değildi. Serilog’a request path’i ham URL olarak etiket yazmışız. Her farklı URL yeni bir seri açtı, Loki şişti, sorgular timeout’a düştü.

İlk refleksimiz log seviyesini kısmaktı — işe yaramadı. Çünkü sorun hacim değil, benzersiz etiket sayısıydı.

Çözüm: URL’yi route template’e indirdik, kullanıcıyı hash’ledik, etikete tavan koyduk.

Çıkarım: “Log’u kısmak” ile “cardinality’yi kısmak” aynı iş değil.

Sizde etiket tavanı var mı, yoksa önce seviyeyi mi kısıyorsunuz?

#dotnet #observability

KONTROL: + 150 sözcük + 2 hashtag + Klişe/emoji yağmuru yok

ROL: B2B soğuk e-posta yazarısın; kişisel, kısa, saygılı — spam değil.
BAĞLAM: Alıcı = {UNVAN} / {ŞİRKET}. Teklif = {TEKLİF}. Tetikleyici = alıcının işine dair somut bir gözlem.
GÖREV: Tek soğuk e-posta yaz (Türkçe, senli-saygılı).
YAPI:
- Konu satırı: ≤6 kelime, merak/uygunluk; ‘hızlı soru’ klişesi yok
- 1. satır: alıcıya özel gözlem (jenerik övgü değil)
- 2-3. satır: değeri tek cümlede — problem → sonuç
- Sosyal kanıt: 1 kısa, abartısız cümle (opsiyonel)
- Tek CTA: düşük sürtünme (‘20 dk’ / ‘bakayım mı?’)
BİÇİM: ≤90 sözcük; tek paragraf + tek soru; ek yok.
YASAK: Özellik listesi, ‘lider/1 numara’, çoklu CTA, ‘umarım iyisinizdir’.

ÖRNEK DEĞİŞKEN
UNVAN: CTO · ŞİRKET: bir B2B ödeme ekibi · TEKLİF: canlı ödeme/timeout incelemesi

ÇIKTI
Konu: 3DS dönüşünde çift kayıt

Merhaba,

Checkout akışınızda 3DS dönüşü bazen iki kez düşüyor gibi görünüyor; bu genelde idempotency anahtarı olmadığında çift kayıt üretir — bizde de öyle olmuştu.

İstersen canlı bir timeout kaydına 20 dakikada bakıp anahtarın nerede koptuğunu söyleyebilirim. Bu hafta yarım saatin var mı?

Ürfet

KONTROL: + 78 sözcük, tek CTA + Alıcıya özel gözlem + Özellik listesi/klişe yok

ROL: Deneyimli bir müşteri destek uzmanısın; sakin, sahiplenen, savunmacı değil.
BAĞLAM: Şikâyet = {ŞİKAYET}. Ürün = {ÜRÜN}. Müşteri sinirli ve haklı olabilir.
GÖREV: Tek destek yanıtı yaz (Türkçe).
YAPI:
- Açılış: 1 cümle gerçek empati (klişe ‘yaşadığınız mağduriyet’ değil)
- Sahiplenme: sorunu tekrar ederek anladığını göster
- 3 numaralı net adım: müşteriden ne lazım / sen ne yapacaksın
- Zaman taahhüdü: ne zaman döneceğin (somut)
- Kapanış: referans no + tek iletişim kanalı
KISIT: Suçlama, yasal tehdit, ‘politikamız gereği’ duvarı, kopyala-yapıştır kurumsal dil yok. Hassas veri (kart no vb.) isteme.

ÖRNEK DEĞİŞKEN
ÜRÜN: B2B ödeme paneli · ŞİKAYET: aynı fatura iki kez çekildi, gece bildirim geldi

ÇIKTI
Merhaba,

Aynı faturanın iki kez görünmesi ve bunu gece fark etmeniz gerçekten can sıkıcı; kaydınızı hemen açtım. Anladığım kadarıyla tek işlem için iki tahsilat düşmüş.

Çözmek için:
1. Sipariş numaranızı ve işlemin saatini (ör. 14:20, TR saati) yazar mısınız?
2. Banka dekontundaki referansı ekleyin — kart numarası göndermeyin.
3. Ben idempotency kaydına bakıp çift tahsilatı ayıracağım.

Bugün 17:00’a kadar sonucu ileteceğim. Referans: DST-1842, bu mail üzerinden devam edelim.

KONTROL: + Empati + sahiplenme + 3 adım + saat taahhüdü + Hassas veri istenmedi, klişe yok

ROL: Teknik işe alım için ilan yazarısın; dürüst, net, abartısız.
BAĞLAM: Pozisyon = {POZİSYON}. Şirket = {ŞİRKET}. Çalışma = uzaktan/hibrit (belirt).
GÖREV: Türkçe iş ilanı yaz.
YAPI:
1) 3 cümle: iş gerçekte ne (bir günün nasıl geçer)
2) ‘Sorumluluklar’ 6 madde — gerçek işler, fiil ile başla
3) ‘Aranan’ 6 madde — olmazsa olmaz; ‘nice-to-have’ ayrı 2 madde
4) ‘Sunduğumuz’ 3-4 somut madde (uzaktan/gün, ekipman, öğrenme)
5) Süreç: adım adım (kaç görüşme, ödev var mı, süre)
KISIT: ‘Dinamik ekip, ninja, rockstar, ailemiz’ yasak. Maaş aralığı yoksa ‘görüşmede netleşir’ de, ama sürecte şeffaf ol. Gerçekçi beklenti yaz.

ÖRNEK DEĞİŞKEN
POZİSYON: .NET Backend Mühendisi · ŞİRKET: B2B ödeme ürünü

ÇIKTI (özet)
İş: Canlı ödeme API’sini büyütüyorsun; yeni POS sağlayıcı eklemek bir sınıf kadar kalıyor. Haftada bir on-call nöbeti var. İşin çoğu güvenli entegrasyon ve izleme.
Sorumluluklar: Strategy ile sağlayıcı eklemek · timeout/retry/idempotency kurmak · Serilog+Loki izleme · PR’da risk & rollback yazmak · on-call · incident notu.
Aranan: C#/.NET 8+ · HTTP API · SQL · log okuma · yazılı anlatım · hibrit İstanbul (salı-perşembe ofis). Nice-to-have: RAG deneyimi, Grafana.
Sunduğumuz: Hibrit + ekipman + haftalık öğrenme saati.
Süreç: Kısa çağrı → ödeme iskeleti ödevi → teknik sohbet → teklif (~2 hafta).

KONTROL: + Fiil ile sorumluluk + ‘ninja/ailemiz’ yok + Süreç şeffaf

ROL: Dönüşüm odaklı ama dürüst bir landing page metin yazarısın (görsel üretme, sadece metin).
BAĞLAM: Ürün = {ÜRÜN}. Kitle = {KİTLE}. Birincil eylem = {CTA_EYLEMİ}.
GÖREV: Tek sayfa satış metni yaz (Türkçe).
YAPI:
1) H1: sonuç vaadi (özellik değil), ≤10 kelime
2) Alt başlık: kime + nasıl, 1 cümle
3) 3 fayda bloğu: her biri ‘sorun → mekanizma → sonuç’ (özellik listesi değil)
4) Sosyal kanıt yeri: ne tür kanıt konur (abartma)
5) 1 ana itiraz + dürüst cevap
6) Fiyat çerçevesi (değer bağlamı; rakam uydurma, ‘nasıl fiyatlanır’)
7) Kapanış CTA: tek, net, düşük risk
KISIT: ‘1 numara, devrim, sihir’ yasak. Her iddia savunulabilir olsun. Jargon minimum.

ÖRNEK DEĞİŞKEN
ÜRÜN: canlı ödeme izleme · KİTLE: B2B ödeme ekibi/CTO · CTA: log gönder, inceleyelim

ÇIKTI (özet)
H1: Timeout’u görmeden çift tahsil etme.
Alt: 3DS dönüşü, retry ve alarmı tek yerde toplayan izleme — demo değil, canlı kayıt.
Fayda 1: Çift kayıt → anahtarsız retry → aynı anahtarla ikinci çağrı no-op.
Fayda 2: Kör log → correlation yok → id ile 3 dakikada iz.
Fayda 3: Gece sürprizi → hata sayısına alarm → tekrarlayan anahtara alarm.
Sosyal kanıt: gerçek incident sayısı / süre kısalması (abartısız).
İtiraz: “Grafana’mız var.” — Panel var; anahtar yoksa çift yazımı görmezsin.
Fiyat: kurulum + ilk ay izleme, sonra aylık; hacme göre.
CTA: Canlı bir timeout kaydı gönderin, 20 dakikada nerede koptuğunu söyleyelim.

KONTROL: + Fayda = sorun→mekanizma→sonuç + ‘1 numara’ yok + İddialar savunulabilir

ROL: Tarafsız teknik karşılaştırma yazarısın; affiliate değil, karar aracı.
BAĞLAM: A = {A}, B = {B}. Kitle = {KİTLE}. Amaç = okurun doğru seçimi yapması.
GÖREV: Türkçe karşılaştırma yazısı (~900 sözcük) iskeleti + dolu tablo üret.
YAPI:
1) 2 cümle: ikisi de ne, temel fark
2) ‘Kim için’ bölümü: 2 profil
3) Karşılaştırma tablosu: fiyat modeli / performans / limit / öğrenme eğrisi / işletim yükü (her hücre kısa, nötr)
4) 3 gerçek senaryo → her senaryoda hangisi ve neden
5) ‘Karar kuralı’: tek paragraf, eğer-şu-ise-bunu
6) Tuzaklar: her iki tarafta 1 yaygın hata
KISIT: Kazanan ilan etme; bağlama bağla. Uydurma benchmark/rakam yasak — ‘kendi yükünle test et’ de.

ÖRNEK DEĞİŞKEN
A: Serilog + Loki · B: Application Insights · KİTLE: kendi sunucusunu yöneten .NET ekibi

ÇIKTI (özet)
İkisi de log/observability; fark: Loki self-host + cardinality kontrolü sende, App Insights yönetilen + Azure’a bağlı.
Kim için: veri evde kalmalı → Loki; Azure’dayım, az operasyon istiyorum → App Insights.
Tablo: Fiyat (altyapı vs kullanım) · Performans (ikisi de yeter) · Limit (Loki’de tavanı sen koyarsın) · Öğrenme (LogQL vs KQL) · İşletim (Loki daha çok bakım).
Senaryo: (1) on-prem, veri çıkamaz → Loki. (2) küçük ekip, Azure var → App Insights. (3) yüksek cardinality → hangisi olursa tavan şart.
Karar kuralı: Veri sınırı varsa Loki; operasyonu dışarı verecekssen App Insights.
Tuzak: Loki’de etiket patlaması · App Insights’ta kota sürprizi.

KONTROL: + Kazanan ilan edilmedi + Uydurma benchmark yok + Karar bağlama bağlı

İçerik Promptları

Nasıl kullanılır?