Skip to main content

elsa-roadmap-refresh

Refresh the Elsa roadmap from current evidence. Use when Codex needs to update ROADMAP.md or the public roadmap issue by researching elsa-core (which now contains the Studio and Extensions source) source code, specs, releases, commits, issues, pull requests, and discussions; classify shipped foundations, partial/productization work, roadmap candidates, stale items, and recommendations; then update the roadmap checklist and GitHub issue coherently.

Source facts

Repository
elsa-workflows/elsa-core
Last source activity
October 11, 2026 at 07:28
Detected SKILL.md language
English
Stars
7,904
Forks
1,528

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

File Explorer
2 files

Showing SKILL.md

SKILL.md
Source instructions · Read-only preview
name
elsa-roadmap-refresh
description
Refresh the Elsa roadmap from current evidence. Use when Codex needs to update ROADMAP.md or the public roadmap issue by researching elsa-core (which now contains the Studio and Extensions source) source code, specs, releases, commits, issues, pull requests, and discussions; classify shipped foundations, partial/productization work, roadmap candidates, stale items, and recommendations; then update the roadmap checklist and GitHub issue coherently.
# Elsa Roadmap Refresh ## Purpose Use this skill to refresh Elsa's roadmap from evidence across the Elsa product surface. Studio, Extensions and Apps are folded into one repository, so all evidence comes from: - `elsa-workflows/elsa-core` Do not query, clone, open issues or PRs in, or otherwise use `elsa-workflows/elsa-studio`, `elsa-workflows/elsa-extensions` or `elsa-workflows/elsa-apps`. Links to their old issues and releases that already appear in `ROADMAP.md` are history and stay as written. Cover Studio and Extensions topics from `studio/` and `extensions/` in elsa-core, and from elsa-core issues and PRs. The output should be a coherent product roadmap, not a raw issue digest. Ground every substantial change in source code, specs, releases, issues, pull requests, or discussions. ## Safety Rules - Before editing, run `git status --short` in `elsa-core`. - Never revert unrelated user changes. - If `ROADMAP.md` or `README.md` already has uncommitted user edits, stop and report the conflict unless the user explicitly asked to work through it. - Edit only roadmap-related files unless the user asks for more. - Do not commit, push, or publish unless the user or automation prompt explicitly asks for it. - If updating GitHub issue `elsa-core#3232`, use the final `ROADMAP.md` body as the issue body. ## Evidence Workflow 1. Read the current roadmap. - `ROADMAP.md` - `README.md` roadmap link, if relevant - GitHub issue `elsa-workflows/elsa-core#3232` 2. Inspect `elsa-core`. - Source modules under `core/src/modules` - App hosts under `core/src/apps` - Specs under `core/docs/specs` - Docs under `core/docs`, shared `docs` and `design` - Recent releases, commits, open issues, discussions, and open PRs 3. Inspect Studio, under `studio/` in `elsa-core`. - Source layout and feature modules under `studio/src` - Designer, diagnostics, auth, localization, embedding, workflow authoring, and instance UX - Recent releases, commits, open issues, discussions, and open PRs in `elsa-core` that touch `studio/` 4. Inspect Extensions, under `extensions/` in `elsa-core`. - Module families and integration foundations under `extensions/src` - Connections, Secrets, Agents, OpenAPI, schedulers, messaging, persistence, data tooling, and package manifests - Recent releases, commits, open issues, and open PRs in `elsa-core` that touch `extensions/` - Discussions if enabled; otherwise state that issue/PR signal is the available source Use `gh` for GitHub data when available. Prefer the local `elsa-core` clone when present; otherwise use a temporary clone or `gh repo clone elsa-workflows/elsa-core` into `/tmp`. ## Classification Rules Use these categories consistently: - `[x]` shipped foundation: implemented in source or released enough to build on. - `[~]` partially shipped or needs productization: code exists, but docs, Studio UX, integration, tests, release packaging, or operational readiness are incomplete. - `[ ]` roadmap candidate: valuable capability not yet implemented or only represented by issue/PR/proposal. - stale/obsolete: roadmap item is already done, superseded, or no longer matches repository direction. Be explicit when a conclusion is an inference from evidence rather than a direct source fact. ## Roadmap Editing Rules - Keep `ROADMAP.md` product-oriented and exciting, but technically defensible. - Preserve the main structure unless a better structure is clearly needed: - North Star - Capability Checklist - Current Foundations - Production Confidence - Authoring Productivity - Integrations And Ecosystem - Observability And Operations - Security, Identity, And Enterprise Readiness - AI-Assisted Workflow Engineering - Recommended Sequencing - Maintainership Recommendations - Update `Last refreshed` to the current date. - Keep issue and PR links close to the claims they support. - Prefer platform tracks over long lists of unrelated features. - Separate what is already present from what still needs productization. - Do not overpromise release dates. ## High-Value Themes To Re-Evaluate Each Refresh - Runtime recovery, graceful shutdown, distributed execution, scheduler/message reliability - Studio designer reliability, state machine authoring, debugging, progress/timeline, embedded components - Studio diagnostics, structured logs, console logs, OpenTelemetry, workflow incident timelines - Extension Platform, package manifests, Connections, Secrets, generated activities, connector SDK - Agents, MCP/tooling, provider matrix, AI-assisted authoring - OpenAPI activity provider, Azure Functions, Azure DevOps, Microsoft 365 and Google Workspace integrations - Security, OIDC, tenant/role activity visibility, localization, white-label readiness - Marketplace/plugin installation path and package maturity states ## Recommended GitHub Commands ```bash gh issue view 3232 --repo elsa-workflows/elsa-core --json title,body,updatedAt,url gh issue list --repo elsa-workflows/elsa-core --state open --limit 200 --json number,title,labels,updatedAt,url gh pr list --repo elsa-workflows/elsa-core --state open --limit 100 --json number,title,updatedAt,url gh release list --repo elsa-workflows/elsa-core --limit 10 ``` ## Publishing When asked to mirror the roadmap to GitHub: ```bash gh issue edit 3232 --repo elsa-workflows/elsa-core --body-file ROADMAP.md ``` After publishing, verify: ```bash gh issue view 3232 --repo elsa-workflows/elsa-core --json title,url,updatedAt ``` Final response should summarize changed themes, whether the GitHub issue was updated, and any files left modified.
View on GitHub