context-engineering

# Context Engineering Feed the agent the right information at the right time. Too little context causes invented APIs; too much context hides the relevant pattern. ## Context Order 1. **Rules:** root `AGENTS.md`, scoped `AGENTS.md`, and any invoked skills. 2. **Specifications and delivery:** the owning system `README.md`, relevant requirements, system designs, ADRs, `plan.md`, and the current work order. 3. **Source:** exact files to modify, related tests, and one similar implementation. 4. **Evidence:** focused error output, failing test name, CI summary, screenshots, or logs. 5. **Conversation:** current user request and any confirmed decisions. ## Kandev Loading Checklist Before running shell commands, resolve every `@path` import in the root or scoped `AGENTS.md`/`CLAUDE.md` files and read the referenced instructions. If an imported file is unavailable, note the missing guidance and continue with the best available local instructions. Before changing code: - Read the scoped `AGENTS.md` for the subtree you will touch, e.g. `apps/backend/AGENTS.md`, `apps/web/AGENTS.md`, or integration-specific guidance. - Use `rg` to find existing patterns before inventing one. - Read the file you will edit and nearby tests. - For product features, read `docs/specs/README.md`, the owning system index, adjacent indexes with similar capability names, and only the relevant requirement and system-design files. Choose the owner from the durable contract, not the affected code lay...