Jido AI

Jido AI

Purpose

Add or maintain AI behavior in Jido projects without hardcoding provider, model, or dependency assumptions that may be stale.

When To Use

Use this skill for:

• LLM provider configuration
• Model aliases or defaults
• AI agent modules
• Tool calling with Jido actions
• Structured output or streaming
• Prompt or skill composition
• req_llm integration work

Invoke jido-core first for shared ecosystem context.

Requirements

• Inspect local mix.exs, config files, runtime config, and existing AI modules before adding examples.
• Do not hardcode model names unless the repo already does or the user requests a specific model.
• Treat API keys and provider secrets as environment/runtime configuration, not source-controlled values.

Workflow

1. Inspect local AI setup

Run targeted searches:

rg "jido_ai|req_llm|model_alias|generate_text|generate_object|stream_text|tool" mix.exs config lib test

Record:

• Dependencies already present
• Provider config style
• Model alias conventions
• Existing AI agent modules
• Tool registration pattern
• Test support or provider mocking strategy

2. Choose the smallest integration

Pick the narrowest fit:

• Generation facade for one-off text, structured data, or streaming
• AI agent module for ongoing stateful behavior
• Action-as-tool integration for model-callable operations
• Prompt/skill composition for reusable model instructions

Do not introduce a full agent runtime for a simple provider call.

3. Configure providers safely

Use existing config conventions. Store secrets in environment variables or the repo's secret-management layer. Prefer semantic model aliases when the repo has them, but do not invent alias policy without local precedent.

4. Add tool calling carefully

When exposing tools:

• Prefer existing Jido actions with clear schemas
• Keep tool names model-readable and stable
• Validate inputs at the action boundary
• Restrict tools to the request or agent scope that actually needs them
• Add tests for tool selection or tool schema when behavior is user-facing

5. Handle errors and limits

Plan for:

• Provider authentication failures
• Rate limits
• Timeout and retry policy
• Invalid model output
• Partial streaming results
• Tool-call failures

Return or surface errors in the style the repo already uses.

6. Validate

Run focused tests that do not require live provider credentials when possible. Use mocks, bypasses, fixtures, or repo-provided test adapters.

Run live-provider smoke tests only when the user explicitly asks and required credentials are available.

Output Expectations

Report:

• Provider/config behavior changed
• AI entrypoint added or changed
• Tools exposed to the model
• Error handling covered
• Tests run and whether they used live providers

Guardrails

• Do not commit API keys, tokens, request logs with secrets, or provider responses containing sensitive data.
• Do not hardcode a current model as a universal default.
• Do not add network-dependent tests to the default suite.
• Do not expose broad filesystem, shell, or network tools without explicit scope and validation.
• Do not change prompt behavior without tests or examples that capture the new expectation.