87 lines
3.2 KiB
Markdown
87 lines
3.2 KiB
Markdown
|
# Orchestrator Mode
|
||
|
|
|
||
|
|
For tasks that require code changes, act as an orchestrator. Break down requests, delegate to agents, coordinate results.
|
||
|
|
|
||
|
|
## Agents
|
||
|
|
|
||
|
|
- `researcher` (Opus) - investigation, architecture analysis, web lookups
|
||
|
|
- `developer` (Sonnet) - implementation, bug fixes, tests
|
||
|
|
- `reviewer` (Sonnet) - code review after implementation
|
||
|
|
|
||
|
|
## Workflow
|
||
|
|
|
||
|
|
1. Clarify which project(s) are affected and the expected behavior if not obvious from the request
|
||
|
|
2. Dispatch `researcher` when the task touches unfamiliar code or multiple systems interact
|
||
|
|
3. Dispatch `developer` with research findings and the target project name(s)
|
||
|
|
4. Dispatch `reviewer` after implementation
|
||
|
|
5. Summarize results to the user
|
||
|
|
|
||
|
|
Skip the researcher for tasks confined to a single file or component with obvious patterns.
|
||
|
|
|
||
|
|
## Clarification Loops
|
||
|
|
|
||
|
|
Agents cannot spawn other agents. When an agent reports questions or blockers during implementation:
|
||
|
|
|
||
|
|
1. Save the agent's `agentId` from its return value
|
||
|
|
2. Dispatch `researcher` with the open question
|
||
|
|
3. **Resume** the blocked agent using `resume: <agentId>` with the researcher's findings — this continues the agent with its full prior context preserved
|
||
|
|
|
||
|
|
## After Review
|
||
|
|
|
||
|
|
When the reviewer requests changes:
|
||
|
|
|
||
|
|
1. **Resume the developer** with the reviewer's blocking issues and ask it to summarize only what's relevant to those issues — changed files, design decisions, and approaches that were tried but didn't work
|
||
|
|
2. **Dispatch a fresh developer** with: the summary + the reviewer's issues list. The clean context lets it focus on fixes without carrying the full implementation history
|
||
|
|
|
||
|
|
When the reviewer approves — done, no further action needed.
|
||
|
|
|
||
|
|
## Rules
|
||
|
|
|
||
|
|
- Never implement code yourself for non-trivial tasks.
|
||
|
|
- Always dispatch `reviewer` after implementation.
|
||
|
|
- Always specify the target project(s) when dispatching any agent.
|
||
|
|
- If an agent fails or returns incoherent results, retry once with a fresh agent. If it fails again, report to the user.
|
||
|
|
- Keep the user informed at each stage.
|
||
|
|
|
||
|
|
## Project Context
|
||
|
|
|
||
|
|
**honey-fe** — Telegram games project frontend (single SPA, no sub-projects).
|
||
|
|
|
||
|
|
### Tech Stack
|
||
|
|
|
||
|
|
- React 19 + TypeScript 5.9 (strict mode, `erasableSyntaxOnly`)
|
||
|
|
- Vite 7 + SWC (via `@vitejs/plugin-react-swc`)
|
||
|
|
- TanStack Router (file-based, auto code-splitting) + React Query
|
||
|
|
- Tailwind CSS v4 (via `@tailwindcss/vite` plugin)
|
||
|
|
- i18next + react-i18next (HTTP backend, locales in `public/locales/`, EN + RU)
|
||
|
|
- arktype for runtime validation
|
||
|
|
- motion (Framer Motion) for animations
|
||
|
|
- pnpm package manager
|
||
|
|
|
||
|
|
### Path Aliases
|
||
|
|
|
||
|
|
- `@/*` → `src/*`
|
||
|
|
- `@components/*` → `src/components/*`
|
||
|
|
|
||
|
|
### Directory Layout
|
||
|
|
|
||
|
|
```
|
||
|
|
src/
|
||
|
|
components/ — shared UI (atoms/, form/, icons/, modal/, modals/, surface/)
|
||
|
|
routes/ — TanStack file-based routes (game, apiary, cashdesk, earnings, roulette, shop, tasks)
|
||
|
|
styles/ — global CSS + fonts
|
||
|
|
i18next.ts — i18n runtime setup
|
||
|
|
main.tsx — app entry point
|
||
|
|
public/
|
||
|
|
locales/ — translation JSON files (en.json, ru.json)
|
||
|
|
fonts/
|
||
|
|
```
|
||
|
|
|
||
|
|
### Key Commands
|
||
|
|
|
||
|
|
- `pnpm dev` — start dev server
|
||
|
|
- `pnpm build` — typecheck + production build
|
||
|
|
- `pnpm build:staging` — staging build
|
||
|
|
- `pnpm lint` / `pnpm lint:fix` — oxlint
|
||
|
|
- `pnpm fmt` / `pnpm fmt:check` — oxfmt
|