Son dönemde uzun soluklu bir yazılım projesinde Codex kullanırken en çok uğraştığım konu gereksiz context, tekrar eden terminal çıktıları, büyük büyük görevler ve yeniden keşif ciddi kullanım tüketti. En son 20x kullanırken 4. gün bitince şöyle bi çözüm buldum ve paylaşmak istedim.
Bir süre farklı yöntemleri deneyince benim için en sağlıklı yapı şu oldu:
AGENTS.md + Nested AGENTS.md + Skills + RTK
Özellikle RTK'yı kesinlikle deneyin derim.
RTK
https://github.com/rtk-ai/rtk
Codex’in git diff, test, lint, TypeScript, Docker logları gibi terminal komutlarından okuduğu gereksiz uzun çıktıları sıkıştırıyor. Böylece modele daha az terminal gürültüsü/context taşınıyor.
RTK kendi ölçümünde desteklenen bazı shell komutlarının çıktısını ciddi oranda azaltabiliyor. Özellikle büyük repo, test ve build çıktılarında context tüketimini azaltmaya yardımcı oluyor.
Global AGENTS.md şablonu
Benim kullandığım genel mantığın sadeleştirilmiş hali:
# Global Codex Guidance ## Core behavior - Prefer the smallest safe change that fully solves the task. - Preserve existing architecture, style, conventions, and unrelated user work. - Do not invent requirements, APIs, permissions, states, or product semantics. - Fail clearly instead of hiding invalid state behind silent fallbacks. - Never leave empty catch blocks. - Never expose or print secrets. - Never force-push, rewrite published history, or discard unrelated work. ## Engineering - Prefer small, cohesive modules. - Treat roughly 300 lines of executable code as a review signal, not a hard limit. - Split files only when there is a real responsibility boundary. - Design for known near-term requirements, not hypothetical future flexibility. - Keep stable entrypoints and isolate volatile logic. - Prefer existing dependencies and platform capabilities before adding new ones. ## Execution economy Default task size: one mutation OR one narrow feature → implementation → focused validation → at most one narrow candidate-owned fix → exact-scope commit → normal push → STOP - Do not split implementation, tests, and Git checkpoint into separate tasks unless safety requires it. - Do not combine multiple independent mutations or authority families into one task. - Batch related reads and Git inspection. - Do not repeatedly reread unchanged files. - Do not repeatedly rerun passing tests. - Do not poll CI after every intermediate commit. - Prefer one blocking long-running command over repeated status polling. - Return one concise final report unless blocked. ## Validation During normal feature work prefer: - focused tests - focused lint/format - relevant typecheck/build - git diff --check Full suite, browser QA, CI, critic review, and release validation belong to release/final-validation milestones. After a focused failure: - allow at most one narrow candidate-owned fix pass; - rerun the smallest affected test subset. ## UI Design UI for the end user, not for the backend schema. Use verifiable requirements instead of vague goals. ## RTK When RTK is installed, prefer it for noisy shell output such as: - git status/diff/log - tests - lint - typecheck/build - Docker/logs - GitHub CLI reads Use raw commands when exact unfiltered output is required for correctness, hashing, provenance, security validation, or debuggingRepo AGENTS.md
# Backend This repository is the server-side semantic authority. ## Map - Current backend code and tests are authoritative. - Shared API contracts are the public interface. - Backend-local DTOs are not automatically public contracts. - Frontend convenience must not force backend semantic changes. ## Invariants Preserve: - authorization - idempotency - concurrency/CAS - data integrity - auditability - migration history Never hide ambiguous state behind successful fallbacks. ## Git - Preserve unrelated work. - Use narrow feature branches/worktrees. - No force push or history rewrite. ## Validation Use focused backend tests during implementation. Run broad regression and database tests at release checkpoints. Frontend için ayrı nested AGENTS: # Frontend ## Frontend rules - Reuse the existing design system. - Reuse the current router/query/API infrastructure. - Do not create a second API client. - Keep loading, empty, unavailable, permission and error states distinct. - Do not expose raw backend errors. ## Mutation safety - Use exact shared schemas. - Respect permission plus capability/state. - Use exact CAS/version authority. - Honor idempotency metadata. - Prevent double-submit. - Do not optimistically invent server authority. ## UX - Design for the user, not the schema. - Prefer typed UI over arbitrary JSON editors. - Avoid horizontal overflow. - Preserve keyboard-accessible dialogs and forms. ## Testing Test frontend-risk behavior only. Do not duplicate schema tests already guaranteed by shared contracts.Skills
--- name: admin-mutation description: Implement one Admin mutation safely end-to-end. --- # Admin Mutation Use this skill for exactly one privileged mutation. ## Default flow one mutation → read exact authority once → implement → focused frontend-risk validation → at most one narrow fix → exact-scope commit → normal push → STOP ## Authority Resolve only what the mutation requires: - method / route - request / response - permission - capability/state - CSRF - idempotency - CAS/version - typed errors Do not invent public semantics. ## Safety - Permission alone is insufficient when capability/state exists. - Use exact server-owned CAS values. - Prevent double-submit. - Same confirmed intent must reuse the same idempotency key. - Never expose raw idempotency keys. - Stale conflicts require refreshed authority and a new explicit intent. - Malformed responses fail closed. ## Validation Use: - focused tests - focused lint/format - relevant typecheck - git diff --check Allow at most one narrow fix pass. ## Git If green: - exact-scope commit - normal push - verify clean worktree - STOP Do not poll CI after intermediate commits. Böylece prompt çok kısalabiliyor: Implement Adaptive Revision Review. Use repository AGENTS.md and the admin-mutation skill. Do not implement Publish or Rollback. Do not query CI. Stop after focused validation, exact-scope commit and normal push.Ben uzun projelerde şu tür skill’leri faydalı buluyorum:
admin-mutation contract-release backend-parity-pin postgres-regression release-critic postgres-regression disposable PostgreSQL → migration/regression → result → cleanup contract-release contract gap → strict schemas → registry → OpenAPI → focused tests → immutable version → provenance → commit release-critic Sadece final candidate aşamasında: clean candidate commit → read-only critic → consolidated findings → critical/high fix batch → max one recheck → final validationPromp Yapısı
Ana mantık
Bir prompt = bir mutation veya bir dar feature.
İdeal akış:
authority'yi bir kez oku → implement et → focused test → en fazla bir küçük fix → commit → push → STOP
Çok küçük görevler context'in sürekli yeniden kurulmasına, çok büyük görevler ise agent'ın fazla dallanmasına neden oluyor.
Bu yüzden en iyi denge genellikle:
tek, net, sınırları belli ve uçtan uca tamamlanabilir bir görev.
