AGENTS.md · eigent-ai/eigent

Sections

1. UI work
2. Product terminology
3. Validation

First lines (shown under the repo's Apache-2.0 license)

# Eigent Agent Instructions

## UI work

Before planning, generating, reviewing, or modifying any user-facing UI, read
`docs/design-system/design.md` completely. Treat it as the active product design
contract for all UI work in this repository.

Use `docs/design-system/index.html` as the visual reference. The Markdown
guideline remains authoritative when the two formats differ.

For UI implementation:

1. Inspect the nearest existing product surface for behavior and layout
   context.
2. Reuse primitives from `src/components/ui` before creating a new component.
3. Use the semantic tokens and supported component axes documented in the
   guideline.
4. Treat `src/style/tokens`, `src/style/generated`, and shared UI primitives as
   the executable source of truth. Never edit generated token files by hand.
5. Do not introduce raw colors, arbitrary standard-control geometry, stock
   shadows, new compatibility aliases, or local icon sizing when an approved
   semantic role or recipe exists.
6. When the design guideline and implementation disagree, inspect both and
   report the discrepancy instead of silently inventing a new rule.

Before handing off UI work, report the reused primitives, selected semantic
tokens or component axes, verified states and themes, any registered exception,
and the validation commands that passed or were not run.

## Product terminology

Before planning, generating, reviewing, or modifying user-facing terminology,
presentation component names, or presentation-oriented file and folder names,
read `docs/product-terminology.md` completely. Treat it as the authoritative
match between UI wording and the backend terms and identifiers that must remain
unchanged.

For terminology work:

1. Use the document's UI wording for visible copy, accessibility labels, and
   presentation-oriented names.
2. Preserve the matched backend/API/database terms, identifier values, routes,
   commands, event fields, translation keys, and persisted keys. Do not create
   new serialized aliases for a UI rename.
3. Classify presentation files and components by the surface they own: Space,
   Session, or shared. A Space-owned container may contain Session-named child
   components.
4. Inspect each occurrence at its presentation or compatibility boundary. Do
   not use an unrestricted search-and-replace across Product terms.
5. When terminology documentation and implementation disagree, inspect both
   and report the discrepancy instead of silently changing a frozen contract.

When a task changes both UI design and terminology, both
`docs/design-system/design.md` and `docs/product-terminology.md` are required
reading before work begins.

## Validation

Run checks in proportion to the UI change. The standard design-system checks
are documented in `docs/design-system/design.md`; at minimum, use focused tests,
type checking, and `git diff --check` when applicable.

For terminology changes, also follow the checklist in
`docs/product-terminology.md`. Search visible wording separately from technical
contracts, and run locale parity checks when localized copy changes.