Skip to content

AGENTS.md

Latest commit

 

History

History
66 lines (52 loc) · 3.04 KB

AGENTS.md

File metadata and controls

66 lines (52 loc) · 3.04 KB
Raw

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.