Jido Core
Purpose
Load shared Jido ecosystem context before making package-specific decisions.
This skill is the hub for Jido framework work.
When To Use
Use this skill when working with:
- Jido agents, actions, directives, plugins, sensors, or signals
- Jido package docs or examples
- Jido AI integration
- Tests for Jido actions or agents
- Cross-package conventions in AgentJido repos
Requirements
- Inspect the local repo before applying examples.
- Read local
AGENTS.md, mix.exs, and nearby modules first.
- Prefer local APIs and conventions over examples in this skill when they
differ.
Ecosystem Map
Common package roles:
| Package |
Role |
jido |
Core agent framework, agent state, directives, runtime concepts |
jido_action |
Validated action behavior and execution building blocks |
jido_signal |
Signal model and routing concepts |
jido_ai |
AI agent integration and skill/tool prompt composition |
req_llm |
LLM provider HTTP client and request layer |
jido_* packages |
Domain-specific adapters, runtimes, tools, or examples |
Do not assume every repo depends on every package. Confirm with mix.exs.
Core Principles
- Agents model state and command handling.
- Actions encapsulate focused behavior behind validated inputs and explicit
return values.
- Side effects should happen at documented runtime boundaries, not hidden in
pure decision code.
- Signals are the cross-boundary message format when a package uses the signal
runtime.
- Zoi-first schemas are preferred for new code when the repo supports them;
preserve existing NimbleOptions patterns in older code unless migration is in
scope.
- Tests should prove behavior first and runtime wiring second.
Workflow
Read the repo-local guidance:
sed -n '1,220p' AGENTS.md 2>/dev/null || true
sed -n '1,220p' mix.exs
Identify package role from mix.exs, modules under lib/, and existing
tests.
Choose the narrower skill:
jido-agent for agent modules and runtime behaviorjido-action for action modules and action schemasjido-ai for LLM, tools, and AI agent integrationjido-testing for test strategy
Follow existing repo patterns unless they conflict with current user intent
or documented project standards.
Validate with repo-local commands. Prefer documented aliases; otherwise use
mix test and focused compile checks.
Output Expectations
When using this skill to guide work, report:
- Which local repo conventions were found
- Which Jido package role applies
- Which narrower skill was used next
- Which validation command proves the change
Guardrails
- Do not paste large API references into responses; load reference files only
when needed.
- Do not force Zoi migration into unrelated work.
- Do not introduce new runtime patterns without checking existing modules.
- Do not assume release, docs, or CI commands exist across all repos.
Reference Docs
Load these only when needed:
reference/agents.md for agent definition, schema, cmd/2, plugins, and
runtime conceptsreference/actions.md for action behavior, run/2, validation, and
compositionreference/directives.md for directive types and runtime processing
1---2name: jido-core3description: Provide Jido ecosystem context, package roles, conventions, and foundational patterns. Use before Jido agent, action, AI, testing, docs, or package work when the local repo needs shared Jido guidance.4license: Apache-2.05---67# Jido Core89## Purpose1011Load shared Jido ecosystem context before making package-specific decisions.12This skill is the hub for Jido framework work.1314## When To Use1516Use this skill when working with:1718- Jido agents, actions, directives, plugins, sensors, or signals19- Jido package docs or examples20- Jido AI integration21- Tests for Jido actions or agents22- Cross-package conventions in AgentJido repos2324## Requirements2526- Inspect the local repo before applying examples.27- Read local `AGENTS.md`, `mix.exs`, and nearby modules first.28- Prefer local APIs and conventions over examples in this skill when they29 differ.3031## Ecosystem Map3233Common package roles:3435| Package | Role |36| --- | --- |37| `jido` | Core agent framework, agent state, directives, runtime concepts |38| `jido_action` | Validated action behavior and execution building blocks |39| `jido_signal` | Signal model and routing concepts |40| `jido_ai` | AI agent integration and skill/tool prompt composition |41| `req_llm` | LLM provider HTTP client and request layer |42| `jido_*` packages | Domain-specific adapters, runtimes, tools, or examples |4344Do not assume every repo depends on every package. Confirm with `mix.exs`.4546## Core Principles4748- Agents model state and command handling.49- Actions encapsulate focused behavior behind validated inputs and explicit50 return values.51- Side effects should happen at documented runtime boundaries, not hidden in52 pure decision code.53- Signals are the cross-boundary message format when a package uses the signal54 runtime.55- Zoi-first schemas are preferred for new code when the repo supports them;56 preserve existing NimbleOptions patterns in older code unless migration is in57 scope.58- Tests should prove behavior first and runtime wiring second.5960## Workflow61621. Read the repo-local guidance:6364 ```bash65 sed -n '1,220p' AGENTS.md 2>/dev/null || true66 sed -n '1,220p' mix.exs67 ```68692. Identify package role from `mix.exs`, modules under `lib/`, and existing70 tests.71723. Choose the narrower skill:7374 - `jido-agent` for agent modules and runtime behavior75 - `jido-action` for action modules and action schemas76 - `jido-ai` for LLM, tools, and AI agent integration77 - `jido-testing` for test strategy78794. Follow existing repo patterns unless they conflict with current user intent80 or documented project standards.81825. Validate with repo-local commands. Prefer documented aliases; otherwise use83 `mix test` and focused compile checks.8485## Output Expectations8687When using this skill to guide work, report:8889- Which local repo conventions were found90- Which Jido package role applies91- Which narrower skill was used next92- Which validation command proves the change9394## Guardrails9596- Do not paste large API references into responses; load reference files only97 when needed.98- Do not force Zoi migration into unrelated work.99- Do not introduce new runtime patterns without checking existing modules.100- Do not assume release, docs, or CI commands exist across all repos.101102## Reference Docs103104Load these only when needed:105106- `reference/agents.md` for agent definition, schema, `cmd/2`, plugins, and107 runtime concepts108- `reference/actions.md` for action behavior, `run/2`, validation, and109 composition110- `reference/directives.md` for directive types and runtime processing
agentjido