Jido action

Skill agentjido/jido-skills/source/skills/jido-action

Agent Skills documentation and examples for the Jido ecosystem

Install

npx -y skills add agentjido/jido-skills --skill jido-action

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Build and maintain composable Jido actions with validated inputs, explicit outputs, predictable errors, and AI-tool compatibility. Use when defining actions, schemas, action chains, or action execution behavior.

The file declares its own license as Apache-2.0. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

3.1 KB, as published. Nobody here has run it

Jido Action

Purpose

Create focused Jido actions that are easy to validate, compose, test, and expose to agents or tools.

When To Use

Use this skill for:

New use Jido.Action modules
Action schema or output schema changes
run/2 behavior changes
Action chains or closures
Converting actions into AI-callable tools
Debugging action validation or execution

Invoke jido-core first for shared ecosystem context.

Requirements

Inspect local action modules before writing new patterns.
Preserve the repo's current schema style unless migration is requested.
Prefer pure, deterministic action behavior.
Return explicit success or error tuples.

Workflow

1. Inspect action conventions

Search before editing:

rg "use Jido.Action|def run\\(" lib test

Record:

Schema style
Return shape
Error conventions
Context usage
Tests for validation and execution

2. Define the action contract

Before coding, identify:

Action name and description
Required and optional params
Output shape
Error cases
Context fields read by run/2
Whether the action is safe to expose as an AI tool

Keep actions narrow. Split multi-step workflows into action chains or separate actions when that improves testing and reuse.

3. Validate inputs and outputs

Use the repo-supported schema mechanism. For new code, prefer Zoi when the repo already uses or supports it. Otherwise preserve the existing schema style.

Validation should reject invalid input before behavior executes. Output schemas should be used for externally consumed or tool-facing actions when supported.

4. Implement `run/2`

run/2 should:

Accept validated params
Read only documented context keys
Return {:ok, result} or {:error, reason}
Keep external side effects out unless the action's purpose is explicitly an adapter boundary
Avoid raising for normal validation or domain failures

5. Tool compatibility

When exposing an action to AI tools:

Ensure name and description are clear to a model
Ensure params have useful docs
Avoid ambiguous atoms or internal-only data structures at the tool boundary
Add tests for generated tool schema when the repo supports that behavior

6. Validate

Run focused action tests first:

mix test path/to/action_test.exs

Then run the repo-standard test or quality command.

Output Expectations

Report:

Action contract changed
Validation behavior changed
Error cases covered
Tool-facing behavior, if any
Tests run

Guardrails

Do not use actions as unstructured service objects.
Do not silently swallow errors.
Do not depend on process dictionary state.
Do not expose unsafe filesystem, network, or code-evaluation behavior as a model tool.
Do not change return shapes without updating callers and tests.