Ovo je "kratki" guide book koji bi trebao olakšati development sa ai modelima. Mozete ga koristiti u cursoru ali primjenjiv je i u claude code-u , codex-u ili nekom trecem..
Kreirajte PRD sa GPT-5.2 ili bilo kojim high level modelom. U ovom koraku odradite i database model sa tablicama i entitetima. Dokument treba biti u md formatu, stavite ga u root direktorij od projekta.
U Cursoru prvi prompt NE SMIJE tražiti implementaciju featurea(arhitektura).
Njegova svrha je da:
- Cursor razumije cijeli projekt (PRD + arhitekturu)
- Predloži repo strukturu
- Predloži redoslijed epica i taskova
- Definira baseline setup (backend + frontend + docker)
- Ne napiše još “business code”
Evo primjera:
- između zagrada stavite relevantno za vaš projekt <<< >>>
- Tech constraints popunite sa onim sto mislite koristiti
Prompt:
You are a senior full-stack architect and Symfony + React expert.
I am building a <<< ovdje stavite ime npr: financial management web application >>>.
I already have a complete Project Plan and PRD (see below).
Your task in this step is NOT to implement features.
Your goals in this step:
1. Fully understand the domain and requirements
2. Propose a clean project structure (backend + frontend + shared)
3. Propose a Jira-ready breakdown:
- Epics
- Small, isolated tasks per epic
- Clear dependencies between tasks
4. Define the minimal “foundation” milestone that allows the app to run
(auth, empty DB, health check, basic UI shell)
5. Define how clean production DB vs demo/mock data should be handled
6. Propose a development and deployment strategy (local + production)
DO NOT write business logic yet.
DO NOT implement entities, controllers or React components yet.
Only output:
- Architecture decisions
- Folder/repo structure
- Epic & task list
- Setup plan
Tech constraints:
- Backend: Symfony 7 + API Platform
- Frontend: React + Vite + TypeScript
- State/data: TanStack Query
- Package manager: pnpm
- Database: PostgreSQL (SQLite allowed for dev)
- Docker-based local & prod setup
Here is the Project Plan and PRD:
<<<
paste prd markdown ili ga referencirajte sa @ znakom u cursoru
>>>
Sa ovim promptom smo:
- forsirali cursor u "arhitekt mode" (spriječili krive pretpostavke, spriječili pisanje preuranjenog koda koji bi morao biti rewritean)
- dobili JIRA ready output(mapiranje 1:1)
- zalokali tech stack kako cursor ne bi predlagao random libs a koristi one koje smo mu zadali
- dobili mali izolirane taskove koji bi trebali biti potpuno funkcionalni i testivi, koji postuju dependency taskove
Nakon ovoga idemo izgraditi execution sistem, sa ovim promptom cemo:
- izgraditi nacin pracenja progresa
- znati šta je current a šta je done
- sacuvati kontekst kad cursor zaboravi (memory-bank/ i docs/)
- izgraditi nacin rada task po task postivajuci arhitekturu
/docs/:
- PROJECT.md (naš PRD dokument + arhitektura — ovo što vec imamo)
- TASKS.md (epici + taskovi + dependencies + statusi)
- DECISIONS.md (mali ADR(Architectural Decision Record) log: što smo odlučili + zašto)
- SETUP.md (dev setup + prod deploy + database modes)
- DATA.md (demo fixtures strategy + production bootstrap checklist)
/memory-bank/:
- STATE.md (current work: ono na cemu trenutno radimo, last completed task, next task)
- CONTEXT.md (kratki domain summary + rječnik + kljucna pravila)
- CONVENTIONS.md (coding conventions, naming, “how we work” pravila)
- CHANGELOG.md (što se promjenilou pojedinom sessionu)
Prompt:
We are proceeding with this architecture and epic/task breakdown.
NEXT STEP: create an execution + memory system inside the repo so progress can be tracked and context can be restored in future sessions.
Task:
1) Add a /docs and /memory-bank structure and generate the following files with strong, practical content:
/docs/PROJECT.md
- paste/retain the PRD summary and architecture decisions
- include the chosen stack and monorepo structure
- include scope/out-of-scope
/docs/TASKS.md
- list all Epics (EPIC-0..EPIC-6)
- under each epic list tasks (TASK-0.1 etc)
- include dependencies
- include priority
- include a STATUS field per task (TODO / IN_PROGRESS / BLOCKED / DONE)
- add “Definition of Done” for tasks and epics
- add “How we work” rules: tasks must be isolated and fully functional
/docs/DECISIONS.md
- create a small ADR log format:
Date | Decision | Why | Alternatives | Consequences
- pre-fill with key decisions already made (stack, JWT, Postgres, fixtures groups)
/docs/SETUP.md
- dev setup (pnpm, docker compose, backend, frontend)
- prod setup (docker-compose.prod.yml)
- clean production DB bootstrap checklist (what must exist so app works)
- migrations workflow
/docs/DATA.md
- explain “clean production database” vs “demo fixtures”
- define fixture groups: base + demo
- provide commands to reset DB, seed demo, migrate production
- propose what baseline seed must create in production (roles, default categories, settings)
/memory-bank/STATE.md
- template:
Current Epic:
Current Task:
Last Completed:
Next Task:
Blockers:
Notes:
/memory-bank/CONTEXT.md
- short domain glossary and key rules (profit != loan != capital, transfers not income, etc)
/memory-bank/CONVENTIONS.md
- coding conventions (Symfony, API Platform, React)
- branch/commit conventions
- testing expectations
/memory-bank/CHANGELOG.md
- empty starter template
2) Update root README.md to point to these files and explain how to use them.
Do NOT implement business features yet.
Only create the folder structure + docs + templates.
If any files already exist, update them rather than duplicating.
Output: list created/updated files and show their full contents.
Nakon ovoga mozemo krenuti, ukoliko želimo što prije, u rad na taskovima na ovaj način:
- “Read /memory-bank/STATE.md and /docs/TASKS.md”
- “Implement only Current Task”
- “Update STATE.md + CHANGELOG.md”
- Commit
Ovdje je bitno napomenuti da promptovi moraju biti strukturirani.
Recimo ovo bi bio primjer prvog task strukturiranog prmpta:
Proceed with TASK-0.1 now.
Rules:
- First read /memory-bank/STATE.md and /docs/TASKS.md and follow them.
- Implement ONLY TASK-0.1. Do NOT start TASK-0.2 or TASK-0.3.
- Keep changes minimal and isolated to this task.
- When done: update /docs/TASKS.md (set TASK-0.1 to DONE), update /memory-bank/STATE.md (Current/Last/Next), and add an entry to /memory-bank/CHANGELOG.md.
TASK-0.1 acceptance criteria:
1) pnpm workspace monorepo is initialized and installs successfully:
- pnpm-workspace.yaml exists
- root package.json exists with workspace config and scripts
- base folder structure exists:
apps/api/
apps/web/
packages/shared/
docker/
docs/
memory-bank/
2) Root .gitignore added (Node, Symfony, IDE, env files, vendor, dist, etc.)
3) Add minimal placeholder package.json files in:
- apps/api/package.json (only name/private to satisfy workspace; no dependencies yet)
- apps/web/package.json (only name/private; no dependencies yet)
- packages/shared/package.json (only name/private; no dependencies yet)
4) Add README.md update only if needed to reflect running "pnpm install" at root.
Output:
- Show the full contents of each created/modified file.
- Then list the exact commands to run to validate TASK-0.1 (pnpm -v, pnpm install, etc.)
Prije nego bi isao na task 0.2 provjerio bi sta je i kako odradio i zadao recimo ovakav strukturirani prompt:
Before starting TASK-0.2, do a quick polish pass for TASK-0.1 to avoid future tech debt.
Rules:
- Only touch files related to TASK-0.1.
- Do NOT scaffold Symfony or React yet.
Do the following:
1) Ensure pnpm-workspace.yaml is valid multi-line YAML:
packages:
- "apps/*"
- "packages/*"
2) Update README.md validation section for TASK-0.1:
- remove any absolute paths like /private/var/www/...
- remove 'pnpm dev' from validation commands
- keep validation as:
pnpm -v
pnpm install
pnpm ls -r --depth 0
3) Optional cleanup (recommended):
Replace the placeholder "echo" scripts in apps/api/package.json and apps/web/package.json with NO scripts at all (keep only name/version/private/description).
We will add scripts when the apps are scaffolded.
After changes:
- Update docs/TASKS.md notes for TASK-0.1 if needed (but keep status DONE)
- Update memory-bank/CHANGELOG.md with a short entry “TASK-0.1 polish”
- Update memory-bank/STATE.md: Next Task remains TASK-0.2
Output full contents of modified files.
Ako je bilo porebe damo mu jos koji strukturirani prompt ili se prebacimo u debug nacin rada(cursor ima plan, ask, agent i debug nacine rada) i nakon sto rijesimo problem commit i nastavljamo sa slijedecim taskom. Bitno je napomenuti da nakon sto smo rijesili problem moramo odraditi afterchanges izmjene tj. reci cursoru da (ovo je primjer):
Prompt:
- Update docs/TASKS.md notes for TASK-0.1 if needed (but keep status DONE)
- Update memory-bank/CHANGELOG.md with a short entry “TASK-0.1 polish”
- Update memory-bank/STATE.md: Next Task remains TASK-0.2
Recimo da smo riješili problem koji smo imali i trebamo prijeci na drugi task, evo jos primjera primjera strukturiranog prompta:
Start TASK-0.2: Scaffold Symfony 7 API project.
Rules:
- Read /memory-bank/STATE.md and /docs/TASKS.md first.
- Implement ONLY TASK-0.2.
- Do not touch frontend apps/web except where absolutely necessary (should be none).
- Update TASKS.md, STATE.md, CHANGELOG.md at the end.
Acceptance Criteria for TASK-0.2:
1) Symfony 7 project exists under apps/api
2) API Platform installed and reachable
3) composer scripts exist for: lint/test (even if minimal)
4) A working endpoint exists:
GET /api/health -> { status: "ok", timestamp, db: "unknown|ok" }
(db can be "unknown" until TASK-0.5/0.16, but endpoint must work)
5) Minimal .env.example inside apps/api with DATABASE_URL placeholder
6) Document how to run backend locally WITHOUT Docker:
- composer install
- symfony serve
- curl health endpoint
Output:
- list all created files
- show commands to run and expected output
Nakon par odrađenih taskova mi se cinilo da bi mogao smanjiti prompt i malo ga automatizirati pa sam odlucio napraviti playbook/storybook po kojem ce agent raditi.
Ovime si ubrzavamo rad po taskovima jer ne moramo detaljno strukturirati promptove i ove gore primjere sa radom na tasku.
Cilj je da se taj playbook radi po projektu tako da bi trebali izvrtiti ovaj prompt(prompt mozete doraditi po potrebi sami ili uz pomoc nekog od modela, koristeci cursor ili chatgpt, ili...) kako bi dobili playbook. Dovoljno je generičan i bilo bi dobro ako ga poboljšavate da si shareamo poboljšanja.
Prompt za generiranje project specific playbooka (moze se c/p u cursor):
You are an autonomous senior software architect, tech lead, and delivery manager.
Your task is to generate a SINGLE authoritative file for this repository:
CURSOR_PLAYBOOK.md
This playbook will be the ONLY operational instruction used for all future work.
After this file exists, the ONLY runtime instruction that will ever be given is:
"Follow CURSOR_PLAYBOOK.md and proceed with TASK-X."
You must therefore make the playbook STRICT, COMPLETE, EXPLICIT, and PRODUCTION-GRADE.
--------------------------------------------------------------------
MANDATORY CONTEXT — SOURCE OF TRUTH
--------------------------------------------------------------------
This repository already contains structured project knowledge.
You MUST read and treat the following files as authoritative inputs:
docs/
- project.md (scope, goals, architecture)
- tasks.md (all epics and tasks, dependencies)
- setup.md (development and production setup rules)
- decisions.md (architectural decision records / ADRs)
- data.md (data model, database rules, fixtures, environments)
memory-bank/
- context.md (domain language and meaning)
- conventions.md (coding standards, git discipline, naming)
- state.md (current progress and active task)
- changelog.md (historical changes)
Assumptions you MUST make:
- These files already exist
- They are authoritative
- You MUST explain HOW and WHEN each one is used
- You MUST NOT invent or hallucinate their contents
- If a required file is missing or empty, you MUST STOP and report it
--------------------------------------------------------------------
REQUIRED STRUCTURE OF CURSOR_PLAYBOOK.md
--------------------------------------------------------------------
The playbook MUST contain the following sections IN THIS EXACT ORDER:
1. Purpose of the Playbook
2. Source-of-Truth Hierarchy
3. Global Execution Rules (Non-Negotiable)
4. How Cursor Must Use docs/
5. How Cursor Must Use memory-bank/
6. Task Execution Protocol (MANDATORY)
7. Standard Task Prompt Template
8. Per-Epic Completion Protocol
9. Tracking & Documentation Discipline
10. Multi-Developer Safety Rules
11. Failure Handling
12. Post-Task Retrospective Rules
13. Continuous Improvement Mode (CIM)
14. Final Operating Contract
NO sections may be omitted, merged, or reordered.
--------------------------------------------------------------------
CRITICAL PRECEDENCE RULE
--------------------------------------------------------------------
When rules conflict, the following precedence ALWAYS applies:
1. Continuous Improvement Mode (CIM)
2. Task Execution Protocol
3. Post-Task Retrospective Rules
4. Tracking & Documentation Discipline
--------------------------------------------------------------------
POST-TASK RETROSPECTIVE RULES (MANDATORY SECTION)
--------------------------------------------------------------------
The Playbook MUST include a first-class section titled:
"Post-Task Retrospective Rules"
Rules:
- A retrospective is POLICY-MANDATORY but EXECUTION-EXPLICIT
- Cursor MUST NOT auto-run retrospectives
- The retrospective runs ONLY when the user explicitly writes:
- "Run Post-Task Retrospective"
- or "Retrospective for TASK-x.y"
During the retrospective, Cursor MUST:
- Review the entire conversation of the completed task
- Identify mistakes, risky assumptions, user corrections, and repeated patterns
- Categorize findings into:
- Execution Issues
- Process Issues
- Tooling Issues
- Documentation Gaps
- Behavioral Issues
- Propose PREVENTIVE RULES for each finding
- Specify WHERE each rule belongs:
- CURSOR_PLAYBOOK.md
- docs/decisions.md
- docs/conventions.md
- docs/data.md
Safety rules:
- Cursor MUST NOT modify any files during retrospectives
- Cursor MUST WAIT for explicit user approval before applying any change
- Cursor MUST output copy-paste-ready rule text
--------------------------------------------------------------------
CONTINUOUS IMPROVEMENT MODE (CIM) — MANDATORY SECTION
--------------------------------------------------------------------
The Playbook MUST include a section titled:
"Continuous Improvement Mode (CIM)"
This is a FORMAL EXECUTION MODE that OVERRIDES ALL NORMAL TASK EXECUTION.
CIM MUST include:
1. Definition
- CIM exists to capture critical mistakes or undesired behavior
- CIM IMMEDIATELY PAUSES task execution
2. Trigger Conditions
CIM is activated immediately when the user writes ANY of:
- "STOP."
- "This behavior is not acceptable."
- "Switch to Continuous Improvement mode."
- "Behavior issue."
- "This must not happen again."
3. Immediate Effects
Upon activation, Cursor MUST:
- Stop all task execution immediately
- Not modify code, configuration, or documentation
- Acknowledge execution is paused due to CIM
4. Analysis Responsibilities
Cursor MUST analyze:
- The exact problematic behavior
- Its category (behavioral, procedural, technical, tooling, documentation)
5. Rule Extraction and Proposal
For each issue, Cursor MUST propose:
- An enforceable rule
- Rule type: HARD or SOFT
- Destination file:
- CURSOR_PLAYBOOK.md
- docs/conventions.md
- docs/decisions.md
- docs/data.md
6. User Approval Requirement
- Cursor MUST WAIT for explicit approval
- Partial approval, modification, or rejection MUST be supported
- NO rule may be applied without confirmation
7. Exit Conditions
CIM ends ONLY when the user writes:
- "Exit Continuous Improvement mode"
- or "Resume TASK-x.y"
Upon exit, Cursor MUST:
- Reload task context
- Re-evaluate scope before resuming
8. Enforcement
- Approved rules are binding
- Repeated violation is a critical failure
--------------------------------------------------------------------
OUTPUT CONSTRAINTS
--------------------------------------------------------------------
- Output ONLY the contents of CURSOR_PLAYBOOK.md
- Do NOT include explanations or summaries
- Do NOT add markdown outside the file
- First line MUST be "# CURSOR_PLAYBOOK"
- Last line MUST be end-of-file (no commentary)
Generate the file now.
Ovime ste dobili da mozete raditi task po task sa ovim promptom:
Follow CURSOR_PLAYBOOK.md.
Proceed with TASK-0.11.
Moj savjet je pustiti ga da odradi task i nakon toga provjera sta je napravio i testiranje i ako primjetite da treba manje izmjene onda ih ili rucno ili sa dodatnim promptom izmjeniti.
Ukoliko je fulao poprilicno onda undo prompta i ponovite prompt ali nadodate par smjernica kako bi mu bilo lakse odraditi bez istih grešaka. Probao sam ici i sa promptanjem dok ne rijesim problem ali mi je undo nekako čišći i brže sam došao do cilja.
Mozete koristiti "Cycle agents count opciju u cursoru - nalazi se desno od modela" ona vam paralelno izvrsi prompt onoliko puta koliko joj zadate i mozete kombinirati sa razlicitim modelima pa provjeriti svako rjesenje zasebno i ostaviti ono koje vam je najbolje - to za kompleksnije taskove nije losa opcija
Ovaj projekt koristi Cursor Playbook kao jedini operativni ugovor između tebe i LLM-a (Cursora).
Nakon što postoji CURSOR_PLAYBOOK.md, nema više “ručnih” ili improviziranih promptova po taskovima.
Tvoja jedina operativna naredba postaje:
Follow CURSOR_PLAYBOOK.md.
Proceed with TASK-X.Y.
Sve ostalo (čitanje dokumentacije, pravila, validacije, update tracking datoteka) Cursor mora odraditi sam — striktno po Playbooku.
Sustav ima tri jasno odvojena moda rada:
Svrha:
Implementacija točno jednog taska (npr. TASK-0.11) na produkcijski ispravan način.
Kako se aktivira:
Follow CURSOR_PLAYBOOK.md.
Proceed with TASK-0.11.
Što Cursor radi:
- Čita
docs/tasks.md,docs/project.md,docs/setup.md - Provjerava ovisnosti i scope
- Implementira task
- Validira rezultat
- Zaustavlja se kada je task završen
Što Cursor NE radi:
- Ne mijenja arhitekturu
- Ne dodaje “bonus” feature
- Ne ažurira Playbook
- Ne nagađa
Svrha:
Zaustaviti Cursor usred taska kada primijetiš krivo ponašanje i pretvoriti to u trajna pravila.
Tipični razlozi:
- Cursor pokušava instalirati paket koji ne želiš
- Izvršava krive naredbe
- Krši dogovorena pravila
- Donosi krive pretpostavke
Trigger (upišeš doslovno):
STOP.
This behavior is not acceptable.
Switch to Continuous Improvement mode.
Što se tada događa:
- Cursor odmah STANE
- Ne mijenja ništa u kodu
- Analizira što je pošlo krivo
- Predlaže nova pravila
- Čeka tvoje odobrenje
Bitno:
CIM ne popravlja task — on popravlja ponašanje Cursora za budućnost.
Svrha:
Nakon završetka taska, izvući pouke iz cijelog rada.
Kako se pokreće:
Run Post-Task Retrospective
ili
Retrospective for TASK-0.11
Što Cursor radi:
- Pregleda cijeli chat za taj task
- Traži:
- greške
- ručne ispravke
- ponavljajuće probleme
- Predlaže preventivna pravila
Što Cursor NE radi:
- Ne mijenja nijedan file
- Ne primjenjuje pravila bez tvog odobrenja
| Situacija | Koristi |
|---|---|
| Problem vidiš usred taska | CIM |
| Task je gotov, ali vidiš pattern | PTR |
| Cursor radi nešto opasno | CIM |
| Cursor je radio OK, ali može bolje | PTR |
Pravilo:
CIM = hitno kočenje
PTR = strateško učenje
- Ti napišeš:
Follow CURSOR_PLAYBOOK.md.
Proceed with TASK-0.11.
-
Cursor radi task po pravilima
-
Ako vidiš problem → aktiviraš CIM
-
Task se završi
-
Pokreneš PTR:
Run Post-Task Retrospective
-
Odobriš (ili odbiješ) nova pravila
-
Cursor nastavlja dalje "pametniji" nego prije - to je plan
Trigeri za pokretanje/aktivaciju CIM mode-a:
- "STOP."
- "This behavior is not acceptable."
- "Switch to Continuous Improvement mode."
- "Behavior issue."
- "This must not happen again."
Trigeri za izlaz iz CIM mode-a:
- "Exit Continuous Improvement mode"
- or "Resume TASK-x.y"
Triger za pokretanje CTR-a:
- "Run Post-Task Retrospective"
- or "Retrospective for TASK-x.y"
- Task = isporuka
- CIM = korekcija ponašanja
- PTR = dugoročno učenje
Ne gomilaš ručne promptove po taskovima — Playbook je jedini izvor istine.
- Radi za 1 developera
- Radi za 5 developera
- Radi za godinu dana
Ne samo da piše kod, nego:
- uči pravila projekta
- poštuje granice
- ponavlja dobre obrasce
Ako postoji CURSOR_PLAYBOOK.md:
Nikada ne objašnjavaj task iznova.
Samo reci:
Follow CURSOR_PLAYBOOK.md.
Proceed with TASK-X.
Sve ostalo je greška u Playbooku — i rješava se kroz CIM ili PTR, a ne kroz ad-hoc promptove.