一键在 Manus 中运行任何 Skill

karpathy-guidelines

星标2

分支0

更新时间2026年4月22日 22:05

LLM kodlama hatalarini azaltan davranissal kurallar. Kod yazarken, review yaparken veya refactor ederken — overengineering'i, gereksiz degisikligi, sessiz varsayimlari onlemek ve dogrulanabilir basari kriteri tanimlamak icin otomatik aktif et.

安装

用 Codex 或 Claude 帮你安装复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。

在 Manus 中运行

来源

huseyindol

huseyindol/elly

打开 GitHub 仓库查看创作者相关仓库

下载

在 Manus 中运行

Karpathy Guidelines

Andrej Karpathy'nin LLM kodlama tuzaklari gozlemlerinden turetilmis davranissal kurallar. Elly projesindeki diger skill'lerle (elly-conventions, multitenant-routing, vb.) birlikte uygula; bunlar nasil davranacagini, digerleri ne yapacagini anlatir.

Tradeoff: Bu kurallar hizdan cok dikkati onceler. Trivial gorevler icin (tek satir fix, typo) overhead yaratma.

1. Think Before Coding

Varsayma. Kafan karisiksa saklama. Tradeoff'lari yuzeye cikar.

Kod yazmadan once:

Varsayimlarini acik soyle. Emin degilsen sor.
Birden fazla yorum varsa hepsini sun — sessizce birini secme.
Daha basit bir yol varsa soyle. Gerektiginde itiraz et.
Belirsizlik varsa dur. Neyin net olmadigini adlandir. Sor.

2. Simplicity First

Problemi cozen minimum kod. Spekulatif bir sey yok.

Istenmeyen ozellik ekleme.
Tek kullanimlik koda abstraction kurma.
Istenmeyen "esneklik" / "configurability" koyma.
Olmayacak senaryolara error handling yazma.
200 satir yazdin ama 50 satir yetseydi, yeniden yaz.

Test sorusu: "Senior bir muhendis buna 'overengineered' der mi?" — Evetse basitlestir.

3. Surgical Changes

Sadece gerekeni degistir. Sadece kendi yarattigin kirliligi temizle.

Mevcut kodu duzenlerken:

Cevredeki kod / yorum / formatlamayi "iyilestirmeye" calisma.
Bozuk olmayan seyi refactor etme.
Mevcut stili bozma, kendi tarzini dayatma.
Ilgisiz dead code gorursen bahset, silme.

Degisikliklerin orphan yaratirsa:

Senin degisikligin yuzunden kullanilmayan import/variable/function'lari kaldir.
Onceden var olan dead code'u talep olmadan silme.

Test: Degisen her satir dogrudan kullanicinin talebine baglanmali.

4. Goal-Driven Execution

Basari kriterini tanimla. Dogrulanana kadar loop et.

Gorevleri dogrulanabilir hedeflere cevir:

"Validation ekle" → "Invalid input icin test yaz, sonra gecsin"
"Bug'i fix'le" → "Bug'i reproduce eden test yaz, sonra gecsin"
"X'i refactor et" → "Oncesinde ve sonrasinda testler gecsin"

Cok adimli gorevlerde kisa bir plan sun:

1. [Adim] → dogrulama: [check]
2. [Adim] → dogrulama: [check]
3. [Adim] → dogrulama: [check]

Guclu basari kriteri bagimsiz loop'a izin verir. Zayif kriter ("calissin iste") surekli clarification gerektirir.

Calisiyor olmasinin isareti: diff'lerde gereksiz degisiklik azalir, overengineering yuzunden rewrite azalir, clarifying sorular hatalardan once gelir.

同仓库更多 Skills

同仓库

elly-project-mastery

huseyindol/elly

Elly CMS projesine tam hakimiyet skill'i. Her yeni oturumda OTOMATIK aktif et — proje durumunu oku, kaldığın yerden devam et, geliştirmeleri kaydet. Sıfırdan başlama, mevcut halinden al.

2026-06-162

multitenant-routing

huseyindol/elly

Multi-tenant veri yönlendirme, tenant context yönetimi ve tenant izolasyonu. Tenant routing, DataSource değiştirme, tenant-specific query veya tenant context hataları ile ilgili konularda otomatik aktif et.

2026-06-162

chat-patterns

huseyindol/elly

Elly chat sisteminin pattern'leri — WebSocket+STOMP konfigürasyonu, rol bazlı görünürlük (visibilityLevel), davet hiyerarşisi, real-time broadcast topic'leri, multi-tenant chat routing, dosya yükleme. Chat endpoint ekleme, WebSocket topic tanımlama, mesaj akışı debug veya rol/davet kuralı değişikliğinde otomatik aktif et.

2026-05-172

error-handling-patterns

huseyindol/elly

Elly'deki exception hiyerarşisi, GlobalExceptionHandler, ErrorResponse formatı ve yeni exception ekleme pattern'leri. Hata yönetimi, yeni exception tipi veya API error response tasarımında otomatik aktif et.

2026-04-132

rabbitmq-patterns

huseyindol/elly

Elly'deki RabbitMQ queue, exchange, retry ve DLQ pattern'leri. Yeni queue ekleme, consumer yazma, retry mekanizması veya mesaj akış sorunlarında otomatik aktif et.

2026-04-132

redis-cache-patterns

huseyindol/elly

Elly'deki Redis cache konfigürasyonu, tenant-isolated key yapısı, TTL, invalidation ve graceful error handling pattern'leri. Cache ekleme, invalidation sorunu veya performans optimizasyonunda otomatik aktif et.

2026-04-132

name	karpathy-guidelines
description	LLM kodlama hatalarini azaltan davranissal kurallar. Kod yazarken, review yaparken veya refactor ederken — overengineering'i, gereksiz degisikligi, sessiz varsayimlari onlemek ve dogrulanabilir basari kriteri tanimlamak icin otomatik aktif et.
license	MIT
source	https://github.com/forrestchang/andrej-karpathy-skills

Karpathy Guidelines

Tradeoff: Bu kurallar hizdan cok dikkati onceler. Trivial gorevler icin (tek satir fix, typo) overhead yaratma.

1. Think Before Coding

Varsayma. Kafan karisiksa saklama. Tradeoff'lari yuzeye cikar.

Kod yazmadan once:

Varsayimlarini acik soyle. Emin degilsen sor.
Birden fazla yorum varsa hepsini sun — sessizce birini secme.
Daha basit bir yol varsa soyle. Gerektiginde itiraz et.
Belirsizlik varsa dur. Neyin net olmadigini adlandir. Sor.

2. Simplicity First

Problemi cozen minimum kod. Spekulatif bir sey yok.

Istenmeyen ozellik ekleme.
Tek kullanimlik koda abstraction kurma.
Istenmeyen "esneklik" / "configurability" koyma.
Olmayacak senaryolara error handling yazma.
200 satir yazdin ama 50 satir yetseydi, yeniden yaz.

Test sorusu: "Senior bir muhendis buna 'overengineered' der mi?" — Evetse basitlestir.

3. Surgical Changes

Sadece gerekeni degistir. Sadece kendi yarattigin kirliligi temizle.

Mevcut kodu duzenlerken:

Cevredeki kod / yorum / formatlamayi "iyilestirmeye" calisma.
Bozuk olmayan seyi refactor etme.
Mevcut stili bozma, kendi tarzini dayatma.
Ilgisiz dead code gorursen bahset, silme.

Degisikliklerin orphan yaratirsa:

Senin degisikligin yuzunden kullanilmayan import/variable/function'lari kaldir.
Onceden var olan dead code'u talep olmadan silme.

Test: Degisen her satir dogrudan kullanicinin talebine baglanmali.

4. Goal-Driven Execution

Basari kriterini tanimla. Dogrulanana kadar loop et.

Gorevleri dogrulanabilir hedeflere cevir:

"Validation ekle" → "Invalid input icin test yaz, sonra gecsin"
"Bug'i fix'le" → "Bug'i reproduce eden test yaz, sonra gecsin"
"X'i refactor et" → "Oncesinde ve sonrasinda testler gecsin"

Cok adimli gorevlerde kisa bir plan sun:

1. [Adim] → dogrulama: [check]
2. [Adim] → dogrulama: [check]
3. [Adim] → dogrulama: [check]

Guclu basari kriteri bagimsiz loop'a izin verir. Zayif kriter ("calissin iste") surekli clarification gerektirir.

Calisiyor olmasinin isareti: diff'lerde gereksiz degisiklik azalir, overengineering yuzunden rewrite azalir, clarifying sorular hatalardan once gelir.