agentjido/jido_run/jido-studio

Jido Studio

jido_studio is the upstream Hex package name.

Start Here

Use this skill for workbench, operator, and demo-facing tasks around the Jido ecosystem.

Good triggers:

• "Add or update a Studio page for this ecosystem package."
• "Plan an operator-facing workflow for agents."
• "Turn package source material into a Studio demo."
• "Review whether this feature belongs in Studio or in a package repo."

The public documentation is thinner here than for the core libraries. Keep proposals narrow and grounded in the ecosystem page, issue #51, and any package-specific examples you can verify.

Primary Workflows

Build or update ecosystem-facing pages

• Start from the package boundary and the user workflow the page should support.
• Prefer concrete demos, examples, or inspection surfaces over generic marketing copy.
• Reuse existing package terminology so Studio and package docs stay aligned.

Plan operator tooling

• Make agent state, signals, or traces visible without coupling Studio to private app internals.
• Keep operational controls explicit and reversible.
• Document which runtime data the Studio feature depends on.

Turn source material into demos

• Build examples that prove one builder workflow end to end.
• Keep the demo small enough to run or explain without hidden infrastructure.
• Call out assumptions when package docs do not define a Studio integration contract.

Build Checklist

• Identify the operator or contributor workflow first.
• Name the package or runtime data the Studio surface depends on.
• Keep demos aligned with documented package behavior.
• Mark inferred Studio behavior as inferred.

Boundaries

• Do not invent undocumented Studio APIs or page contracts.
• Do not move package-specific implementation details into Studio unless the user explicitly wants that coupling.
• Do not treat thin ecosystem descriptions as proof of a full product feature.