# Codex için İş Akışınızı Geliştirecek En İyi 10 Ajan Becerisi

> Projeleri planlama, başarısız CI hatlarında hata ayıklama, uygulamaları test etme, tasarımları uygulama, web projelerini dağıtma ve günlük geliştirme iş akışlarını düzene koyma için en iyi Codex becerilerini keşfedin.

- Canonical: https://nanoskill.ai/tr/blog/best-agent-skills-for-codex
- Markdown: https://nanoskill.ai/tr/blog/best-agent-skills-for-codex.md
- Author: Jeff Page
- Published: 2026-06-26T09:09:24.794Z
- Updated: 2026-07-25T04:38:34.299Z
- Language: tr

## Giriş

Codex zaten kod yazabilir, bilinmeyen depoları açıklayabilir, hataları düzeltebilir ve geliştiricilerin daha hızlı ilerlemesine yardımcı olabilir. Ancak çoğu ekip için asıl darboğaz birkaç satır kod üretmek değildir.

Kodun etrafındaki her şeydir.

Bir özelliği uygulamadan önce planlamak. Başarısız bir CI çalıştırmasını anlamak. Pull request yorumlarına yanıt vermek. Bir kullanıcı akışını gerçek bir tarayıcıda test etmek. Bir veri kümesini temizlemek. Dokümantasyon yazmak. Bir projeyi dağıtıma hazırlamak. Bunlar her hafta sessizce saatler tüketen tekrarlayan iş akışlarıdır. İşte Ajan Becerileri burada faydalı hale gelir.

Ajan Becerileri, Codex'e belirli bir görev türünü ele almak için tekrarlanabilir bir yol sunar. Aynı gereksinimleri her komut isteminde yeniden açıklamak yerine, Codex'i yapılandırılmış talimatlar, destekleyici kaynaklar ve göreve özel iş akışlarıyla donatabilirsiniz. Sonuç sadece daha hızlı çıktı değil, aynı zamanda planlama, geliştirme, test, inceleme ve teslim süreçlerinde daha tutarlı bir çalışmadır.

Doğru becerilerle Codex, bir kodlama asistanından daha fazlası haline gelir. Ekibinizin özellikleri nasıl planladığını, kaliteyi nasıl kontrol ettiğini, verileri nasıl analiz ettiğini ve projeleri nasıl teslim ettiğini bilen odaklanmış bir ekip arkadaşı gibi çalışabilir.

Bu kılavuzda, 2026'da Codex için en iyi Ajan Becerilerine göz atacağız; ürün planlama, GitHub iş akışları, tarayıcı testi, veri analizi, güvenlik incelemeleri, tasarımdan koda dönüştürme, dağıtım ve dokümantasyon becerileri dahil. Amaç bulabildiğiniz her beceriyi yüklemek değil. İş akışınızdaki en çok tekrarlanan sürtüşmeyi ortadan kaldıranları belirlemektir.

## **Bir Bakışta: Codex için En İyi Ajan Becerileri**

İşte Codex için en iyi Ajan Becerilerine ve en kullanışlı oldukları iş akışlarına hızlı bir bakış.

### Hızlı Karşılaştırma: Codex için En İyi Ajan Becerileri

| Beceri | En İyi Olduğu Alan | Codex'in Ne Yapmasına Yardımcı Olur | İhtiyacınız Olanlar |

| --- | --- | --- | --- |

| Hedef Tanımla | Net başarı kriterleri | Belirsiz istekleri ölçülebilir hedeflere, kapsam sınırlarına ve doğrulama adımlarına dönüştürür | Net olmayan gereksinimleri veya birden fazla olası sonucu olan bir görev |

| gh-fix-ci | Başarısız CI kontrollerini düzeltme | GitHub Actions hatalarını inceler, günlükleri gözden geçirir ve odaklanmış bir onarım planı önerir | GitHub CLI erişimi ve GitHub Actions kullanan bir depo |

| gh-address-comments | PR inceleme geri bildirimi | İnceleme yorumlarını toplar, talep edilen değişiklikleri özetler ve seçilen geri bildirime yanıt verilmesine yardımcı olur | Açık bir GitHub pull request'i ve GitHub CLI erişimi |

| Playwright | Tarayıcı testi ve kullanıcı arayüzü hata ayıklama | Gerçek bir tarayıcı açar, kullanıcı akışlarını test eder, formları doldurur, düğmelere tıklar ve ekran görüntüleri yakalar | Bir web projesi ve çalışan bir Node.js ve npm ortamı |

| Güvenlik En İyi Uygulamaları | Varsayılan olarak güvenli kodlama | Yaygın güvenlik riskleri için kodu inceler ve daha güvenli uygulama desenleri önerir | Python, JavaScript/TypeScript veya Go gibi desteklenen bir kod tabanı |

| Figma Tasarımı Uygula | Figma'dan koda iş akışları | Figma düzenlerini, bileşenlerini ve tasarım jetonlarını ön uç uygulama kılavuzuna dönüştürür | Figma MCP erişimi ve bir Figma dosyası, çerçevesi veya seçili düğümü |

| Jupyter Notebook | Veri analizi ve deneyler | Araştırma, analiz, öğretici ve tekrarlanabilir iş akışları için not defterleri oluşturur ve yapılandırır | Bir veri kümesi, deney veya analiz iş akışı |

| CLI Oluşturucu | Yeniden kullanılabilir iç araçlar | Tekrarlayan görevler, API'ler ve dahili otomasyon için dayanıklı komut satırı araçları oluşturur | Paylaşılan bir araca dönüştürülmeye değer tekrarlayan bir iş akışı |

| Vercel Dağıt | Önizleme dağıtımlarını gönderme | Bir web projesini yayınlar ve test ve geri bildirim için paylaşılabilir bir önizleme URL'si oluşturur | Dağıtılabilir bir web projesi ve Vercel erişimi |

| OpenAI Belgeleri | OpenAI ürünleriyle geliştirme | API'ler, modeller, SDK'lar, geçişler ve Codex iş akışları için resmi OpenAI belgelerini kullanır | OpenAI ile ilgili bir geliştirme görevi |

### Kullanım Durumuna Göre Hızlı Seçimler

- **Gereksinimleriniz belirsizse buradan başlayın:**Hedef Belirle
- **GitHub iş akışları sizi yavaşlatıyorsa buradan başlayın:**gh-ci-düzelt veya gh-yorum-ele-al
- **Web ürünleri geliştiriyorsanız buradan başlayın:**Oyun Yazarı ve Vercel Dağıtım
- **Tasarımcılarla yakın çalışıyorsanız buradan başlayın:**Figma Tasarımını Uygula
- **Araştırma veya iş verilerini analiz ediyorsanız buradan başlayın:**Jupyter Not Defteri
- **Ekibiniz aynı manuel görevi tekrarlıyorsa buradan başlayın:**CLI Oluşturucu
- **OpenAI ile yapay zeka özellikleri geliştiriyorsanız buradan başlayın:**OpenAI Belgeleri
- **Daha güvenli geliştirme alışkanlıkları istiyorsanız buradan başlayın:**Güvenlik En İyi Uygulamaları

En iyi seçim, iş akışınızın en çok nerede yavaşladığına bağlıdır. Yeni bir ürün geliştiriyorsanız, planlama, test ve dağıtım becerileriyle başlayın. Her gün GitHub'da çalışıyorsanız, CI, pull request ve güvenlik iş akışlarına öncelik verin. Çalışmanız araştırma veya büyüme verilerini içeriyorsa, veri analizi ve dokümantasyon becerileri daha fazla değer sağlayabilir.

## **En İyi Codex Ajan Becerileri: Detaylı İncelemeler**

### **Değerlendirme Kriterlerimiz**

Bu Codex becerilerini beş pratik faktöre dayanarak değerlendirdik:

- **İş akışı etkisi:**Bu beceri, gerçek geliştirme çalışmasından anlamlı bir darboğazı ortadan kaldırıyor mu?
- **Kurulum sürtünmesi:**Ne kadar yapılandırma, kimlik doğrulama veya harici araç gerektiriyor?
- **Kontrol ve güvenlik:**Bu beceri, kod veya dağıtım değişiklikleri yapmadan önce kullanıcıları kontrol altında tutuyor mu?
- **Kapsam netliği:**Bu becerinin ne zaman kullanılması ve ne zaman kullanılmaması gerektiği açık mı?
- **Yeniden kullanılabilirlik:**Bu iş akışı, birden çok projede, depoda veya ekipte yardımcı olabilir mi?

Bunlar, her becerinin belgelenmiş iş akışına, ön koşullarına ve amaçlanan kullanım durumlarına dayanan editoryal değerlendirmelerdir. Bunlar kıyaslama puanları veya çıktı kalitesi garantisi değildir.

### **Hedef Belirle: Net Başarı Kriterleri İçin En İyisi**

![<img src="define goal" alt="the screenshot of define goal skill in GitHub">](https://file.nanoskill.ai/define-goal.png)

**Ne yapar:**  
Hedef Belirle, uygulama başlamadan önce geniş talepleri somut bir başarı tanımına dönüştürmeye yardımcı olur. “Kullanıcı katılım akışını iyileştir” gibi bir talebi basit bir kodlama görevi olarak ele almak yerine, kullanıcıyı ve ajanı neyin değişmesi gerektiğini, kapsam dışı olanı, sonucun nasıl test edileceğini ve çalışmanın tamamlandığını gösteren koşulları netleştirmeye teşvik eder.  
**Neden öne çıkıyor:**  
Şaşırtıcı derecede çok sayıda geliştirme görevi, hedefin hiçbir zaman net olarak tanımlanmaması nedeniyle başarısız olur. Kod çalışabilir, ancak yanlış sorunu çözebilir, önemli bir uç durumu kaçırabilir veya yeni bir revizyon turu yaratabilir. Hedef Belir, konuşmayı belirsiz eylemlerden ölçülebilir sonuçlara taşıyarak Codex’e daha güçlü bir başlangıç noktası verir.  
Özellikle bir görev birden çok paydaş, belirsiz ürün gereksinimleri, performans hedefleri, taşıma çalışmaları veya test edilebilir kabul kriterlerine dönüştürülmesi gereken hata raporları içerdiğinde kullanışlıdır. Kodlamaya başlamadan önce bitiş çizgisini tanımlayarak, ekipler gereksiz ileri-geri iletişimi azaltabilir ve Codex’e ilerideki çalışma için daha net koruma sınırları verebilir.  
**Örnek Görev:**

“Yeni kullanıcılar için katılım akışını iyileştirin. Ölçülebilir bir hedef tanımlayın, hedef kullanıcı eylemini netleştirin, kapsam içi ve kapsam dışı olanları belirleyin, kabul kriterleri önerin ve herhangi bir uygulama başlamadan önce nihai sonucun nasıl doğrulanması gerektiğini açıklayın.”  
**En iyisi:**  
Ürün ekipleri, geliştiriciler ve belirsiz özellik talepleri, hata düzeltmeleri, taşıma görevleri veya kaliteye duyarlı işleri yöneten teknik liderler

### **gh-ci-düzelt: Başarısız CI Kontrollerini Düzeltmek İçin En İyisi**

![<img src="gh-fix-ci skill" alt="the screenshot of gh-fix-ci skill in GitHub">](https://file.nanoskill.ai/gh-fix-ci-skill.png)

**Ne yapar:**  
gh-ci-düzelt, Codex'in bir çekme isteğindeki başarısız GitHub Actions kontrollerini araştırmasına yardımcı olur. İş akışı durumunu inceleyebilir, hata günlüklerini gözden geçirebilir, sorunun en olası nedenini belirleyebilir ve değişiklikler yapılmadan önce odaklanmış bir onarım planı önerebilir.  
**Neden öne çıkıyor:**  
CI hataları, modern yazılım geliştirmede en yaygın sürtünme kaynaklarından biridir. Bir geliştirici, bir yapının neden başarısız olduğunu anlamak için GitHub günlükleri, yerel test çıktısı, bağımlılık dosyaları, çekme isteği değişiklikleri ve iş akışı yapılandırması arasında geçiş yapmak zorunda kalabilir. gh-ci-düzelt, Codex'e bu bağlamı toplamak ve sorunu daraltmak için yapılandırılmış bir yol sunar.  
Bu beceri, tanıyı uygulamadan ayırması nedeniyle özellikle değerlidir. Codex, doğrudan kapsamlı değişiklikler yapmak yerine, önce neyin başarısız olduğunu, neden başarısız olmuş olabileceğini ve daha sonra neyin kontrol edilmesi gerektiğini açıklayabilir. Bu, iş akışını daha şeffaf hale getirir ve geliştiricilere kırmızı CI durumundan doğrulanmış bir düzeltmeye daha hızlı bir yol sunar.

**Örnek Görev:**

“Bu çekme isteğindeki başarısız GitHub Actions denetimlerini inceleyin. Olası kök nedeni özetleyin, etkilenen dosyaları veya iş akışı adımlarını belirleyin ve herhangi bir kod değişikliği yapmadan önce en küçük güvenli onarım planını önerin.”  
**En uygun olduğu durum:**  
Testler, derlemeler, linting, tip kontrolleri ve çekme isteği doğrulaması için GitHub Actions kullanan ekipler.

### **gh-address-comments: PR İnceleme Geri Bildirimi için En Uygun**

![<img src="gh-address-comments skill" alt="the screenshot of gh-address-comments skill in GitHub">](https://file.nanoskill.ai/gh-address-comments-skill.png)

**Ne yapar:**  
gh-address-comments, Codex'in çekme isteği inceleme geri bildirimlerini toplamasına ve düzenlemesine yardımcı olur. İnceleme başlıklarını tanımlayabilir, her yorumun ne gerektirdiğini özetleyebilir, ilgili istekleri gruplandırabilir ve kullanıcıların hangi yorumların kod değişikliklerine yol açması gerektiğine karar vermelerine yardımcı olabilir.  
**Neden öne çıkıyor:**  
Kod incelemesi nadiren tek bir yorum nedeniyle zordur. Geri bildirim birden fazla inceleyici, dosya, başlık ve takip tartışmalarına dağıldığında zaman alıcı hale gelir. Geliştiriciler genellikle yorumları manuel olarak yeniden okumak, hangilerinin eylem gerektirdiğine karar vermek, her talebin ardındaki amacı anlamak ve halihazırda ele alınanların kaydını tutmak zorundadır.  
Bu beceri, bu parçalanmış süreci daha yönetilebilir bir iş akışına dönüştürür. Codex, her inceleme yorumunu eşit derecede acil olarak ele almak yerine, geri bildirimi özetlemeye, eyleme geçirilebilir öğeleri ortaya çıkarmaya ve revizyon sürecini daha bilinçli hale getirmeye yardımcı olabilir. Özellikle büyük çekme istekleri, hızlı hareket eden ekipler ve geri bildirimlere dikkatle yanıt verirken bağlam değiştirmeyi azaltmak isteyen geliştiriciler için faydalıdır.

**Örnek görev:**

“Mevcut çekme isteğindeki tüm çözülmemiş yorumları inceleyin. İlgili geri bildirimleri gruplandırın, her inceleyicinin ne istediğini özetleyin, hangi yorumların kod değişikliği gerektirdiğini belirleyin ve dalı düzenlemeden önce ele almanız gereken öğeleri onaylamamı isteyin.”

**En uygun olduğu durum:**  
Sık çekme istekleri ve çok inceleyicili geri bildirim içeren işbirlikçi GitHub depolarında çalışan geliştiriciler.

### **Playwright: Tarayıcı Testi ve UI Hata Ayıklaması için En Uygun**

![<img src="playwright skill" alt="the screenshot of playwright skill in GitHub">](https://file.nanoskill.ai/playwright-skill)

**Ne yapar:**  
Playwright, Codex'e terminalden gerçek bir tarayıcıyla etkileşim kurma yeteneği verir. Sayfaları açabilir, kullanıcı akışlarında gezinebilir, formları doldurabilir, düğmelere tıklayabilir, sayfa durumunu inceleyebilir, ekran görüntüleri alabilir ve yalnızca koddan anlaşılması zor olan arayüz sorunlarının yeniden oluşturulmasına yardımcı olabilir.  
**Neden öne çıkıyor:**  
Bir özellik birim testlerini geçebilir ancak gerçek ürün deneyiminde başarısız olabilir. Bir form yanlış gönderilebilir, bir modal kapanmayabilir, bir düğme küçük ekranlarda gizlenebilir veya bir sayfa yalnızca belirli bir tıklama dizisinden sonra bozulabilir. Bunlar, birisi ürünle bir kullanıcı gibi etkileşim kurduğunda belirgin hale gelen türden sorunlardır.  
Playwright, Codex'in depo düzeyindeki akıl yürütmenin ötesine geçmesine ve gerçek bir tarayıcı ortamında görünür davranışı doğrulamasına yardımcı olur. Bu, UI gerilemelerinde hata ayıklamak, katılım akışlarını kontrol etmek, ödemeleri veya kayıt yollarını doğrulamak ve bir özelliğin yalnızca kodda değil, kullanıcının bakış açısından çalıştığını onaylamak için onu değerli kılar.

**Örnek görev:**

“Yerel uygulamayı çalıştırın ve kayıt akışını gerçek bir tarayıcıda test edin. Bir test hesabı oluşturun, gerekli alanları doldurun, onay ekranının göründüğünü doğrulayın ve herhangi bir adım başarısız olursa bir ekran görüntüsü ve izleme kaydı alın.”

**En uygun olduğu durum:**  
Ön yüz geliştiricileri, SaaS ekipleri, QA iş akışları ve tarayıcı tabanlı ürünler geliştiren herkes.

### **Güvenlik En İyi Uygulamaları: Varsayılan Olarak Güvenli Kodlama için En Uygun**

![<img src="security best practices" alt="the screenshot of security best practices in GitHub">](https://file.nanoskill.ai/security-best-practices)

**Ne yapar:**  
Güvenlik En İyi Uygulamaları, Codex'in kodu yaygın güvenlik riskleri açısından incelemesine ve daha güvenli uygulama desenleri önermesine yardımcı olur. Aracıya, girdi doğrulama, sır yönetimi, kimlik doğrulama, izinler, güvensiz varsayılanlar ve yaygın uygulama düzeyi güvenlik açıkları hakkında daha dikkatli düşünmesi için rehberlik edebilir.  
**Neden öne çıkıyor:**  
Güvenlik sorunları genellikle normal görünen geliştirme kararlarıyla başlar: eksik bir yetkilendirme kontrolü, açığa çıkmış bir ortam değişkeni, zayıf girdi doğrulaması, aşırı geniş bir izin kuralı veya kullanıcı verilerinin güvensiz şekilde işlenmesi. Bir ekip hızlı bir şekilde özellikleri yayınlamaya odaklandığında bu sorunlar kolayca gözden kaçabilir.  
Bu beceri, güvenlik düşüncesini geliştirme sürecine daha erken dahil etmeye yardımcı olur. Güvenliği son aşama bir kontrol listesi olarak ele almak yerine, Codex kod yazılırken veya incelenirken daha güvenli uygulama kalıpları kullanabilir. Özellikle her çekme isteğini inceleyen özel bir güvenlik mühendisi olmayan ancak varsayılan olarak güvenli geliştirme alışkanlıklarına ihtiyaç duyan küçük ekipler için yararlıdır.

**Örnek görev:**

“Bu uygulamadaki kimlik doğrulama ve kullanıcı profili güncelleme akışını yaygın güvenlik risklerine karşı inceleyin. Girdi doğrulamasını, yetkilendirmeyi, gizli anahtar işlemeyi, oturum yönetimini ve güvensiz varsayılanları kontrol edin. Kod seviyesinde örneklerle birlikte varsayılan olarak güvenli değişiklikler önerin.”

**En uygun olduğu durumlar:**  
Startup'lar, full-stack geliştiriciler, API oluşturucular ve müşteriye dönük uygulamalar üzerinde çalışan ekipler.

### **Figma Implement Design: Figma'dan Koda İş Akışları için En Uygun**

![<img src="figma implement design" alt="the screenshot of figma implement design in GitHub">](https://file.nanoskill.ai/figma-implement-design)

**Ne yapar:**  
Figma Implement Design, Codex'in Figma bileşenlerini, ekranlarını, düzenlerini, tasarım belirteçlerini ve görsel referanslarını üretime hazır ön yüz koduna dönüştürmesine yardımcı olur. Ajana yapılandırılmış tasarım bağlamı verir, böylece uygulama kararları kaba görsel yorumlamaya değil, gerçek tasarıma dayanır.  
**Neden öne çıkıyor:**  
Tasarım teslimi, ürün tasarımı ile ön yüz geliştirme arasındaki en büyük sürtüşme kaynaklarından biridir. Geliştiricilerin boşlukları, tipografiyi, duyarlı davranışı, ikonografiyi, bileşenleri, durumları ve mevcut tasarım sistemi kurallarını anlaması gerekir. Açık bir bağlam olmadan, uygulama amaçlanan tasarımdan uzaklaşabilir veya tutarsız kullanıcı arayüzü desenleri ortaya çıkarabilir.  
Bu beceri, teslimi daha sistematik hale getirir. Codex'i mümkün olduğunca mevcut bileşenleri ve tasarım belirteçlerini yeniden kullanmaya, görsel desenleri daha yakından takip etmeye ve son çıktıyı orijinal tasarıma göre doğrulamaya teşvik eder. Her gün Figma'da çalışan ekipler için bu, tasarım onayından daha cilalı, tutarlı bir uygulamaya giden yolu kısaltabilir.

**Örnek görev:**

“Seçilen Figma çerçevesini kullanarak bu gösterge paneli sayfasını mevcut ön yüz projesinde uygulayın. Mümkün olduğunca mevcut bileşen kütüphanesini ve tasarım belirteçlerini yeniden kullanın, düzen ve tipografiyi yakından eşleştirin, duyarlı davranışı destekleyin ve son sayfayı Figma tasarımıyla karşılaştırın.”

**En uygun olduğu durumlar:**  
Ürün ekipleri, ön yüz geliştiriciler ve Figma tabanlı tasarım sistemleriyle çalışan tasarımcılar.

### **Jupyter Notebook: Veri Analizi ve Deneyler için En Uygun**

![<img src="jupyter notebook" alt="the screenshot of jupyter notebook in GitHub">](https://file.nanoskill.ai/jupyter-notebook)

**Ne yapar:**  
Jupyter Notebook, Codex'in veri analizi, deneyler, eğitimler ve tekrarlanabilir araştırma iş akışları için not defterleri oluşturmasına, düzenlemesine, organize etmesine ve yeniden düzenlemesine yardımcı olur. Okunabilir markdown açıklamaları, mantıksal kod hücreleri ve daha bilinçli analiz adımları ile daha net bir defter yapısını destekleyebilir.  
**Neden öne çıkıyor:**  
Bir defter, sadece çalıştığı için yararlı değildir. Güçlü bir defter aynı zamanda başkaları tarafından anlaşılması, tekrarlanması ve genişletilmesi kolay olmalıdır. Uygulamada, birçok defter kod, notlar, geçici deneyler ve sonuçlar net bir yapı olmadan birbirine karıştığı için takip edilmesi zor hale gelir.  
Bu beceri, Codex'in tek kullanımlık karalama defterlerinden daha fazlası olan defterler oluşturmasına yardımcı olur. Daha temiz keşifsel analiz, daha anlaşılır deneyler ve öğretme veya paylaşma için daha iyi eğitim tarzı defterler destekleyebilir. Bu, araştırmacılar, analistler, büyüme ekipleri ve veri çalışmasını tek seferlik bir betik yerine yeniden kullanılabilir bir yapıya dönüştürmesi gereken herkes için değerlidir.

**Örnek görev:**

“Bu CSV veri kümesini analiz eden temiz bir Jupyter defteri oluşturun. Veri temizleme, tanımlayıcı istatistikler, görselleştirmeler, temel bulgular ve her adım için markdown açıklamaları ekleyin. Defteri, başka bir araştırmacının baştan sona çalıştırabileceği şekilde yapılandırın.”

**En uygun olduğu durumlar:**  
Araştırmacılar, analistler, eğitimciler, makine öğrenimi uygulayıcıları ve deneylerle veya yapılandırılmış veri kümeleriyle çalışan ekipler.

### **CLI Creator: Yeniden Kullanılabilir İç Araçlar İçin En İyisi**

![<img src="cli creator" alt="the screenshot of cli creator in GitHub">](https://file.nanoskill.ai/cli-creator)

**Ne işe yarar:**  
CLI Creator, Codex'in tekrar eden iş akışları için dayanıklı komut satırı araçları oluşturmasına yardımcı olur. Bu araçlar API etkileşimlerini, yerel otomasyonları, dahili operasyonları, veri alımını, yönetsel görevleri ve aksi takdirde manuel tarayıcı çalışması veya tek seferlik komut dosyaları gerektirecek tekrarlanabilir eylemleri destekleyebilir.  
**Neden öne çıkıyor:**  
Birçok ekip aynı görevleri tekrar tekrar gerçekleştirir: günlükleri kontrol etmek, veri dışa aktarmak, dosya yüklemek, dahili sistemleri sorgulamak, bilgileri senkronize etmek veya güvenli operasyonel eylemleri tetiklemek. Başlangıçta bu görevler genellikle geçici komut dosyaları veya belgelenmemiş bir dizi manuel adımla halledilir. Zamanla bu sürtüşme, tutarsızlık ve bireysel ekip üyelerine gereksiz bağımlılık yaratır.  
CLI Creator, tekrarlanan işi daha temiz bir dahili ürüne dönüştürmeye yardımcı olur. Her hafta aynı sorunu çözmek yerine ekipler, daha anlaşılır komutlar, öngörülebilir çıktı, daha güvenli kimlik doğrulama işleme ve başkalarının takip edebileceği dokümantasyon ile yeniden kullanılabilir bir komut satırı arayüzü oluşturabilir. Bu, Codex'i tek seferlik bir asistandan bir araç oluşturma ortağına dönüştürmek için en güçlü becerilerden biridir.

**Örnek görev:**

“E-posta adresine göre dahili API'mizden müşteri kayıtlarını getiren yeniden kullanılabilir bir CLI aracı oluşturun. Net komutlar, yardım metni, JSON çıktısı, ortam değişkenine dayalı kimlik doğrulama, hata yönetimi ve bir "`--kuru-çalıştırma`modu.”

**En iyi şunlar için:**  
Mühendislik ekipleri, platform ekipleri, operasyon ekipleri ve tekrar eden dahili iş akışlarına sahip geliştiriciler.

### **Vercel Deploy: Önizleme Dağıtımlarını Yayınlamak İçin En İyisi**

![<img src="vercel deploy skill" alt="vercel deploy skill">](https://file.nanoskill.ai/vercel-deploy-skill)

**Ne işe yarar:**  
Vercel Deploy, Codex'in bir web projesini Vercel'e yayınlamasına ve paylaşılabilir bir önizleme dağıtımı oluşturmasına yardımcı olur. Bu, kullanıcılara bir proje üretime geçmeden önce açılabilen, incelenebilen, test edilebilen ve paylaşılabilen canlı bir URL verir.  
**Neden öne çıkıyor:**  
Bir proje, insanlar onunla bir tarayıcıda etkileşime girebildiği an değerlendirilmesi daha kolay hale gelir. Yerel geliştirme oluşturma için yararlıdır, ancak önizleme dağıtımları, ekip arkadaşlarının, müşterilerin, tasarımcıların, paydaşların ve erken kullanıcıların sonucu bağlam içinde görmesini sağlayan şeydir.  
Bu beceri, "kod benim makinemde çalışıyor" ile "başkası test edebilir" arasındaki mesafeyi kısaltır. Bu, onu portfolyolar, açılış sayfaları, prototipler, dahili gösterge panoları, MVP'ler ve erken SaaS deneyleri için özellikle yararlı kılar. Ayrıca, ekiplerin geri bildirim toplayabileceği ve tam bir üretim lansmanına geçmeden önce sorunları yakalayabileceği önizleme dağıtımlarına odaklanarak daha güvenli bir yayınlama ritmini destekler.

**Örnek görev:**

“Mevcut web projesini bir önizleme dağıtımı olarak Vercel'e dağıtın. Derlemenin başarılı olduğunu doğrulayın, önizleme URL'sini döndürün ve bir üretim dağıtımı oluşturmayın veya değiştirmeyin.”

**En iyi şunlar için:**  
Bağımsız geliştiriciler, öğrenciler, startup ekipleri, ürün geliştiricileri ve hızlı paylaşılabilir önizleme bağlantılarına ihtiyaç duyan herkes.

### **OpenAI Docs: OpenAI Ürünleriyle Geliştirme İçin En İyisi**

![<img src="openai docs" alt="openai docs">](https://file.nanoskill.ai/openai-docs)

**Ne işe yarar:**  
OpenAI Docs, Codex'in OpenAI API'leri, modelleri, SDK'ları, geçişleri, Ajanları ve Codex ile ilgili iş akışlarıyla çalışırken resmi OpenAI dokümantasyonunu kullanmasına yardımcı olur. Güncel olmayan öğreticiler veya resmi olmayan örnekler yerine güncel birinci taraf dokümantasyonuna dayanan uygulama kararlarını teşvik eder.  
**Neden öne çıkıyor:**  
Yapay zeka geliştirme hızla değişir. Model yetenekleri, API parametreleri, SDK desenleri, geçiş kılavuzları ve ürün önerileri, birçok üçüncü taraf öğreticinin güncellenmesinden daha hızlı evrimleşebilir. Bu, bilgilerin hala güncel olup olmadığını kontrol etmeden eski blog yazılarından veya topluluk parçacıklarından örnekler kopyalayan geliştiriciler için gerçek bir risk oluşturur.  
Bu beceri, Codex'e OpenAI ürünleriyle çalışırken daha güvenilir bir doğruluk kaynağı sağlar. Özellikle doğru API modelini seçme, desteklenen özellikleri anlama, geçiş değişikliklerini yönetme veya Codex ve aracı iş akışları için en son rehberliği takip etme gibi güncel belgelere bağlı uygulama sorularında faydalıdır.

**Örnek görev:**

"Yalnızca resmi OpenAI belgelerini kullanarak, bu uygulamaya belge tabanlı Soru-Cevap eklemek için en iyi güncel uygulama yaklaşımını önerin. İlgili API seçeneklerini karşılaştırın, gerekli kurulum adımlarını listeleyin, ana parametreleri açıklayın ve minimal bir TypeScript örneği sağlayın."

**En uygun olduğu durumlar:**  
OpenAI API'leri, OpenAI modelleri, Aracılar, Codex veya AI destekli ürün özellikleriyle geliştirme yapan geliştiriciler.

## **Örnek Codex Beceri İş Akışları**

Aracı Becerileri, gerçek bir görevi nasıl değiştirdiklerini gördüğünüzde değerlendirmek daha kolaydır. Yalnızca özellikleri listelemek yerine, aşağıdaki örnek, Codex'in belirsiz bir ürün talebi aldığında ve yapılandırılmış bir beceri kullanarak onu daha net, daha doğrulanabilir bir sonuca dönüştürdüğünde ne olduğunu gösterir.

### **İş Akışı 1: "Katılımı İyileştir"i Ölçülebilir Bir Ürün Hedefine Dönüştürmek**

**Senaryo:**

Bir SaaS ekibi, birçok yeni kullanıcının bir hesap oluşturduğunu ancak çalışma alanı kurulumunu tamamlamadan ayrıldığını fark eder. İlk talep basittir: "Katılım akışını iyileştirin." Ancak talep, bir hedef metrik, son tarih, kapsam veya çalışmanın başarılı olduğunu kanıtlamanın net bir yolunu tanımlamaz.

**Kullanılan beceri:**

Hedef Tanımla

**Kullanılan komut:**

"Yeni kullanıcılar için katılım akışını iyileştirin. Ölçülebilir bir hedef tanımlayın, hedef kullanıcı eylemini netleştirin, kapsam dahilinde ve kapsam dışında olanları belirleyin, kabul kriterleri önerin ve herhangi bir uygulama başlamadan önce nihai sonucun nasıl doğrulanması gerektiğini açıklayın."

Hemen UI değişiklikleri önermek veya kod yazmak yerine, Codex önce talebi bir ürün hedefine dönüştürdü. 30 günlük bir hedef tanımladı, temel metrikleri belirledi, ölçülebilir başarı kriterleri koydu ve çalışmanın katılım deneyimini gerçekten iyileştirip iyileştirmediğini doğrulamak için gereken kanıtları belirledi.

![<img src="define goal sample1" alt="the screenshot of define goal outcome ">](https://file.nanoskill.ai/define-goal-sample1)

Orijinal talep, ölçülebilir bir başarı tanımı içermiyordu. Hedef Tanımla'yı uyguladıktan sonra Codex, bunu belirli bir sonuca dönüştürdü: katılım tamamlanma oranını %42'den en az %55'e çıkarmak, ortalama tamamlanma süresini ise 6 dakika 30 saniyeden 5 dakika veya daha azına düşürmek.

Bu, becerinin temel değeridir. Görevi "bir şeyi daha iyi hale getir"den, yayınlandıktan sonra test edilebilir, ölçülebilir ve gözden geçirilebilir bir hedefe taşır.

Codex ayrıca, gevşek tanımlanmış taleplerde genellikle eksik olan dört unsur ekledi:

- **Net başarı kriterleri:**çalışmanın başarılı sayılabilmesi için ekibin neyi başarması gerektiği.
- **Tanımlanmış kapsam:**katılım deneyiminin hangi kısmının önce iyileştirilmesi gerektiği.
- **Doğrulama kanıtı:**sonucu doğrulamak için gerekli yayın sonrası analitikler.
- **Dur ve sor koşulları:**Codex'in varsayım yapmak yerine açıklama talep etmesi gereken durumlar.

![<img src="define goal sample2" alt="the screenshot of define goal outcome ">](https://file.nanoskill.ai/define-goal-sample2)

Bu iş akışının önemli bir parçası, Codex'in hedefi tamamlanmış olarak işaretlememesidir. Hedefin, iki şey gerçekleşene kadar engelli kaldığını doğru bir şekilde belirledi: revize edilmiş katılım akışının yayınlanması ve yayın sonrası analitiklerin aynı temel olay tanımlarını kullanarak hedef metrikleri doğrulaması.

Bu ayrım önemlidir. Beceri, hedefi tanımlayabilir, doğrulama planını hazırlayabilir ve destekleyici yapıtlar oluşturabilir, ancak gerçek dünya kanıtı olmadan başarı iddia etmemelidir.

**Bu iş akışı neden önemlidir:**

Hedef Tanımla, bir görev belirsiz bir taleple, birden fazla paydaşla veya net olmayan başarı kriterleriyle başladığında en kullanışlıdır. Codex'e daha disiplinli bir başlangıç noktası sağlar ve uygulama başlamadan önce ekiplerin "tamamlanmış"ın gerçekte ne anlama geldiği konusunda anlaşmasına yardımcı olur.

### **İş Akışı 2: Başarısız Bir CI Kontrolünden Odaklanmış Bir Onarım Planına**

**Senaryo:**

Bir çekme isteği, küçük bir kod değişikliğinden sonra otomatik test kontrolünde başarısız oluyor. Geliştirici CI durumunun kırmızı olduğunu görebilir, ancak gerçekte neyin başarısız olduğunu, sorunun koddan mı yoksa testten mi kaynaklandığını ve yapılması gereken en küçük güvenli düzeltmenin ne olduğunu belirlemesi gerekir.

Bu örnekte, başarısız test add(2, 2) işlevinin 5 döndürmesini beklerken, gerçek sonuç`4`. Önemli soru, kontrolün geçmesini sağlamak değildir. Uygulamanın mı yanlış olduğu, test beklentisinin mi yanlış olduğu, yoksa hatanın daha geniş bir soruna mı işaret ettiğidir.

**Kullanılan Beceri:**

gh-fix-ci

**Örnek istem:**

“Mevcut daldaki çekme isteği için başarısız GitHub Actions kontrollerini inceleyin. Hata bağlamını özetleyin, olası temel nedeni belirleyin ve en küçük güvenli onarım planını önerin. Planı açıkça onaylayana kadar kodu düzenlemeyin veya iş akışlarını yeniden çalıştırmayın.”

Kodu hemen değiştirmek yerine, gh-fix-ci görevi kontrollü bir tanılama iş akışı olarak yapılandırır. Codex önce başarısız kontrolü ve mevcut bağlamını inceler, hatanın olası nedenini belirler ve minimal bir onarım planı önerir. Codex yalnızca kullanıcı planı onayladıktan sonra değişikliği yapmalı, ilgili testi çalıştırmalı ve çekme isteği kontrolünün yeşil döndüğünü doğrulamalıdır.

![<img src="gh fix ci sample" alt="the screenshot of gh fix ci sample ">](https://file.nanoskill.ai/gh-fix-ci-sample)

_Şekil 3. gh-fix-ci Becerisi'ne dayalı açıklayıcı iş akışı: Codex, başarısız bir GitHub Actions kontrolünden odaklanmış, incelenebilir bir onarım planına geçer._

Bu örnekte, hata sinyali açıktır. Codex, hatalı bir uygulama ile hatalı bir test arasında ayrım yapmak için bu hata bağlamını kullanır. Burada, 4 döndüren add işlevi doğrudur. Temel neden, sonucun yanlışlıkla 5 olmasını bekleyen test beklentisidir.

Ortaya çıkan onarım planı bilinçli olarak minimaldir:

1. Testteki beklenen değeri 5'ten 4'e değiştirin.
2. İlgili testi yerel olarak çalıştırın.
3. Onaylanan değişikliği gönderin ve çekme isteği durumunu yeniden kontrol edin.

En önemli adım**onay kapısı**. gh-fix-ci, her başarısız kontrolü otomatik olarak kodu düzenleme izni olarak görecek şekilde tasarlanmamıştır. Tanılamayı uygulamadan ayırır: Codex olası sorunu açıklar, odaklanmış bir onarım planı sunar ve dalı değiştirmeden önce açık kullanıcı onayını bekler.

Onaydan sonra, beklenen son durum basittir: düzeltilmiş test yerel olarak geçer ve çekme isteği kontrolü yeşil döner.

Bu iş akışı, CI onarımını daha şeffaf ve daha az tepkisel hale getirdiği için faydalıdır. Codex'ten “hatayı düzeltmesini” isteyip en iyisini ummak yerine, geliştiriciler hata analizini inceleyebilir, önerilen değişiklik kapsamını onaylayabilir ve sorunun nasıl çözüldüğüne dair net bir kayıt tutabilir.

**Bu iş akışı neden önemlidir:**

gh-fix-ci, çekme isteği iş akışlarının bir parçası olarak GitHub Actions kullanan ekipler için en değerli olandır. Codex'in başarısız bir kontrolü, CI durumunu geçirmeye yönelik kara kutu bir girişim yerine, tanılama, onay, uygulama ve doğrulamadan oluşan yapılandırılmış bir diziye dönüştürmesine yardımcı olur.

### **İş Akışı 3: Tarayıcıda Bozuk Bir Kayıt Akışını Test Etme ve Doğrulama**

**Senaryo:**

Bir kayıt sayfası, kod incelemesinde doğru görünebilir ancak en önemli anda: gerçek bir kullanıcı akışı tamamlamaya çalıştığında başarısız olabilir. Bir form girdi kabul edebilir, bir düğme tıklanabilir görünebilir ve ön uç belirgin bir hata göstermeyebilir—yine de beklenen onay durumu gönderimden sonra hiç görünmeyebilir.

Bu açıklayıcı senaryoda, bir kullanıcı bir çalışma alanı kayıt sayfasını açar, tam adını, iş e-postasını ve çalışma alanı adını girer, ardından şuna tıklar:**Çalışma alanı oluştur**. Beklenen sonuç görünür bir onay mesajıdır:**“Çalışma alanı oluşturuldu.”**Bunun yerine, akış gönderiyor gibi görünür ancak herhangi bir onay durumu oluşturmaz.

**Kullanılan İş Akışı:**

Playwright destekli tarayıcı testi

**Örnek istem:**

“Tarayıcıda çalışma alanı kayıt akışını açın, formu geçerli bilgilerle doldurun, Çalışma alanı oluştur'a tıklayın ve görünür bir onay mesajının göründüğünü doğrulayın. Akış başarısız olursa, ilgili tarayıcı kanıtlarını yakalayın, olası nedeni belirleyin ve kodu düzenlemeden önce en küçük güvenli düzeltmeyi önerin.”

Yalnızca kod incelemesinden farklı olarak, tarayıcı testi kullanıcının gerçekte ne deneyimlediğini kontrol eder. İş akışı, sayfa yüklemeden form gönderimine kadar olan yolu yeniden oluşturarak başlar, ardından görünür sonucu beklenen kullanıcı odaklı sonuçla karşılaştırır.

![<img src="playwright sample1" alt="the screenshot of playwright sample ">](https://file.nanoskill.ai/playwright-sample)

_Şekil 4. Örnek Playwright destekli iş akışı: Codex, bozuk bir kayıt akışından tarayıcı kanıtına, onaya ve doğrulanmış bir kullanıcı akışı sonucuna geçer._

İlk başarısızlık belirsiz bir “bir şeyler ters gitti” mesajı değildir. Tarayıcı testinin net, kullanıcıya yönelik bir beklentisi vardır: kullanıcı geçerli kayıt bilgilerini gönderdikten sonra sayfa onay mesajını göstermelidir**“Çalışma alanı oluşturuldu.”**  
Bunun yerine, gözlemlenen sonuç, gönderimden sonra hiçbir onay durumunun görünmediğidir. Bu, Codex'e “kayıt sayfasını düzelt” gibi genel bir talimat yerine araştırması için belirli bir başarısızlık koşulu sunar.

Bu ayrım önemlidir. Sorun mutlaka form alanlarının bozuk olması veya kullanıcının verilerinin geçersiz olması değildir. Bunun yerine, iş akışı, uygulamanın geçerli girdiyi kabul ettiğini ancak gönderimden sonra bir başarı durumu oluşturamadığını öne sürer.

Buradan itibaren Codex, araştırmayı kontrollü bir dizi halinde yapılandırabilir: tarayıcı durumunu incele, başarısızlık kanıtlarını gözden geçir, olası eksik kullanıcı arayüzü davranışını belirle ve minimal bir onarım planı öner. Bu durumda, önerilen düzeltme kasıtlı olarak dardır: geçerli form gönderiminden sonra görünür bir**“Çalışma alanı oluşturuldu”**onay durumu oluştur, mevcut sayfa düzenini ve doğrulama davranışını değiştirmeden bırak.

![<img src="playwright sample2" alt="the screenshot of playwright sample ">](https://file.nanoskill.ai/playwright-sample2)

_Şekil 5. Altı adımlı tarayıcı testi iş akışı: akışı aç, sorunu yeniden oluştur, tarayıcı kanıtlarını incele, bir düzeltme öner, onay al ve beklenen son durumu doğrula._

Kritik adım onay kapısıdır. Tarayıcı testi otomatik olarak kontrolsüz kod düzenlemeye dönüşmemelidir. Codex başarısızlığı belirleyebilir ve en küçük değişikliği önerebilir, ancak uygulamayı değiştirmeden önce kullanıcı onayını beklemelidir.

Onaylanan düzeltme uygulandıktan sonra beklenen son durum açıktır: kayıt akışı onay mesajını gösterir ve tarayıcı testi geçerli bir sonuç döndürür. Bu, neyin başarısız olduğuna dair kanıt veya kullanıcı akışının şimdi çalıştığına dair onay olmadan bir aracıya “kayıt sayfasını düzelt” demekten daha güvenilir bir geliştirme döngüsü oluşturur.

Bu örnek, Playwright tarzı tarayıcı testine dayalı açıklayıcı bir iş akışıdır. Bir üretim uygulamasını veya tamamlanmış canlı bir test çalışmasını temsil etmez.

**Bu iş akışı neden önemlidir:**

Playwright destekli iş akışları, özellikle ön yüz ekipleri, SaaS ürünleri ve görünür kullanıcı deneyiminin kodun kendisi kadar önemli olduğu herhangi bir proje için değerlidir. Yalnızca statik kod incelemesine güvenmek yerine, tıklamalar, form gönderimleri, gezinme ve onay durumları gibi gerçek etkileşimleri doğrulamaya yardımcı olurlar. Sonuç, uygulama kararlarını kullanıcıların tarayıcıda gerçekten gördükleri ve yaptıklarıyla bağlayan bir iş akışıdır.

## **Codex Becerileri Hakkında SSS**

### **Codex Becerileri nedir?**

Codex Becerileri, Codex'in belirli bir görev türünü daha tutarlı bir şekilde ele almasına yardımcı olan yeniden kullanılabilir iş akışlarıdır. Bir beceri, Codex'i tekrarlanabilir bir süreç boyunca yönlendiren talimatlar, isteğe bağlı komut dosyaları, referans materyalleri ve varlıkları içerebilir.

Örneğin, bir beceri Codex'in başarısız CI kontrollerini araştırmasına yardımcı olabilirken, bir diğeri belirsiz bir ürün talebini ölçülebilir bir hedefe dönüştürmesine yardımcı olabilir. Her yeni konuşmada aynı uzun istemi tekrarlamak yerine, iş akışını, tercih edilen çıktı biçimini ve önemli kuralları korumak için bir beceri kullanabilirsiniz.

### **Bir Codex Becerisini nasıl yüklerim?**

Seçilmiş beceriler için Codex'i açın ve yerleşik yükleyiciyi kullanın.

Örneğin, şunu yazabilirsiniz:

**$skill-installer gh-fix-ci**

Codex daha sonra seçilen beceriyi yerel kurulumunuza yükleyebilir. Beceri kurulumdan hemen sonra görünmezse, Codex'i yeniden başlatın ve tekrar çağırmayı deneyin.

Ayrıca yükleyiciden ilgili becerileri keşfetmenize yardımcı olmasını isteyebilirsiniz. Örneğin:

**$skill-installer**

**Tarayıcı testi ve GitHub iş akışları için beceriler öner.**

Kurulduktan sonra, bir beceriyi, adını dolar işareti ile yazarak açıkça çağırabilirsiniz, örneğin**$gh-düzelt-ci**veya**$tanımla-hedef**.

### **Kendi Codex Becerimi oluşturabilir miyim?**

Evet. Aslında, özel beceriler genellikle büyük bir jenerik beceri koleksiyonundan daha değerlidir.

Kullanışlı bir özel beceri genellikle zaten tekrarladığınız bir iş akışıyla başlar. Bir yayın kontrol listesi, bir kod inceleme formatı, bir tarayıcı QA rutini, bir dokümantasyon süreci veya bir dahili raporlama görevi olabilir.

Codex, kullanışlı bir konu akışını, belgeyi, betiği, kontrol listesini veya örnek çıktıyı yeniden kullanılabilir bir beceriye dönüştürmeye yardımcı olabilecek bir Beceri Oluşturucu iş akışı içerir. Özel bir beceri genellikle gerekli bir`BECERİ.md`dosyası ile başlar ve isteğe bağlı referanslar, betikler veya şablonlar içerebilir.

Bir beceri oluşturmanın en iyi zamanı, bir görevi bir kez tamamladıktan ve iyi bir sonucun tam olarak nasıl olması gerektiğini bildikten sonradır.

### **Codex Becerisi ile AJANLAR.md arasındaki fark nedir?**

Bir`AJANLAR.md`dosyası kalıcı proje yönergeleri içerir. Codex'e belirli bir depoda veya klasörde çalıştığında nasıl davranması gerektiğini söyler.

Örneğin, bir`AJANLAR.md`dosyası şöyle diyebilir:

- Bir çekme isteği açmadan önce test paketini çalıştırın.
- Onay olmadan yeni bağımlılıklar eklemeyin.
- Mevcut bileşen kütüphanesini takip edin.
- Genel API değişikliklerini belgeleyin.

Beceri farklıdır. Belirli bir görev türü için yeniden kullanılabilir bir iş akışıdır.

Örneğin:

- GitHub Actions denetimi başarısız olduğunda gh-düzelt-ci kullanın.
- Bir kayıt akışını doğrularken bir tarayıcı test becerisi kullanın.
- Yayın notları hazırlarken bir dokümantasyon becerisi kullanın.

Farkı hatırlamanın basit bir yolu:

### **AJANLAR.md sürekli kuralları tanımlar. Beceriler tekrarlanabilir işleri tanımlar.**

### **Başlangıç seviyesindekiler ilk olarak hangi Codex Becerisini denemeli?**

Mevcut iş akışınızda en sık tekrarlanan sorunu çözen beceri ile başlayın.

Görevleriniz genellikle belirsiz gereksinimlerle başlıyorsa,**Hedef Tanımla**ile başlayın. Geniş talepleri ölçülebilir sonuçlara, kapsam sınırlarına ve doğrulama kriterlerine dönüştürmeye yardımcı olur.

GitHub çekme isteklerinde çok zaman harcıyorsanız,**gh-düzelt-ci**veya**gh-yorumları-ele-al**deneyin.

Web ürünleri geliştiriyorsanız,**Oyun Yazarı**gibi tarayıcı test iş akışları, kullanıcıların gerçekte ne gördüğünü ve yaptığını doğrulamaya yardımcı oldukları için kullanışlıdır.

AçıkAI API'leri veya modelleri ile çalışıyorsanız,**AçıkAI Belgeleri**Codex'in güncel birinci taraf belgelere güvenmesine yardımcı olabilir, eski örneklere değil.

En iyi ilk beceri genellikle en gelişmiş olan değildir. İşinizden tekrarlanan bir sürtüşme kaynağını ortadan kaldırandır.

### **Codex Becerilerini yüklemek güvenli mi?**

Beceriler, diğer yeniden kullanılabilir otomasyon veya geliştirici araçları gibi ele alınmalıdır: bunları güvenilir kaynaklardan yükleyin, ne yapmak üzere tasarlandıklarını inceleyin ve hangi erişime ihtiyaç duyduklarını anlayın.

Bir beceriyi gerçek bir projede kullanmadan önce, şunları yapıp yapamayacağını kontrol edin:

- Yerel ortamınızda komutlar çalıştırın
- Harici araçlara veya bağlı hizmetlere erişin
- Dosyaları değiştirin
- Commit'ler veya çekme istekleri oluşturun
- Dağıtımları tetikleyin
- Proje belgelerini veya gizli anahtarlarla ilgili yapılandırmayı okuyun

Düşük riskli denemeler için ayrı bir demo klasöründe veya test deposunda başlayın. Bir beceri anlamlı bir değişiklik önerdiğinde, dosya düzenlemelerini, kod değişikliklerini, commit'leri veya dağıtımları onaylamadan önce planı gözden geçirin.
