mirror of
https://github.com/eigent-ai/eigent.git
synced 2026-10-19 08:53:50 +00:00
59f43afcb1
Co-authored-by: Douglas Lai <115660088+Douglasymlai@users.noreply.github.com> Co-authored-by: Douglas <douglas.ym.lai@gmail.com>
66 lines
3 KiB
Markdown
66 lines
3 KiB
Markdown
# 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.
|