Instalare cu AI

Lasă un asistent AI de cod să facă integrarea pentru tine. Funcționează cu orice agent care poate citi un URL sau un fișier lipit și îți poate edita codul — Claude Code, Cursor, Copilot, Windsurf și altele asemenea.

Mecanismul e un singur fișier: un playbook pentru agenți, la https://dailysmith.com/docs/agent/install-sdk.md. E ghidul JS SDK rescris pentru un executor automat: fragmente exacte, punctele de decizie per framework, comenzi curl care îți validează cheia și calea de bază înainte ca vreun cod să fie editat, și o listă de verificare finală.

Promptul

Lipește asta în asistentul tău, completând cheia ta:

Read https://dailysmith.com/docs/agent/install-sdk.md and follow it to install
the baas studio blog on this website.

Publishable key: pk_YOUR_KEY
Blog base path: /blog

Cheia ta publică e pe pagina site-ului din dashboard, iar calea de bază e oricare a fost configurat blogul să fie montat (/blog, dacă nu ai schimbat-o). Dacă omiți una dintre ele, playbook-ul îi spune agentului să se oprească și să te întrebe, în loc să ghicească.

Fiecare pagină de documentație poate fi preluată și ca markdown brut — adaugă .md la finalul URL-ului (ex. /docs/install-sdk.md), sau pornește de la indexul /docs/llms.txt. Paginile randate își anunță sursa prin <link rel="alternate" type="text/markdown">.

Ce va face agentul

1. Validează înainte de a edita

   Apelează delivery API cu cheia și calea ta de bază. O cheie greșită, un site neverificat sau o cale de bază nepotrivită sunt prinse aici, cu instrucțiuni despre cum să repari fiecare — niciun cod nu e atins într-un impas.

2. Inserează fragmentul SDK

   Adaugă fragmentul de două linii (container plus script) pe pagina de la calea ta de bază, în orice formă își dorește stack-ul tău — o pagină statică, o rută catch-all Next.js sau SvelteKit, un template de CMS.

3. Servește shell-ul peste tot

   Îți configurează hostul ca fiecare URL de sub calea de bază să returneze acea pagină — pasul pe care integrările manuale îl ratează cel mai des — folosind regulile de rewrite ale platformei tale (Netlify, Vercel, nginx, sau ruta framework-ului însuși). Pe un site exportat static, face în plus ca build-ul să emită URL-uri absolute pentru resurse — fără ele, bundle-ul dă 404 pe fiecare URL de articol.

4. Integrează blogul în designul tău

   Blogul moștenește fontul și culorile tale, dar nu și stilul linkurilor, lățimea coloanei de text sau scara titlurilor. Playbook-ul îi cere să le rezolve după stilurile site-ului, nu să lase valorile implicite ale browserului.

5. Verifică și raportează

   Încarcă din browser, cu refresh complet, un URL real de articol și verifică dacă pagina chiar a pornit — nu doar dacă a venit HTML înapoi — apoi raportează ce s-a schimbat, ce nu a putut verifica singur și ce mai rămâne de făcut de tine (publicarea articolelor).

E sigur?

Integrarea implică doar cheia ta publică (pk_…), care e publică prin design — oferă acces de citire la articolele tale publicate și nimic altceva. Playbook-ul îi instruiește explicit agentului să nu ceară sau să nu gestioneze niciodată chei secrete, să țină diff-ul limitat la ruta de blog, configurația de rutare și stilurile care integrează blogul în designul tău, și să nu facă commit sau deploy fără aprobarea ta. Pe un site exportat static trebuie să schimbe în plus o singură setare globală de build, ca resursele să se rezolve pe URL-uri adânci — playbook-ul îi cere să menționeze explicit asta în raport. Ca la orice scrie un agent, verifică diff-ul înainte să îl trimiți în producție.