Discover, reuse, and release workflow packs in Epismo. Trigger on: 'find a workflow', 'get <id>', 'read <alias>', 'new workflow', 'create workflow', 'capture pattern', 'adapt a workflow', 'reuse this pattern', 'update workflow', 'organize steps', 'release this as a workflow', 'publish a workflow', 'deprecate workflow', or any intent to search community workflows or capture a proven execution pattern for reuse.
Discover, adapt, and release reusable workflow packs in Epismo — from finding a community pattern to publishing a proven execution structure.
Core principle: reuse before creating. Search private → liked → public before building anything new.
For connection setup, surface conventions, scope model, share URL resolution, and error handling, see Epismo Basics. For task/goal tracking, see Project Tracking. For workflow query patterns and loading, see Search & Discovery.
| Command | Natural language triggers |
|---|
| → |
|---|
new | create workflow, capture pattern, adapt a pattern, new workflow | NEW |
get <id|alias> | get this ID, load this ID, read alias, open alias, load workflow | GET |
find <query> | find a workflow, search workflows, what workflows do I have | FIND |
update [<id|alias>] | edit steps, update workflow, modify steps | UPDATE |
organize | reorganize steps, reorder, clean up workflow | ORGANIZE |
release [<id|alias>] | publish this, make public, release pattern, update release, deprecate | RELEASE |
| — | unclear intent | Ask once |
| Operation | CLI | MCP |
|---|---|---|
search pack | epismo pack search --type workflow --filter '{...}' | epismo_pack_search |
get pack | epismo pack get --id <id> [--full] [--step-id <ids>]<br>epismo pack get --alias <alias> | epismo_pack_get |
create pack | epismo pack create --input '<json>' | epismo_pack_create |
update pack | epismo pack update --id <id> --input '<json>' | epismo_pack_update |
delete pack | epismo pack delete --id <id> | epismo_pack_delete |
like pack | epismo pack like --id <id> --liked | epismo_pack_like |
upsert alias | epismo alias upsert --type workflow --id <id> --alias <name> | — |
get alias | epismo alias get --alias <name> | — |
list aliases | epismo alias list --type workflow | — |
delete alias | epismo alias delete --alias <name> | — |
Goal: create a reusable workflow as a private pack. Reuse before building — scan for an existing pattern first.
Infer 2–4 topic keywords from the user's intent. Search in this order:
# 1. Your own private workflows
epismo pack search --type workflow --query "<topic>" --filter '{"visibility":["private"]}'
# 2. Workflows you bookmarked
epismo pack search --type workflow --filter '{"like":"liked"}'
# 3. Community public workflows
epismo pack search --type workflow --query "<topic>" --filter '{"visibility":["public"]}'
| Result | Action |
|---|---|
| Strong match | Fetch full content → adapt steps → Step 3 — Create |
| Partial match | Fetch → use as base, modify steps → Step 3 — Create |
| No match | Design steps from scratch → Step 2 — Design steps |
Each step should:
human for decisions/reviews, AI agent name for generation/researchdependsOn only when execution genuinely requires a prior stepBefore materializing:
To materialize steps as project tracks, map each workflow step to an updateDrafts entry — use the step's id (e.g. s001) as a client label; the server resolves it to a UUID. Preserve dependsOn directly from the workflow steps:
epismo track apply --input '{
"projects": ["pj_123"],
"updateDrafts": [
{ "id": "s001", "title": "Define scope", "task": { "status": "todo" } },
{ "id": "s002", "title": "Implement", "task": { "status": "todo", "dependsOn": ["s001"] } },
{ "id": "s003", "title": "Review and ship", "task": { "status": "todo", "dependsOn": ["s002"] } }
]
}'
Use Workflow Patterns — Discovery for structured adaptation reports.
Default private. Use RELEASE to publish publicly.
create pack:
{
"title": "<title>",
"content": "<description>",
"type": "workflow",
"visibility": "private",
"steps": [
{
"id": "s001",
"title": "<step title>",
"content": "<step instructions>",
"dueDate": "",
"dependsOn": [],
"parentId": "",
"assignee": "human"
}
]
}
| Who needs it | visibility | projects[] |
|---|---|---|
| Just me | "private" | omit |
| My team | "private" | ["pj_xxx"] |
workflow <workflow-id> <workflow-title>
step <step-id> <step-title>
Goal: fetch a workflow by ID, alias, or explicit read/open target.
Prefer alias-first unless the input is obviously a search query.
| Input pattern | Route | Why |
|---|---|---|
get ..., use ..., load ..., open ..., read ... | GET | Explicit retrieval |
find ..., search ..., what workflows do I have, show workflows | FIND | Explicit discovery |
| Bare UUID | GET | IDs are unambiguous |
| Bare alias-shaped token | GET | Try alias first, then search if it misses |
| Short ambiguous phrase | GET | Try alias first, then search if it misses |
| Obvious search query, question, or long descriptive phrase | FIND | Discovery intent is clearer than alias intent |
get pack --id.@handle/name or one compact token like prd-review → get pack --alias; if it misses, run FIND with the same text.deployment checklist → try get pack --alias first; if it misses, run FIND.get/read/open/use <target> always counts as retrieval intent.get pack — default returns outline only; pass --full for all steps, or --step-id to load specific steps.
epismo pack get --id <pack-id> --full
epismo pack get --alias <alias> --full
epismo pack get --id <pack-id> --step-id <step-id-1>,<step-id-2>
Goal: discover the right workflow when the ID is not known.
search pack — scan titles only (no step content). Use this for natural-language discovery requests and multi-keyword topic phrases. Search in this order:
type: workflow, query: <topic>, filter: { visibility: ["private"] }type: workflow, query: <topic>, filter: { like: "liked" }type: workflow, query: <topic>, filter: { visibility: ["public"] }Present the title list; if the match is clear, get pack immediately.
For filter keys, sort options, and search recipes, see Search & Discovery.
Goal: edit the steps or metadata of an existing workflow.
Always fetch before writing.
get pack → inspect current steps and metadata → update pack with id and step operations using op fields.
For update <alias> based on this conversation:
dependsOn, ownership, and ordering coherentsearch pack — type: workflow, query: <inferred topic>, filter: { visibility: ["private"] }, sort: updatedAt:desc"Last workflow" shortcut: sort updatedAt:desc, take the first result.
workflow <workflow-id> <workflow-title>
step <step-id> <step-title> # when a specific step was updated
Goal: improve the step structure of an existing workflow.
get pack --full → review all steps → apply changes → update pack.
| Situation | Action |
|---|---|
| A step is too broad or covers multiple concerns | Split — divide into two focused steps |
| Two steps overlap or one has become redundant | Merge — combine into one coherent step, remove the other |
| A step is no longer relevant | Remove — delete the step from the workflow |
| Steps are out of execution order | Reorder — update dependsOn chains to reflect correct sequence |
| The whole workflow is obsolete | Delete — requires explicit user approval |
All changes are applied via update pack using op fields. Use "op": "add" for new steps, "op": "update" for existing ones, "op": "remove" to delete a step by ID. delete pack requires explicit user approval.
Goal: publish a workflow publicly, update an existing release, or deprecate an obsolete one.
Two paths:
| Situation | Path |
|---|---|
| Existing private workflow worth sharing | Promote — change visibility to public |
| New content written for community reuse | Create new public workflow via NEW first |
Run Quality Gate before any release decision. All 8 criteria must pass for public release. A single fail means: fix or keep private.
| Decision | When |
|---|---|
release | Execution proven, structure generalizable, no superior equivalent exists |
update | Improves an existing released pattern without breaking consumers |
keep private | Evidence incomplete or quality gate has open items |
deprecate | Obsolete, unsafe, or superseded |
Run the pre-decision checks in Release before choosing one of these paths.
Confirm with user before writing: state the workflow title, ID, and target visibility.
update pack:
{
"id": "<id>",
"visibility": "public",
"category": "<category>"
}
| Category | When to use |
|---|---|
productivity | Daily rhythms, time management, operating norms |
programming | Code review, deployment, testing, development workflows |
design | Component reviews, UX research, design system processes |
marketing | Campaign planning, content creation, launch workflows |
operations | Incident response, onboarding, deployment pipelines |
learning | Onboarding guides, skill-building, training workflows |
life | Personal productivity, non-work routines |
See Release for the approval boundary and required output format.
workflow <workflow-id> <workflow-title>
share https://epismo.ai/hub/workflows/<id>
new and update always write private. Use RELEASE to go public.For the full approval matrix, see Visibility & Sharing — Approval Boundary.
After every operation, return in this order:
workflow <workflow-id> <workflow-title>
step <step-id> <step-title> # when a specific step was created or updated
Skip analysis and evidence unless the user asked for it.
Repository: https://github.com/epismoai/skills