# Codex Prompt Templates for Box Monorepo

## 1. General Feature Implementation (Backend, NestJS, TypeScript)

**Use this when adding a new feature.**

> You are working in the `box-nestjs-monorepo` project (NestJS + TypeScript).
> Read and respect the project docs in `docs/`:
>
> - ARCHITECTURE.md
> - SYSTEM_OVERVIEW.md
> - API_FLOW_DIAGRAMS.md
> - DEVELOPMENT_CHECKLIST.md
> - DEPLOYMENT_GUIDE.md
> - CODEX_ONBOARDING.md
>
> Task:
>
> 1. Summarize the relevant architecture and flows for this task.
> 2. Propose the NestJS module/controller/service/DTO design in a bullet list.
> 3. After that, ask me if I am ready for TypeScript code.
>
> Requirements:
>
> - Use **TypeScript only**.
> - Follow existing folder structures under `apps/` and `libs/`.
> - Use Redis/Mongo/MySQL access patterns already present in the codebase, unless you explicitly propose a better one.
> - Maintain backward compatibility with existing APIs and DTOs where possible.
> - Keep date/time fields as **BigInt epoch** values in the data layer (as per project rules).
>
> Task details:
> [Describe the feature here, e.g. “Implement auto-registration of users by device_code in box-app-api, including MySQL schema changes and service logic.”]

---

## 2. Refactor / Cleanup Prompt

> You are refactoring existing code in `box-nestjs-monorepo`.
> First:
>
> 1. Inspect the current implementation and summarize what it does.
> 2. Identify risks of breaking changes.
> 3. Propose a safer refactor plan (steps).
> 4. Only then, after I confirm, generate TypeScript changes.
>
> Rules:
>
> - Do **not** rename public APIs or DTO fields unless necessary and explicitly agreed.
> - Preserve external behavior.
> - Improve readability, testability, and consistency with patterns in `libs/common` and `libs/core`.

---

## 3. Docs-Driven Implementation Prompt

> Use `docs/ARCHITECTURE.md`, `docs/SYSTEM_OVERVIEW.md`, and `docs/API_FLOW_DIAGRAMS.md` as the source of truth.
> I want you to:
>
> 1. Read those docs.
> 2. Explain how the requested feature fits into the architecture.
> 3. List the affected files/modules (existing and new).
> 4. Propose a small, incremental implementation plan (1–3 PRs).
> 5. Only after I confirm, start generating TypeScript code.
>
> Feature:
> [Describe feature here]