Claude Skills by ibrahim-isikli

Bir akademik makale/tez taslağını dergi hakemi veya tez jürisi gözüyle eleştirir — içerik yazmaz veya iyileştirmez, sadece değerlendirir. Araştırma sorusunun netliği/literatüre katkısı, yöntem sağlamlığı, bulgular ile tartışma arasındaki tutarlılık ve literatüre yerleşim üzerinden somut, gerekçeli zayıf noktalar çıkarır. Kullanıcı bir makale/tez taslağı paylaşıp "hakem ne der", "bu makaleyi eleştir", "red mi alır", "jüri gözüyle değerlendir", "dergiye göndermeden önce kontrol et" gibi bir şey...

Bir akademik taslaktaki metin-içi atıflar ile kaynakça arasındaki tutarlılığı kontrol eder, atıf formatını (APA 7, Chicago, IEEE, Vancouver, MLA) denetler, şüpheli/muhtemelen uydurma (hallucinated) kaynakları örnekleme yaparak canlı arama ile doğrulamaya çalışır, ve aşırı iddialı (overclaiming) ifadeler ile yapay zeka açıklaması (disclosure) gerekliliği gibi bütünlük kontrollerini yapar — intihal/metin benzerliği taraması yapmaz, bunun için iThenticate/Turnitin gibi araçlara yönlendirir. Kull...

Bir akademik araştırma sorusu için literatür tarama stratejisi kurar, DergiPark/TR Dizin/Google Scholar/YÖK Ulusal Tez Merkezi gibi kaynaklarda canlı arama yapar ve bulunan kaynakları alaka/güncellik/tür açısından değerlendirir — kullanıcının yerine makale özetleyip "literatür taraması yapıldı" gibi bir sonuç uydurmaz, sadece bulduğunu kaynağıyla raporlar. Araştırma sorusunu netleştirmek için Sokratik sorular da sorabilir. Kullanıcı "bu konuda literatür taraması yap", "hangi kaynaklar var", "...

Bir akademik makale/tez/tez bölümü için Sokratik sorularla yapı ve akış planlaması yapar (IMRAD, tez bölümleri, derleme, vaka çalışması, politika notu vb.), taslak bir iskelet/başlık ağacı üretir ve kullanıcının kendi taslağındaki yapısal/mantıksal zayıflıkları eleştirir — ama paragrafları veya tam cümleleri kullanıcı adına yazmaz. Kullanıcı "bu makaleyi nasıl yapılandırayım", "tez bölümlerimi planla", "bu taslağın akışında sorun var mı", "giriş bölümü nasıl olmalı", "argümanım tutarlı mı" gi...

Açık TÜBİTAK TEYDEB/ARDEB çağrılarını (1501, 1505, 1507, 1509, 1511, 1707, ARDEB 1001, 3001 vb.) web üzerinden tarar ve son başvuru tarihine göre sıralı bir tablo üretir. Bütçe üst limiti, çağrı dönemi gibi sayısal değerleri asla hafızadan yazmaz, mutlaka güncel kaynaktan çeker ve kaynağı belirtir. Kullanıcı "açık çağrılar neler", "1501'in son başvuru tarihi ne zaman", "hangi TÜBİTAK çağrılarına başvurabilirim", "çağrı takvimi çıkar", "bütçe üst limiti kaç TL" gibi bir şey sorduğunda, ya da /...

Kabul edilmiş bir TEYDEB projesinin dönemsel Gelişme Raporu'nu (AGY301) veya proje sonu Sonuç Raporu'nu, TEYDEB'e sunulmadan önce hakem/izleyici gözüyle eleştirir — içerik yazmaz. Onaylı proje planı (AGY101/iş paketleri/takvim/bütçe) ile rapor taslağını karşılaştırıp teknik hedeflere ulaşıldığına dair somut kanıt eksikliğini, gerekçesiz takvim/bütçe sapmalarını ve tutarsız bir sonraki dönem planını işaretler. Kullanıcı "gelişme raporumu kontrol eder misin", "dönem raporunu göndermeden önce ba...

Kullanıcının belirttiği ürün/teknoloji alanında somut TÜBİTAK Ar-Ge proje fikri adayları üretir; her adayı cagri-tarama ile güncel çağrı uygunluğuna, patent-on-arastirma ile ön özgünlük taramasına ve teknik belirsizlik/yenilik/sistematik çalışma/yaygın etki kriterlerine göre eler, hayatta kalanları Proje Fikri Öneri Formu formatında sunar. Üretilen fikirleri asla "şirketin doğrulanmış, gerçek bir sorunu" gibi sunmaz — aksi belirtilmedikçe varsayımsal (GENERATED) olarak işaretler. Kullanıcı "b...

Bir TEYDEB proje bütçesindeki gider kalemlerini (personel, seyahat, hizmet alımı, alet/teçhizat/yazılım/yayın alımı, malzeme/sarf) 5 resmi kategoriye oturtur ve her kalemi hakemlerin sık sık uygunsuz/orantısız bulduğu somut kalıplara (fazla mesai-prim-yol-yemek gibi uygun olmayan personel ödemeleri, business class seyahat, "altyapı yatırımı" gibi görünen genel yazılım/donanım alımları, gerekçesiz dış hizmet alımı vb.) göre işaretler. Bütçe üst limiti gibi sayısal değerleri asla hafızadan yazm...

Bir TÜBİTAK Ar-Ge proje önerisi taslağını (1501, 1507, 1509, 1511, 3001 vb.) panel hakemi gözüyle eleştirir — içerik yazmaz veya iyileştirmez, sadece değerlendirir. Endüstriyel Ar-Ge niteliği/yenilik, proje planı/yapılabilirlik ve en belirleyici boyut olan ticarileşme potansiyeli üzerinden somut, gerekçeli zayıf noktalar çıkarır. Kullanıcı bir proje önerisi/başvuru metni paylaşıp "şuna bir bak", "hakem ne der", "bu taslağı eleştir", "reddedilir mi", "değerlendirir misin", "panelist gözüyle ok...

Bir TÜBİTAK projesi hakem raporuyla reddedildiğinde, kullanıcının itiraz mı etmesi yoksa revize edip yeniden mi başvurması gerektiğine karar vermesine yardımcı olur; itiraz yolu seçilirse TÜBİMER'e sunulacak itiraz dilekçesini SADECE mevcut proje metni ve hakem raporundaki ifadelere dayanarak, 4 izin verilen gerekçe kategorisinden birine oturtarak hazırlar — yeni teknik iddia veya proje değişikliği asla eklemez, çünkü bu itirazı geçersiz kılar. Kullanıcı "projem reddedildi ne yapmalıyım", "ha...

Bir proje fikri için önce ücretsiz genel patent veritabanlarında (Google Patents/Espacenet, WebSearch/WebFetch ile) canlı ön araştırma yapar; kullanıcı TÜRKPATENT'e özel doğrulama veya marka/tasarım araması istediğinde markapatent-mcp sunucusu üzerinden TÜRKPATENT'i de tarar. Benzer başvuruları listeler, "bu fikir özgündür/tescillenebilir" gibi bir sonuca asla varmaz — karar her zaman insana aittir. Kullanıcı "bu fikir daha önce patentlenmiş mi", "benzer patent var mı", "TÜRKPATENT'te ara", "...

Aynı proje için hazırlanmış birden fazla belge (proje önerisi/AGY101, bütçe dökümü, iş paketleri, hakem raporu, dönem raporu, ticarileşme planı vb.) arasında süre, toplam bütçe, personel sayısı, iş paketi/hedef tanımı, TRL, ticarileşme/satış tarihi gibi alanlarda çelişki arar ve karşılaştırmalı bir tabloda raporlar — hangi belgenin doğru olduğuna karar vermez, sadece çelişkiyi gösterir. Kullanıcı birden fazla proje belgesi paylaşıp "bunlar birbiriyle tutarlı mı", "belgeler arasında çelişki va...