Lovable’da Sadece Basit Bir Site Oluşturmak Değil, Projeyi Baştan Sona Yönetmek İçin Geliştirdiğim “Lovable” Skill’i

Herkese merhabalar,

Bu haftaki yazımı dün yetiştiremedim, o nedenle Cuma günü paylaşıyorum. Geçen hafta içerikleri daha iyi anlayabilmek adına geliştirdiğim Codex Skill'inden bahsetmiştim. Bu yazımda ise favori Vibe Coding aracım Lovable ile internet siteleri, dijital ürünler ve farklı web uygulamaları geliştirirken çok sık kullandığım Codex Skill’ini sizinle paylaşmak istiyorum.

Lovable, bir fikri oldukça kısa sürede çalışan bir ürüne dönüştürebiliyor. Ancak iyi bir sonuç almak için yalnızca “Bana şöyle bir site yap” yeterli değil. Ürünün hangi sayfalardan oluşacağını, kullanıcıların nasıl hareket edeceğini, hangi içeriğin nerede yer alacağını, mobil görünümün nasıl davranacağını ve hangi alanların kesinlikle değiştirilmemesi gerektiğini doğru biçimde anlatmak gerekiyor. Bu çalışmaları yaparken ise sadece Lovable'da ilerlemeye ne kredi dayanıyor, ne de kaliteli bir iş ortaya çıkıyor. O nedenle ayrı bir yapay zekâ aracıyla birlikte koordine çalışmak çok önemli.

Ve ihtiyaç her zaman sıfırdan bir ürün oluşturmak da değil. Bazen mevcut projeye yeni bir bölüm eklemek gerekiyor. Bazen yalnızca mobil görünümdeki bir problemi düzeltmek, bir ekranın mockup’ını hazırlamak veya Lovable’ın önerdiği uygulama planının güvenli olup olmadığını değerlendirmek durumunda kalıyoruz. Bazen küçük bir değişiklik isterken sistemin çalışan diğer bölümleri bozulabiliyor. Vibe Coding araçlarının en temel sorunlarından biri bu maalesef.

Bu nedenle Lovable ile yaptığım çalışmaları tek tek yazılmış bağımsız prompt’larla yönetmek yerine, bütün süreci kapsayan bir çalışma sistemi geliştirdim. Farklı internet sitesi ve uygulama projelerinde karşılaştığım ihtiyaçları, işe yarayan çözümleri ve tekrar eden kontrol noktalarını zaman içerisinde tek bir Codex Skill’i altında bir araya getirdim. Codex'te çalışmaları son haline getirdikten sonra Lovable'a aktararak ilerliyorum. Bu sayede Lovable'da minimum kredi harcayarak maksimum çıktı kalitesine ulaşabiliyorum.

Lovable Skill; yeni bir ürün fikrinin netleştirilmesinden kod içermeyen PNG mockup’ların hazırlanmasına, ilk geliştirme prompt’undan mevcut projeye yeni özellik eklenmesine, ekran geri bildirimlerinden responsive düzeltmelere, Lovable’ın uygulama planının incelenmesinden test ve yayın sürecine kadar bütün çalışma akışını kapsıyor.

Skill’i çalıştırmak için Codex’e projenizi anlatıp:

• “Lovable için bu fikri birlikte geliştirelim.”

• “Önce bu bölümün mockup’ını yap.”

• “Bu geri bildirimi Lovable prompt’una dönüştür.”

• “Lovable böyle bir uygulama planı çıkardı, sence uygun mu?”

• “Yalnızca mobil görünümü düzelt, masaüstünü değiştirme.”

• “Bu özelliği eklesin ama başka hiçbir şeye dokunmasın.”

gibi bir mesaj yazmanız yeterli.

Skill şu anda 17 temel çalışma bloğundan oluşuyor. Her blok kendi içerisinde daha detaylı talimatlar barındırıyor ancak tamamı aynı amaç için birlikte çalışıyor: Lovable’a yalnızca uzun bir prompt vermek değil, fikri doğru anlamak, tasarımı adım adım netleştirmek, değişikliklerin sınırlarını korumak ve uygulanabilir bir ürün geliştirme süreci oluşturmak.

Aşağıda bu blokları neden eklediğimi ve Codex için hazırladığım İngilizce talimatları paylaşacağım.

Lovable Skill 17 Blok:

1. Skill Definition and Purpose (Skill Tanımı ve Amaç)

Bir skill hazırlarken ilk olarak hangi taleplerde devreye gireceğini ve hangi sonucu üretmesi gerektiğini tanımlamak gerekiyor.

Lovable Skill yalnızca yeni bir MVP oluştururken çalışmıyor. Yeni bir sayfa veya özellik eklemek, ekran görüntüsü üzerinden geri bildirim vermek, bir responsive problemi çözmek, Lovable’ın hazırladığı uygulama planını incelemek veya güvenli bir test prompt’u yazmak gibi taleplerde de devreye giriyor.

Temel amacı ise kullanıcı ile Lovable arasında yalnızca prompt yazan bir aracı olmak değil; ürün, kullanıcı deneyimi, içerik ve değişiklik kapsamını birlikte yöneten bir çalışma ortağı gibi davranmak.

Talimat Bloğu

---
name: lovable
description: End-to-end Lovable product design and change-management
  workflow for websites, apps, SaaS products, dashboards,
  communities, marketplaces, and interactive experiences.
  Use when the user wants to shape a new Lovable project,
  clarify requirements, inspect references, create
  code-free PNG mockups, write a complete first-build
  prompt, add or revise a feature/section/route in an
  existing Lovable project, turn screenshot feedback into a
  surgical change prompt, preserve approved design and
  functionality, review Lovable's implementation plan
  before approval, diagnose responsive or UI problems,
  prepare test-only prompts, or plan a safe release.
---

# Lovable

## Purpose

Act as the user's product, UX, content, and change-scope partner for
Lovable. Support the full lifecycle: rough idea, discovery, research,
page planning, code-free mockups, first build, later features,
feedback, implementation-plan review, testing, and release.

2. Route the Request (Talebin Türünü Belirleme)

Lovable ile ilgili her talep aynı çalışma biçimini gerektirmiyor.

Yeni bir ürün fikri üzerinde çalışırken önce ihtiyaçları ve kullanıcı akışını anlamak gerekiyor. Mevcut projedeki tek bir bölümü düzeltirken ise bütün ürünü yeniden tasarlamak doğru değil. Kullanıcı yalnızca bir metin istediğinde kod yazmak veya tek bir bölüm için bütün sitenin prompt’unu hazırlamak da gereksiz.

Bu nedenle skill ilk olarak talebin hangi çalışma türüne ait olduğunu belirliyor.

Talimat Bloğu

Do not treat every request as a new MVP. First determine whether the
user is:

1. defining a new product;
2. exploring or approving a visual direction;
3. asking for a single complete first-build prompt;
4. changing an existing Lovable project;
5. reviewing a plan Lovable proposed;
6. diagnosing or testing an implementation; or
7. preparing domain, SEO, analytics, or release work.

Match the response to that mode. Do not produce code, a full-site
prompt, or a broad redesign when the user asked only for copy, one
mockup, one section, or one targeted fix.

3. Core Working Principles (Temel Çalışma Prensipleri)

Lovable projelerinde yaşadığım sorunların önemli bir kısmı eksik talimatlardan değil, fazla yorumdan kaynaklanıyordu.

Örneğin yalnızca bir bölüm eklenmesini isterken yeni renklerin, açıklama metinlerinin veya butonların da eklenmesi mümkün olabiliyor. Kesinleştirilmiş bir metin yeniden yazılabiliyor veya daha önce reddedilmiş bir tasarım fikri tekrar projeye girebiliyor.

Bu nedenle skill’in temel çalışma prensipleri arasında kapsamı kendiliğinden genişletmemek, onaylanmış metni korumak ve olmayan gerçek içerikleri uydurmamak bulunuyor.

Talimat Bloğu

## Core Working Principles

- Work in the user's language unless asked otherwise.
- Treat the latest explicit user decision as authoritative.
- Preserve approved wording literally when the user says it is final,
  exact, or unchanged.
- Separate confirmed facts, recommendations, assumptions, and
  unresolved decisions.
- Ask only questions that materially change the result.
- Never silently expand scope.
- Never invent real links, logos, people, testimonials, prices, dates,
  legal claims, or unavailable assets.
- When the user supplies a screenshot or approved mockup, treat it as
  implementation evidence, not loose inspiration.

4. Source Priority (Kaynak Önceliği)

Bir proje üzerinde birkaç gün çalışıldığında aynı ekranın farklı mockup’ları, eski metinleri, yeni kararları ve Lovable tarafından uygulanmış sürümleri oluşabiliyor.

Bu noktada hangi bilginin güncel olduğunun belirlenmesi gerekiyor. Kullanıcının son kararıyla eski bir doküman çeliştiğinde, eski dokümandaki bilgi yeniden kullanılmamalı.

Skill bu nedenle bütün kaynaklar için net bir öncelik sırası kullanıyor.

Talimat Bloğu

## Source Priority

Resolve conflicts in this order:

1. the user's latest explicit instruction or edit;
2. the latest mockup or version the user explicitly approved;
3. supplied source files, screenshots, brand materials, and content;
4. the current implemented project or Lovable plan;
5. earlier discussion and exploratory ideas;
6. general best practice.

Do not resurrect a rejected idea.

5. New Product Discovery (Yeni Ürünü Anlama)

Yeni bir uygulama veya internet sitesi geliştirilirken hemen nihai prompt’a geçmek çoğu zaman önemli kararların Lovable’a bırakılmasına neden oluyor.

Bu nedenle skill önce ürünün amacını, hedef kitlesini, temel kullanıcı sonucunu, sayfalarını, rollerini, içeriklerini ve veri ihtiyaçlarını anlamaya çalışıyor. Ancak bu süreci gereksiz bir soru listesine de dönüştürmüyor. Yalnızca ürünün yapısını gerçekten değiştirecek sorular soruluyor.

Talimat Bloğu

### Mode A — New product discovery

1. Ingest all supplied materials before proposing a solution.
2. Summarize the product purpose, audience, desired outcome, and
   constraints.
3. Inventory the required pages, roles, actions, content, assets, and
   data.
4. Identify only decision-changing gaps.
5. Research comparable patterns when requested or materially useful.
6. Propose the smallest complete user flow, not just a collection of
   screens.
7. Confirm scope before writing the master prompt.

6. Visual Exploration and Mockups (Kod İçermeyen Mockup Süreci)

Lovable’a doğrudan uzun bir geliştirme prompt’u vermeden önce tasarımı görmek ve bölüm bölüm onaylamak benim için çok daha verimli oluyor.

Bu nedenle skill’den sıklıkla yalnızca belirli bir sayfanın veya bölümün PNG mockup’ını hazırlamasını istiyorum. Burada önemli olan gerçekten sadece görsel üretmesi; siteyi kodlamaya başlamaması, bütün projeyi tasarlamaması ve ekranda geliştirici notları göstermemesi.

Mockup’ın amacı nihai ürünü oluşturmak değil, hiyerarşi, oran, yerleşim ve görsel yaklaşım üzerinde karar verebilmek.

Talimat Bloğu

### Mode B — Visual exploration and mockups

- Produce code-free image mockups when requested.
- Create only the requested page, section, component, or viewport.
- Work one screen or section at a time when feedback is expected.
- Apply the approved design system and supplied content.
- Do not improvise new brand colors, gradients, card styles, CTAs,
  helper copy, or dark sections.
- Keep editor controls, comments, developer labels, annotations, and
  specification notes out of the end-user visual.
- After approval, record the accepted decisions for the later Lovable
  prompt.

7. First-Build Master Prompt (İlk Geliştirme Prompt’u)

Sayfalar, kullanıcı akışları, içerikler ve mockup’lar netleştikten sonra bütün kararları tek bir geliştirme prompt’unda bir araya getiriyorum.

Burada amaç Lovable’a olabildiğince uzun bir metin vermek değil. Kritik kararları Lovable’ın tahmin etmesine gerek bırakmayacak, kendi içerisinde tutarlı ve uygulanabilir bir ürün tanımı hazırlamak.

Prompt’un; sayfaları, navigasyonu, buton davranışlarını, içerikleri, asset’leri, responsive kuralları, veri ihtiyaçlarını ve değiştirilmemesi gereken alanları birlikte anlatması gerekiyor.

Talimat Bloğu

### Mode C — First-build master prompt

Build the prompt from all approved decisions. It must be
self-contained enough that Lovable does not need to infer critical
structure, content, behavior, or visual rules.

8. Existing-Project Changes (Mevcut Projeye Özellik Ekleme)

Lovable ile çalışırken en sık karşılaştığım ihtiyaçlardan biri, çalışan bir projeye yeni bir özellik veya bölüm eklemek.

Bu tür değişikliklerde yalnızca neyin ekleneceğini anlatmak yeterli değil. Yeni bölümün tam olarak nereye yerleşeceğini, hangi rotada çalışacağını, hangi kullanıcıların göreceğini ve mevcut sistemde hangi alanlara dokunulmaması gerektiğini de belirtmek gerekiyor.

Skill önce değişikliğin etkisini değerlendiriyor. Talep yalnızca görsel mi, içerikle mi ilgili, navigasyonu mu değiştiriyor, yoksa veritabanı, yetkilendirme veya gerçek zamanlı çalışma gibi daha geniş bir etkisi mi var?

Talimat Bloğu

### Mode D — Existing-project change or feedback

1. Establish the current state from the user's description,
   screenshots, files, or Lovable plan.
2. Define the exact insertion point, affected route, component, role,
   and viewport.
3. Determine the blast radius: visual only, content only, navigation,
   frontend state, backend/schema, authentication, permissions,
   realtime, email, domain, or infrastructure.
4. Recommend the lowest-risk implementation that satisfies the
   request.
5. If visual approval is needed, create the narrow mockup first.
6. Write a surgical change prompt with acceptance checks.

9. Change Ledger (Değişecek ve Korunacak Alanları Ayırma)

“Başka hiçbir şeyi değiştirme” cümlesi önemli olsa da tek başına yeterince kesin değil.

Lovable’ın hangi alanları koruması gerektiğini açıkça yazmak gerekiyor. Örneğin yalnızca mobil görünüm değişecekse masaüstü ve tablet tasarımları korunmalı. Bir metin değiştirilecekse mevcut sayfa yapısı, butonlar, linkler ve backend davranışları aynı kalmalı.

Bu nedenle skill her değişiklikte küçük bir kapsam defteri oluşturuyor.

Talimat Bloğu

Create a change ledger:

- **Change:** exact requested modifications.
- **Preserve:** routes, content, design, behavior, data, or viewports
  that must remain untouched.
- **Unknown:** details Lovable must inspect rather than guess.

If the user says "do not change anything else," translate that into
explicit protected areas. Do not rely on a generic sentence alone.

10. Lovable Implementation-Plan Review (Lovable’ın Planını İnceleme)

Lovable bazen geliştirmeye başlamadan önce nasıl ilerleyeceğini anlatan bir uygulama planı hazırlıyor.

Bu plan mantıklı görünse bile kullanıcının istemediği mimari değişiklikler, yeni bağımlılıklar, veritabanı güncellemeleri veya tasarım kararları içerebiliyor. Bu nedenle uygulamayı onaylamadan önce planın ayrıca incelenmesi oldukça faydalı oluyor.

Skill planı doğrudan yeniden yazmak yerine önce değerlendiriyor ve üç sonuçtan birini veriyor: onaylanabilir, belirli düzeltmelerle onaylanabilir veya uygulamadan önce yeniden hazırlanmalı.

Talimat Bloğu

### Mode E — Lovable implementation-plan review

Check:

- whether all requested items are present;
- whether separate requests are placed at their correct locations;
- whether approved text, layout, route, interaction, or asset mapping
  was altered;
- whether Lovable introduced unrequested architecture, styles, copy,
  or dependencies;
- whether database schema, auth, RLS, email, realtime, routing, SEO,
  or infrastructure changes are necessary;
- whether desktop, tablet, and mobile behavior is explicit;
- whether success and failure states are complete;
- whether the plan is testable.

Return a clear verdict: approve, approve with named corrections, or
revise before implementation.

11. Discovery and System Map (Ürün Sistemini Haritalandırma)

Özellikle birden fazla kullanıcı rolü veya gerçek zamanlı etkileşim içeren uygulamalarda yalnızca ekran listesi hazırlamak yeterli olmuyor.

Kimin hangi bilgiyi görebileceğini, süreci kimin başlatacağını, ekranların hangi durumlarda değişeceğini ve sistemde bir hata yaşandığında ne olacağını da tanımlamak gerekiyor.

Bu nedenle skill gerektiğinde ürünün rol, ekran, aksiyon, veri ve durum haritasını çıkarıyor.

Talimat Bloğu

## Discovery and System Map

Map the relevant parts of:

- product purpose and target users;
- routes and screen responsibilities;
- roles and permissions;
- navigation and page-to-page behavior;
- empty, loading, success, error, disabled, completed, expired, and
  offline states;
- forms, validation, emails, redirects, external links, uploads, and
  downloads;
- data entities and relationships;
- backend, auth, admin, payment, analytics, email, or realtime
  requirements;
- responsive rules;
- exclusions and later-phase ideas.

For multi-role or realtime experiences, map the state machine
explicitly.

12. Content and Asset Handling (İçerik ve Görsel Dosyaları Eşleştirme)

Bir projeye çok sayıda görsel, logo veya içerik dosyası yüklendiğinde Lovable’ın bunları yanlış bölümlerde kullanması mümkün olabiliyor.

Dosya isimleri veya yükleme sırası da her zaman güvenilir değil. Bu nedenle skill, önemli asset’ler için hangi dosyanın hangi bölümde, hangi oranla ve hangi bağlantıyla kullanılacağını açıkça eşleştiriyor.

Kesinleştirilmiş metinlerde ise kelimelerin, sıralamanın, linklerin ve vurguların korunmasını istiyor.

Talimat Bloğu

## Content and Asset Handling

Create an inventory containing:

- visible asset identity;
- source filename;
- destination page, component, or slot;
- crop or fit behavior;
- link target;
- missing, pending, or coming-soon state.

Match images by visible content or explicit identity, not unreliable
upload order or filename numbering.

For exact copy:

- preserve wording, order, punctuation, emphasis, and links;
- treat user-edited versions as superseding earlier drafts;
- do not add explanatory microcopy merely to fill space;
- design for realistic long strings and variable item counts.

13. Visual and Responsive Fidelity (Görsel Tutarlılık ve Mobil Uyumluluk)

Responsive tasarımda “mobil uyumlu yap” demek çoğu zaman yeterli olmuyor.

Bir bölüm mobilde düzeltilirken masaüstü tasarımının bozulması veya bütün öğelerin orantısız biçimde küçültülmesi mümkün. Bu nedenle skill masaüstü, tablet ve mobil davranışlarını gerektiğinde ayrı ayrı tanımlıyor.

Örneğin talep yalnızca mobil görünümle ilgiliyse masaüstü ve tablet tasarımları açıkça koruma altına alınıyor.

Talimat Bloğu

## Visual and Responsive Fidelity

Define desktop, tablet, and mobile separately when behavior differs.

A mobile-only request must explicitly freeze desktop and tablet.

Require:

- no horizontal scrolling;
- readable text without clipping;
- intact email addresses and other long strings;
- touch-safe controls;
- preserved content and action order;
- checks at representative widths such as 360, 390, and 430 px.

Do not solve a proportional problem by shrinking everything
indiscriminately. Rebalance typography, spacing, image size, and
container height together.

14. Architecture and Safety Rules (Mimariyi ve Çalışan Sistemi Koruma)

Küçük bir tasarım değişikliği sırasında veritabanının, kullanıcı giriş sisteminin veya gerçek zamanlı çalışma mantığının değiştirilmesini istemeyiz.

Bu nedenle skill her talebin teknik etkisini sınırlandırmaya çalışıyor. Mevcut tasarım sistemi ve bileşenler mümkün olduğunca yeniden kullanılıyor. Yeni bir backend, admin paneli veya veri modeli yalnızca gerçekten gerekli olduğunda öneriliyor.

Ayrıca riskli veya yedek özelliklerin ana kullanıcı akışından ayrı tutulması isteniyor. Böylece alternatif bir çözüm eklenirken çalışan sistemin etkilenme ihtimali azalıyor.

Talimat Bloğu

## Architecture and Safety Rules

- Prefer scoped, reversible changes.
- Reuse the project's current design system and component patterns.
- Do not change routes, schemas, auth, RLS, backend functions,
  realtime logic, or dependencies unless required.
- Keep optional fallback experiences isolated from the main flow.
- Keep repeated content in a single structured source of truth.
- Do not add a broad admin system without approval.
- Separate required access consent from optional marketing permission.
- Never expose secrets or sensitive role-only information in
  client-visible state.

15. Diagnosis, Testing and Release (Test ve Yayın Süreci)

Bazen Lovable’dan yeni bir geliştirme değil, yalnızca mevcut uygulamayı test etmesini istiyorum.

Bu durumda test sırasında bulduğu sorunları kendiliğinden düzeltmeye başlamaması önemli. Önce sorunları raporlaması, kanıtları göstermesi ve kesin bir hata ile muhtemel bir problemi birbirinden ayırması gerekiyor.

Test kapsamının da sınırsız olmaması lazım. Hangi rotaların, kullanıcı rollerinin, ekran boyutlarının ve davranışların kontrol edileceği baştan belirleniyor.

Talimat Bloğu

### Mode F — Diagnosis, testing, and release

- Diagnose from evidence before prescribing changes.
- Distinguish a confirmed defect from a likely or uncertain one.
- When requested, write a report-only test prompt that forbids
  automatic fixes.
- Keep tests bounded: name routes, roles, viewports, actions, expected
  outcomes, evidence, and stop conditions.
- Do not test against production, shared data, paid services, or real
  users without authorization.
- For high-risk features, recommend a manual rehearsal and rollback
  path.
- Separate app changes from DNS, redirects, SEO, favicon, analytics,
  and hosting configuration.

16. Master and Surgical Prompt Anatomy (İki Farklı Prompt Yapısı)

Skill içerisinde bütün Lovable prompt’ları aynı formatta hazırlanmıyor.

Yeni bir ürün için hazırlanan master prompt; ürünün amacı, sayfaları, tasarım sistemi, içerikleri, kullanıcı akışları ve teknik ihtiyaçları gibi bütün sistemi kapsıyor.

Mevcut projedeki belirli bir değişiklik için ise daha dar kapsamlı bir surgical change prompt hazırlanıyor. Bu prompt yalnızca hedeflenen değişikliği, yerleşim noktasını, korunacak alanları ve kabul kriterlerini anlatıyor.

Talimat Bloğu

## Master Prompt Anatomy

1. objective and audience;
2. source priority and approved references;
3. scope and non-goals;
4. routes, roles, and user flow;
5. global design system;
6. page-by-page structure and exact content;
7. asset-to-component mapping;
8. interactions and states;
9. data, auth, backend, admin, email, or realtime requirements;
10. responsive and accessibility behavior;
11. SEO, security, analytics, and release requirements;
12. acceptance checklist.

## Surgical Change Prompt Anatomy

1. Goal
2. Current state
3. Exact changes
4. Placement
5. Content and assets
6. Behavior
7. Protected areas
8. Acceptance checks

17. Quality Gate (Son Kalite Kontrolü)

Bütün talimatlar yazılmış olsa bile, nihai prompt hazırlanırken küçük fakat kritik bir kararın unutulması mümkün.

Bu nedenle skill çıktıyı vermeden önce kendi çalışmasını kontrol ediyor. En güncel kararların kullanılıp kullanılmadığı, kapsamın genişleyip genişlemediği, korunacak alanların açıkça belirtilip belirtilmediği ve herhangi bir içerik veya tasarım unsurunun uydurulup uydurulmadığı yeniden değerlendiriliyor.

Talimat Bloğu

## Quality Gate Before Delivery

Before delivering a mockup, prompt, or plan verdict, verify:

- Does it reflect the latest accepted decision?
- Is the requested scope complete but not expanded?
- Are separate changes mapped to separate locations?
- Are all protected areas named?
- Are supplied words, links, assets, and counts preserved?
- Are roles, navigation, success, error, and empty states coherent?
- Are desktop, tablet, and mobile effects explicit?
- Are backend and infrastructure changes justified?
- Can the result be tested with observable acceptance criteria?
- Did any invented copy, asset, style, or feature slip in?

Buraya kadar okuduğunuz için çok teşekkür ederim.

Ben Lovable Skill’ini yeni bir ürün fikrini şekillendirirken, sayfaları planlarken, mockup hazırlarken ve mevcut projelerde yeni geliştirmeler yaparken kullanıyorum. Özellikle çalışan bir sistem üzerinde küçük bir değişiklik yapılacaksa kapsamın doğru korunması oldukça faydalı oluyor.

Çünkü yapay zekâ ile ürün geliştirirken önemli olan yalnızca ne istediğimizi anlatmak değil. Nelerin değişmemesi gerektiğini, hangi kararların kesinleştiğini ve ortaya çıkan sonucun nasıl kontrol edileceğini de tanımlamak gerekiyor.

“Bana bir internet sitesi yap” gibi genel bir prompt hızlı bir başlangıç sağlayabilir. Ancak fikir geliştikçe, sayfalar çoğaldıkça ve ürüne yeni özellikler eklendikçe daha sistemli bir çalışma biçimine ihtiyaç duyuluyor.

Bence önümüzdeki dönemde yapay zekâ ile ürün geliştirmede fark yaratacak şey yalnızca daha uzun prompt’lar yazmak olmayacak. Fikri doğru sorularla netleştiren, tasarımı adım adım onaylatan, mevcut sistemi koruyan ve yapılan değişikliği test edilebilir hâle getiren çalışma sistemleri çok daha önemli olacak.

Lovable Skill’i de tam olarak bu ihtiyacı çözmek için geliştirdim.

Skill’in tamamını indirilebilir bir doküman olarak almak isterseniz bana özelden mesaj gönderebilir veya paylaşımın altına yorum bırakabilirsiniz.

Denerseniz deneyimlerinizi, geliştirme önerilerinizi ve eklemek istediğiniz yeni çalışma biçimlerini benimle paylaşmayı unutmayın.

İyi çalışmalar diliyorum.

Enis Erdem Yurdatapan

enis@experinn.com

experinn.com