Ekranı Göster, İşi Öğret: Claude Cowork “Record a Skill” ile Örtük Bilgiyi Tekrarlanabilir Sürece Dönüştürmek

Bir işi her hafta aynı biçimde yaptığınızı düşünün: içerik yönetim sistemine giriyor, yeni içerik kaydı açıyor, başlığı ve kısa açıklamayı yerleştiriyor, slug alanını kontrol ediyor, etiketleri seçiyor, yazıyı önizliyor ve taslak olarak kaydediyorsunuz. Bu süreci bir çalışma arkadaşınıza öğretmek için uzun bir kılavuz yazabilirsiniz. Fakat çoğumuz gerçekte başka bir yol seçeriz: Ekranı açar, “Bak, önce buraya giriyorum; bu alanı şimdilik boş bırakıyorum; kaydetmeden önce de mutlaka önizlemeyi kontrol ediyorum” diyerek işi gösteririz.

Claude’un 21 Temmuz 2026 tarihli resmî duyurusuna göre Cowork içindeki “Record a skill” özelliği, kullanıcı görevini yaparken ekranını kaydetmesine ve adımları sözlü olarak anlatmasına imkân veriyor. Claude bu gösterimi daha sonra yeniden çalıştırabileceği bir skill’e dönüştürüyor. Duyuruda özelliğin Claude masaüstü uygulamasındaki “+” menüsünde bulunduğu ve o tarih itibarıyla Pro, Max ve Team planlarında sunulduğu belirtiliyor. Buradaki skill, belirli bir işi yürütmek için yeniden kullanılabilen talimat ve kaynak bütününü ifade ediyor.

Belgelenmiş ürün davranışı bu kadar: Ekranı kaydetmek, görevi sözlü olarak anlatmak ve gösterimi yeniden kullanılabilir bir skill’e dönüştürmek. Bunun “göstererek programlama”, “örtük bilgi aktarımı” veya “süreç madenciliği” ile ilişkisi ise ürün duyurusunun iddiası değil; özelliğin nasıl değerlendirilebileceğini anlamak için kullanacağımız analitik çerçevedir.

İlk bakışta bu, yalnızca kullanım kolaylığı sağlayan bir ürün özelliği gibi görünebilir. Oysa yaklaşım daha geniş bir imkân açıyor: Bilgisayara ne yapacağını yalnızca metinle tarif etmek yerine, işi yaparken oluşan davranışı öğretim malzemesine dönüştürebiliyoruz. Fakat gösterilen bir işi kaydetmekle güvenilir bir otomasyon kurmak aynı şey değildir. Kayıt tek bir başarılı örneği yakalar. Gerçek iş ise istisnalar, değişen ekranlar, belirsiz kararlar, hassas veriler ve geri alınması zor eylemler içerir.

Bu nedenle asıl soru “Bir skill ne kadar kolay kaydediliyor?” değil, “Kaydedilen davranış hangi koşullarda güvenle tekrar edilebilir?” olmalıdır.

“Record a skill” neyi değiştiriyor?

Geleneksel otomasyonda önce süreci soyutlamak gerekir. Bir geliştirici hangi verinin nereden alınacağını, hangi alanın nasıl doldurulacağını ve hata durumunda ne yapılacağını kodla ifade eder. Metin tabanlı yapay zekâ kullanımında ise kullanıcı aynı yapıyı doğal dille anlatır: “Yeni bir içerik oluştur, başlığı ekle, durumu taslak yap ve kaydet.”

Ekran kaydıyla öğretme yaklaşımı bu iki yöntemin arasına yerleşir. Kullanıcı, görevi doğal çalışma ortamında gerçekleştirirken ekranda yaptığı işi kaydeder ve açıklamalarını seslendirir. Görüntü, eylemin nasıl yapıldığını; sözlü anlatım ise çoğu zaman neden öyle yapıldığını aktarmaya yardımcı olabilir.

Burada önemli bir sınır var: Resmî duyuru, kaydedilen ekran ve anlatımın skill’e dönüştürüldüğünü söylüyor; sistemin her tıklamayı ayrı bir olay olarak nasıl çıkardığını, konuşmadan hangi karar kurallarını hangi yöntemle türettiğini veya tek gösterimden ne ölçüde güvenilir genelleme yaptığını açıklamıyor. Bu nedenle aşağıdaki tasarım önerilerini doğrulanmış iç işleyiş bilgisi olarak değil, güvenli bir öğretim kaydı hazırlamak için insan tarafında uygulanabilecek yöntemler olarak okumak gerekir.

Yalnız ekran kaydında şu dizi görülebilir:

1. İçerik yönetim sistemindeki yazı koleksiyonunu aç.
2. Yeni kayıt oluştur.
3. Başlık, slug, açıklama ve içerik alanlarını doldur.
4. Durumu “draft” olarak bırak.
5. Kaydet.

Sözlü anlatım ise görünmeyen kuralları açık hale getirebilir: “Slug alanında Türkçe karakter kullanmıyorum. Başlık değişirse slug’ı yeniden kontrol ediyorum. Kaynakları doğrulamadan içeriği yayımlamıyorum. Bu süreç yalnızca taslak oluşturabilir; yayınlama kararını editör verir.”

İkinci katman olmadan kayıt, yalnız görünen hareketleri taşır. Sözlü açıklama eklendiğinde iş akışının niyetini, sınırlarını ve başarı ölçütlerini ifade etmek mümkün hale gelir. Bu, sistemin her kuralı kusursuz çıkaracağını garanti etmez; fakat gösterimin öğretici niteliğini güçlendirir.

Ekran kaydı eylemin izini, sözlü anlatım ise kararın gerekçesini taşıyabilir. Güvenilir bir skill için ikisini de açık ve denetlenebilir hale getirmek gerekir.

Bu yaklaşım neden “göstererek programlama” olarak düşünülebilir?

Göstererek programlama, kullanıcının bir prosedürü geleneksel kod yazmadan örnek davranış üzerinden tanımlaması fikridir. “Record a skill” için bu terim resmî ürün tanımı değildir; özelliği daha eski bir bilgisayar bilimi yaklaşımıyla ilişkilendiren yorumdur.

Kullanıcı sistemi adım adım programladığını düşünmeyebilir. Yine de yaptığı seçimlerle bir prosedürün üç temel parçasını görünür kılar:

• Girdi: İşlenecek kayıt, belge veya kullanıcı isteği.
• Dönüşüm: İzlenecek adımlar ve kararlar.
• Çıktı: Oluşturulacak ya da güncellenecek sonuç.

İçerik yönetim sistemi örneğinde girdi, tamamlanmış bir yazı paketidir. Dönüşüm; doğru koleksiyonu açmak, alanları eşlemek, slug’ı denetlemek ve durumu taslak olarak seçmektir. Çıktı ise eksiksiz, fakat henüz yayımlanmamış tek bir içerik kaydıdır.

Buradaki kolaylık yanıltıcı olabilir. Kullanıcı kod yazmasa da bir yürütme politikası tarif etmektedir. “Kaydet” düğmesine basması bir eylem, “Yayınla düğmesine hiçbir zaman basma” demesi bir yetki kuralı, “Aynı slug varsa dur” demesi ise bir hata koşuludur. Dolayısıyla iyi bir kayıt yapmak, yalnızca işi tamamlamak değil, davranışın mantığını görünür kılmaktır.

Gösterirken düşünceyi dışarı çıkarmak

Bir skill kaydı hazırlanırken sessizce hızlı çalışmak yerine kararları seslendirmek daha değerlidir. Aşağıdaki anlatım, bir içerik yönetim sisteminde taslak oluşturma senaryosu için doldurulmuş bir örnektir:

“İçerikler koleksiyonunda yeni kayıt açıyorum. Başlığı verilen paketle aynı giriyorum. Slug’ı küçük harfli ve tireli biçimde kontrol ediyorum; mevcut bir kayıtla çakışıyorsa kaydetmeden duruyorum. Açıklama alanına okur kazanımını anlatan kısa özeti ekliyorum. HTML içeriğinde h1 bulunmadığını kontrol ediyorum çünkü başlık arayüzde ayrıca gösteriliyor. Etiket olarak ‘Yapay Zekâ’yı seçiyorum. Durumu ‘draft’ bırakıyorum. Kaydetmeden önce başlık, slug ve durum alanlarını son kez karşılaştırıyorum. Yayınlama işlemi bu skill’in yetkisi dışında.”

Bu anlatım yalnız yol tarif etmiyor. Çakışma, biçim, doğrulama ve yetki sınırı gibi gelecekte kararı değiştirecek bilgileri de açıkça kayda dahil ediyor.

Asıl değer: Örtük bilgiyi görünür hale getirmek

İşlerin önemli bir bölümü yazılı prosedürlerde bulunmaz. Deneyimli bir editör, açıklamanın başlığı tekrar ettiğini bir bakışta fark eder. Slug’ın gereksiz uzadığını görür. Bir kaynak iddiasının yeterince sağlam olmadığını değerlendirip kaydı yayımlamak yerine taslakta bırakır. Bu bilgiye örtük bilgi diyebiliriz: Kişinin uygulayabildiği, fakat çoğu zaman eksiksiz biçimde yazıya dökmediği bilgi.

Ekran kaydı örtük bilgiyi kendiliğinden tamamen çıkarmaz. Editör bir alanı düzeltir ama neden düzelttiğini söylemezse kayıtta yalnızca değişiklik görünür. Gelecekte benzer görünen fakat farklı karar gerektiren bir durumda aynı davranış yanlış olabilir. Sözlü anlatımın önemi burada ortaya çıkar: Uzmanın zihnindeki karar kuralını eylemle eşleştirmek için bir fırsat sağlar.

Bunun için kayıt sırasında üç soruyu seslendirmek yararlıdır:

• Neye bakıyorum? “Slug’ın mevcut kayıtlarla çakışıp çakışmadığına bakıyorum.”
• Kararı hangi kuralla veriyorum? “Çakışma varsa otomatik yeni ek üretmiyorum; editöre bildiriyorum.”
• Hangi durumda duruyorum? “Kaynak URL’si eksikse kaydı oluşturabilirim ama işi incelemeye hazır kabul etmiyorum.”

Bu yöntem, “şuraya tıkla” bilgisini “bu koşulda şu kararı ver” bilgisine dönüştürür. Ancak bütün editoryal sezgilerin tek bir gösterimle aktarılabileceğini varsaymamak gerekir. Estetik yargı, bağlama bağlı dil tercihleri ve tartışmalı kaynak değerlendirmeleri çoğu zaman birden fazla örnek ve insan geri bildirimi ister.

Bir örnekten kural çıkarmanın sınırı: Genelleme

Kaydedilen görev tek bir yürütmedir; gelecekte kullanılacak skill ise farklı girdilerle karşılaşabilir. Risk tam bu geçişte doğar.

Örneğin kayıtta “Yapay Zekâ” etiketi seçilmiş olabilir. Bu, her yazı için sabit bir adım mıdır, yoksa içeriğin konusuna göre değişen bir seçim midir? Açıklamanın belirli bir uzunlukta olması kural mıdır, yoksa yalnız o örneğin sonucu mudur? Başlık alanının ilk sırada doldurulması zorunlu mudur, yoksa kullanıcının alışkanlığı mıdır?

Tek gösterim, zorunlu kurallarla tesadüfi ayrıntıları ayırmakta yetersiz kalabilir. Bu riski azaltmak için değişkenleri, değişmezleri ve istisnaları sözlü olarak ayırabiliriz:

Pratik karar kuralı şudur: Gelecekte farklı olması mümkün olan her ayrıntıyı “değişken”, hiçbir koşulda aşılmaması gereken sınırı ise “değişmez kural” olarak açıkça söyleyin. Ardından skill’i, normal örnekten farklı en az iki vakayla sınayın.

İçerik yönetim sisteminde taslak hazırlama: Uçtan uca senaryo

Şimdi kayıtla öğretilecek görevi somutlaştıralım. Amaç, onaylanmış bir yazı paketini kullanılan içerik yönetim sistemine eksiksiz bir taslak olarak girmek olsun. Skill’in girdileri başlık, slug, açıklama, HTML içerik, SEO başlığı, meta açıklama, etiketler ve varsa doğrulanmış kaynaklardır.

1. Kayıttan önce başarı sözleşmesini kurun

Gösterime başlamadan önce başarılı sonucun tanımı yapılır:

• Doğru koleksiyonda yalnız bir yeni kayıt oluşmalı.
• Başlık, slug ve açıklama verilen paketle eşleşmeli.
• İçerik alanında semantik HTML bulunmalı ve h1 kullanılmamalı.
• Slug mevcut bir içerikle çakışmamalı.
• Durum “draft” olmalı.
• Kaynaklar yalnız verilen ve doğrulanmış adreslerden oluşmalı.
• Skill hiçbir koşulda içeriği yayımlamamalı.

Bu sözleşme, kaydın sonunda “iş bitti” demek için kullanılacak somut kanıttır.

2. Normal akışı gösterin

Kullanıcı örnek bir yazıyı sisteme girerken her alanın amacını açıklar. Sabit değerlerle girdiden gelen değerleri ayırır. Örneğin durumun her zaman “draft” olduğunu, başlık ve açıklamanın ise her işte değişeceğini söyler.

3. Riskli geçişleri işaretleyin

Alan doldurmak görece düşük riskli, kaydı yayımlamak ise dış dünyada görünür sonuç üreten yüksek riskli bir eylemdir. Skill’in yetkisi bu sınırda bitmelidir. Benzer biçimde mevcut bir kaydı güncellemek, yeni kayıt oluşturmaktan daha riskli olabilir; yanlış eşleşme mevcut içeriği bozabilir.

4. İstisna akışlarını öğretin

Normal kayıt tek başına yeterli değildir. En az şu durumlar için davranış tanımlanmalıdır:

• Aynı slug bulundu: Yeni kayıt oluşturma; çakışan kaydın kimliğini raporla.
• Zorunlu alan eksik: Tahmin ederek doldurma; eksik alanı belirtip dur.
• HTML içinde h1 var: Otomatik silme yetkisi açıkça verilmemişse uyarı üret.
• Etiket bulunamadı: Kendiliğinden yeni etiket oluşturma; mevcut seçenekleri bildir.
• Oturum veya yetki hatası oluştu: Sürekli yeniden deneme; işlemi güvenli biçimde sonlandır.

5. Sonucu bağımsız olarak doğrulayın

Aynı ekranı tekrar görmek yeterli doğrulama değildir. Oluşturulan kaydı yeniden açıp kritik alanları girdi paketiyle karşılaştırmak gerekir. İki kaynak verilen başarılı bir normal vaka için örnek doğrulama raporu şöyle olabilir:

Görev: İçerik taslağı oluşturma
Beklenen durum: draft
Gerçek durum: draft
Oluşturulan kayıt sayısı: 1
Başlık eşleşmesi: başarılı
Slug benzersizlik kontrolü: başarılı
HTML içinde h1 kontrolü: başarılı
Kaynak URL’leri: 2 verildi, 2 kaydedildi
Yayınlama eylemi: gerçekleştirilmedi
Sonuç: İnsan editör incelemesine hazır

Bu rapor yalnız “tamamlandı” demez; tamamlanma iddiasının dayanaklarını gösterir. Slug çakışması vakasında ise yeni kayıt sayısı sıfır olmalı ve sonuç “çakışma nedeniyle durduruldu” şeklinde raporlanmalıdır.

Doğrulama, kayıttan sonra eklenen bir süs değildir

Bir skill’in aynı adımları tekrar edebilmesi, doğru sonuç ürettiği anlamına gelmez. Otomasyonun güvenilirliği üç ayrı düzeyde sınanmalıdır.

Yapısal doğrulama, zorunlu alanların dolu olup olmadığını ve verinin beklenen biçime uyup uymadığını kontrol eder. Anlamsal doğrulama, açıklamanın gerçekten okur değerini anlatıp anlatmadığı veya seçilen etiketin konuya uyup uymadığı gibi daha zor sorulara bakar. Eylem doğrulaması ise doğru kaydın doğru durumda oluşturulduğunu ve yetki dışı bir işlem yapılmadığını kanıtlar.

Bu ayrım önemlidir. Slug teknik olarak geçerli olabilir ama yanlış yazıya ait olabilir. Bütün alanlar dolu olabilir ama içerik kazara yayımlanmış olabilir. Dolayısıyla güvenilir bir skill, hem çıktıyı hem de dış sistemde oluşan yeni durumu kontrol etmelidir.

İlk kullanımda gözetimli çalışma iyi bir kuraldır. Skill önce düşük riskli üç farklı vaka üzerinde çalıştırılır: eksiksiz normal kayıt, çakışan slug ve zorunlu alanı eksik kayıt. Normal vakada tek bir taslak oluşmalı; diğer iki vakada yeni kayıt oluşmamalı ve durma nedeni açıkça raporlanmalıdır. Bu üç beklenen davranış sağlanmadan daha geniş kullanıma geçilmez.

Gizlilik: Ekran kaydı yalnız yaptığınızı değil, gördüğünüzü de taşıyabilir

Ekran kaydı güçlü bir öğretim aracıdır çünkü bağlamı yakalar. Aynı nedenle ciddi bir veri toplama yüzeyi oluşturabilir. Tarayıcı sekmeleri, müşteri isimleri, e-posta adresleri, erişim belirteçleri, yayımlanmamış içerikler, dahili adresler ve bildirim önizlemeleri kayda istemeden girebilir. Sözlü anlatım da kişi adları veya ticari kararlar gibi hassas bilgileri taşıyabilir.

Anthropic’in Cowork güvenlik rehberi, Cowork’un dosyalar, tarayıcı ve uygulamalarla çalışabildiğini; ekran üzerinde tıklama, yazma ve gezinme gibi eylemler gerçekleştirebildiğini belirtiyor. Rehber ayrıca özellikle hassas veriler, güvenilmeyen içerikler ve geri alınması zor işlemler konusunda dikkatli olunmasını öneriyor. Bu yüzden kayıt hazırlarken yalnız videonun öğretici olup olmadığına değil, çalışma ortamına hangi verilerin girdiğine de bakmak gerekir.

Kayıttan önce şu kontrol uygulanmalıdır:

• Gerçek müşteri verisi yerine temsili bir deneme kaydı kullanın.
• Gereksiz sekmeleri, bildirimleri ve yan panelleri kapatın.
• Parola, API anahtarı ve erişim belirteci görünen ekranlara girmeyin.
• Kaydın ve oluşturulan skill’in nasıl işlendiğini, kimlerin erişebildiğini ve hangi saklama kurallarına tabi olduğunu güncel ürün belgeleriyle kuruluş politikanız üzerinden doğrulayın.
• Skill’in çalışma sırasında erişebileceği veri alanlarını ve eylemleri en az yetki ilkesiyle sınırlandırın.
• Kayıt bittikten sonra içeriği yalnız öğretim kalitesi için değil, veri sızıntısı açısından da inceleyin.

Ürün erişimi, veri işleme ayrıntıları ve yönetim seçenekleri planlara, sürümlere ve kuruluş ayarlarına göre değişebilir. Hassas işlerde güncel resmî belgeler ile kurum politikasını her uygulamadan önce yeniden kontrol etmek gerekir.

En tehlikeli sonuç: Hatayı daha hızlı yapmak

Otomasyon iyi bir süreci ölçeklediği kadar kötü bir süreci de ölçekler. Kullanıcı kayıtta yanlış koleksiyonu seçerse, gereksiz bir alanı her seferinde doldurursa veya yayınlama düğmesine alışkanlıkla basarsa skill bu davranışı gelecekte tekrarlayabilir.

Daha sinsi hatalar da vardır. Deneyimli kullanıcı, ekrandaki bir uyarıyı fark edip sezgisel olarak durur fakat bunu seslendirmez. Kaydedilen öğretim örneğinde durma kuralı açıkça yer almaz. Ya da kullanıcı ilk örnekte kaynakları başka bir yerde kontrol etmiştir; kayıt yalnız son değerleri gösterdiği için doğrulama adımı görünmez kalır.

Bu nedenle kayıt, mevcut süreci kutsallaştırmamalıdır. Önce süreç sorgulanmalıdır:

1. Bu adım gerçekten gerekli mi, yoksa alışkanlık mı?
2. Yanlış yapılırsa etkisi nedir?
3. Geri alınabilir mi?
4. Kararı sistem mi vermeli, insan mı?
5. Başarı hangi bağımsız kanıtla doğrulanacak?

Özellikle yayımlama, gönderme, silme, ödeme ve erişim değiştirme gibi eylemler kaydedilen normal akışın otomatik devamı olmamalıdır. Bunlar açık yetki, insan onayı veya ayrı bir güvenlik kapısı gerektirir.

İyi bir skill kaydı için yedi adımlı çalışma yöntemi

1. Görevi daraltın: “İçerik yönetim sistemini yönet” yerine “onaylanmış içerik paketinden taslak kayıt oluştur” deyin.
2. Girdi ve çıktıyı tanımlayın: Hangi alanların verileceğini ve sonunda hangi kaydın oluşacağını belirtin.
3. Temiz bir deneme ortamı hazırlayın: Hassas verileri kaldırın, temsili içerik kullanın.
4. Kararları seslendirin: Tıklamayı değil, tıklamanın nedenini açıklayın.
5. Değişkenlerle değişmezleri ayırın: Başlık değişkendir; durumun taslak kalması değişmezdir.
6. İstisnaları ve durma koşullarını ekleyin: Eksik veri, çakışma ve yetki hatasında ne olacağını tarif edin.
7. Farklı örneklerle sınayın: Normal, sınırda ve başarısız olması gereken vakalarda sonucu doğrulayın.

Bu yöntemin özü basittir: Skill’i bir video tekrar oynatıcısı gibi değil, girdileri, kuralları, yetkileri, durma koşulları ve kanıtları bulunan küçük bir operasyon sistemi gibi tasarlayın.

Sonuç: Gösterim başlangıçtır, güvenilirlik ise tasarım işidir

“Record a skill”, iş öğretmenin doğal bir biçimini otomasyona yaklaştırıyor: Ekranı açıp yaparak göstermek ve süreç boyunca konuşmak. Resmî duyuru, bu gösterimin yeniden çalıştırılabilir bir skill’e dönüştürülebildiğini doğruluyor. Özellikle prosedürü yazıya dökmenin zor, göstermenin kolay olduğu işlerde bu yaklaşım yararlı olabilir.

Yine de tek bir başarılı gösterim, güvenilir bir skill değildir. Kayıt örnek sağlar; genelleme kuralları, doğrulama ölçütleri, gizlilik önlemleri ve yetki sınırları ayrıca tasarlanır. Aksi halde sistemin karar kurallarını doğru yakaladığını varsayar, tesadüfi davranışları süreç kuralına dönüştürür ve hatayı ölçekleyebiliriz.

İlk uygulamanızı düşük riskli ve geri alınabilir bir görevden seçin. İçerik yönetim sistemi örneğinde yalnız taslak oluşturma yetkisi verin, yayınlamayı insan kararında bırakın. Normal akışın yanında bir slug çakışması ve bir eksik alan vakasıyla sınama yapın. Son olarak “Skill aynı adımları izledi mi?” sorusuyla yetinmeyin; “Doğru kayıt oluştuğunu ve yanlış hiçbir eylem yapılmadığını hangi kanıt gösteriyor?” diye sorun.

Göstererek öğretmenin gerçek gücü, fare hareketlerini kopyalamakta değil; insanın iş yaparken kullandığı niyeti, muhakemeyi ve güvenlik sınırlarını açık, sınanabilir ve tekrar kullanılabilir hale getirmektedir.

Kaynaklar

• Claude (@claudeai): “Record a skill” resmî ürün duyurusu, 21 Temmuz 2026
• Claude Help Center: Use Claude Cowork safely