| name | elizaos |
| description | End-to-end ElizaOS development, debugging, and operations for the LTCG monorepo. Use when working on ElizaOS agents, character files, plugin architecture (actions/providers/evaluators/services/routes), runtime settings, Convex-backed agent APIs, or agent docs in this repository. |
ElizaOS (LTCG Monorepo)
Overview
Use this skill for all ElizaOS work in this repository, including:
- Plugin development in
packages/plugin-ltcg
- Character and runtime configuration in
packages/plugin-ltcg/src/character.ts and packages/plugin-ltcg/src/characters/*.ts
- Agent API integration in
convex/http/*.ts
- Agent docs in
apps/docs-agents/src/content/docs
- Runtime debugging, validation, and testing for ElizaOS agent behavior
Source Priority
Use this order to resolve uncertainty:
- Repository implementation (highest priority for this codebase)
- Official ElizaOS docs via Context7 (
/elizaos/docs)
- DeepWiki ElizaOS pages for orientation and discovery, then verify against 1 and 2
Do not rely on DeepWiki alone for behavioral guarantees.
Load-Only-What-You-Need References
- For official CLI, character format, and plugin interface patterns: read
references/official-elizaos.md.
- For repository file map, endpoint map, and environment variable map: read
references/ltcg-elizaos-monorepo.md.
- For concrete implementation procedures and checklists: read
references/playbooks.md.
Workflow
1) Classify the request
Map the request into one primary lane:
- Character/runtime lane: personality, model/provider, secrets/settings, startup behavior
- Plugin lane: actions/providers/evaluators/services/routes/client wiring
- API lane: agent registration, matchmaking, game actions, story/chat/deck endpoints
- Docs lane:
apps/docs-agents updates
- Ops lane: debugging, testing, release hardening
2) Locate the implementation surface
Use rg and file maps from references/ltcg-elizaos-monorepo.md to find exact touch points before editing.
3) Apply the smallest coherent change
- Keep changes scoped to the selected lane.
- Reuse existing patterns already used in
packages/plugin-ltcg/src.
- Preserve established naming and component registration conventions.
4) Verify at the right level
Choose the smallest effective validation set:
- Plugin-only checks in
packages/plugin-ltcg
- Repo-level type/tests only when the change crosses package boundaries
- Endpoint checks when touching
convex/http
5) Update docs when behavior changes
If runtime behavior, configuration, or API shape changes, update docs in apps/docs-agents/src/content/docs.
6) Update engineering memory
Before and after substantial work, use the repo memory loop:
bun run eng:start
bun run eng:log -- observation "<title>" "<details>"
If a wrong assumption or error occurred, log it with prevention:
bun run eng:log -- mistake "<title>" "<what went wrong>" "<prevention rule>"
Guardrails
- Keep ElizaOS plugin registration coherent: if adding a component, wire it through the corresponding index and plugin export.
- Never hardcode secrets. Read via runtime/environment settings.
- Keep
LTCG_API_KEY validation semantics intact (ltcg_ prefix) unless a deliberate migration is required.
- For HTTP endpoints under
convex/http, preserve auth wrapper choice (httpAction vs authHttpAction) intentionally.
- When adding settings, update config schema and defaults together.
- When adding API routes, ensure client constants and client methods stay aligned.
Quick Commands
Use these first:
bun run dev:all
bun run type-check
cd packages/plugin-ltcg
bun run dev
bun run start
bun run type-check
bun run test
bun run check-all
Completion Criteria
Consider work complete only when:
- Code changes are wired through all required registries and exports.
- Runtime/config/API compatibility is validated at least once.
- Agent docs are updated if user-facing behavior changed.
- No unresolved TODOs or partial wiring remain.
