|
| 1 | +# CLAUDE.md |
| 2 | + |
| 3 | +This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository. |
| 4 | + |
| 5 | +> **Context Optimization**: This file is structured for efficient agent usage. The "Agent Routing" section defines what context each agent needs. When spawning subagents, pass only relevant sections—not the entire file. Sections marked `<!-- reference -->` are lookup tables; don't include them in agent prompts unless specifically needed. |
| 6 | +
|
| 7 | + |
| 8 | +## Agent Routing |
| 9 | + |
| 10 | +**MANDATORY: All implementation work MUST be performed by subagents.** Never directly edit code, configuration, or documentation in the parent conversation. Instead, always delegate to the appropriate specialized agent from the table below. The parent conversation should only coordinate agents, pass context between them, and communicate results to the user. |
| 11 | + |
| 12 | +Do NOT ask the user which agent to use - pick the appropriate one based on what files or features are being modified. |
| 13 | + |
| 14 | +| Task Type | Agent | When to Use | |
| 15 | +|-----------|-------|-------------| |
| 16 | +| UI/Frontend | `datum-platform:frontend-dev` | React, TypeScript, CSS, anything in `ui/` directory | |
| 17 | +| Go Backend | `datum-platform:api-dev` | Go code in `cmd/`, `internal/`, `pkg/` directories | |
| 18 | +| Infrastructure | `datum-platform:sre` | Kustomize, Dockerfile, CI/CD, `config/` directory, `.infra/` for deployment | |
| 19 | +| Tests | `datum-platform:test-engineer` | Writing or fixing Go tests | |
| 20 | +| Code Review | `datum-platform:code-reviewer` | After implementation, before committing | |
| 21 | +| Documentation | `datum-platform:tech-writer` | README, docs/, guides, API documentation | |
| 22 | +| Architecture | `Plan` | Designing new features or significant refactors | |
| 23 | +| Exploration | `Explore` | Understanding codebase structure or finding code | |
| 24 | + |
| 25 | +**Key principles:** |
| 26 | +- **Always use subagents** — never write code, edit files, or run build/test commands directly in the parent conversation |
| 27 | +- Use agents proactively without being asked |
| 28 | +- For multi-step tasks, use the appropriate agent for each step (launch independent agents in parallel when possible) |
| 29 | +- After making code changes, always use `code-reviewer` to validate |
| 30 | +- For UI changes, run `npm run build` and `npm run test:e2e` to verify |
| 31 | +- **Always test infrastructure changes in a test environment before opening a PR** - Deploy to the test-infra KIND cluster (`task test-infra:cluster-up`) and verify resources work correctly before pushing changes to staging/production repos |
| 32 | +- **Use Telepresence for debugging staging issues** - When investigating bugs that only reproduce in staging, intercept the service and run it locally with `task test-infra:telepresence:intercept SERVICE=<name>`. See "Remote Debugging with Telepresence" section. |
| 33 | + |
| 34 | +### Agent Context Requirements |
| 35 | + |
| 36 | +Each agent only needs specific context. When spawning agents, pass minimal relevant info in prompts—don't repeat the entire CLAUDE.md: |
| 37 | + |
| 38 | +| Agent | Required Context | Skip (don't include in prompt) | |
| 39 | +|-------|-----------------|--------------------------------| |
| 40 | +| `frontend-dev` | UI commands, file paths in `ui/` | Go architecture, ClickHouse, NATS, data pipeline | |
| 41 | +| `api-dev` | Go patterns, API resource types, key directories | UI commands, dev environment setup, migrations | |
| 42 | +| `sre` | Config structure, build commands, deployment | Code architecture details, CEL patterns | |
| 43 | +| `test-engineer` | Test commands, package being tested | Full architecture, deployment, UI | |
| 44 | +| `Explore` | Key directories, architecture overview | Build commands, dev setup, deployment | |
| 45 | +| `code-reviewer` | Architecture, multi-tenancy model, conventions | Dev environment, build commands | |
| 46 | +| `tech-writer` | API resources, architecture overview | Implementation details, build commands | |
| 47 | + |
| 48 | +### Agent Output Guidelines |
| 49 | + |
| 50 | +Agents should return **concise summaries** to minimize context bloat in the parent conversation: |
| 51 | + |
| 52 | +| Agent | Return | Don't Return | |
| 53 | +|-------|--------|--------------| |
| 54 | +| `Explore` | File paths + 1-line descriptions | Full file contents, extensive code quotes | |
| 55 | +| `api-dev` | What was changed + file paths | Full diffs, unchanged code | |
| 56 | +| `frontend-dev` | Components modified + any build errors | Full file contents | |
| 57 | +| `code-reviewer` | Numbered findings list with file:line refs | Full code blocks for context | |
| 58 | +| `test-engineer` | Pass/fail summary + failure messages only | Full test output, passing test details | |
| 59 | +| `sre` | Changed manifests + deployment notes | Full YAML contents | |
| 60 | + |
| 61 | +### Multi-Step Task Decomposition |
| 62 | + |
| 63 | +For complex tasks, decompose to minimize per-agent context: |
| 64 | + |
| 65 | +1. **Explore first** (use `model: "haiku"`): Find relevant files → return only paths |
| 66 | +2. **Plan if needed**: Design approach → return bullet points only |
| 67 | +3. **Implement** (sonnet): Work on specific files identified in step 1 |
| 68 | +4. **Review**: Check only the changed files |
| 69 | + |
| 70 | +**Critical**: Pass only what's needed between steps. Don't re-explore what's already known. |
0 commit comments