Skip to main content

Create Your Own Recipes

You can create your own Automation Agent workflow recipes by first developing the workflow with a strong MCP agent, then asking that agent to turn the successful run into a reusable implementation prompt.

This is worth doing when you expect to run the same kind of workflow more than once.

A one-off high-level prompt can be fine for exploration. For a repeatable workflow, it is usually better to move as much thinking as possible into the prompt itself: the inspection order, Runtime DSL snippets, validation steps, expected output records, adaptation rules, and failure handling.

That helps strong agents such as Codex and Claude Code because they can work faster, use fewer tokens, and avoid rediscovering the same solution every time. It helps even more when the final workflow should run with a local model or a generic MCP client that can call Automation Agent tools, but does not automatically receive the full Automation Agent skill, DSL reference, and example library.

If you are new to Automation Agent workflows, start with Agent Workflow via MCP and Supported MCP Clients.

Why This Helps​

A high-level prompt usually describes the editing problem in natural language: what should happen, which material matters, and what the result should look like. It often does not spell out the exact Automation Agent programs needed to do the work.

That leaves important implementation choices to the agent. For example, if you ask an agent to work with the currently selected project items, the agent first has to figure out which Automation Agent probe can list those selected items. If the workflow uses transcripts, it has to figure out how to map project items to transcript export steps. If the workflow creates markers, it has to figure out the exact Runtime DSL shape for marker creation.

Strong agents such as Codex or Claude Code can often discover those details while they work. That is useful during development, but it is wasteful when the workflow is already known.

If the agent has to solve the same implementation problem from scratch on every run, it spends time and tokens on work that could have been prepared once. For a repeated workflow, you can move that work into the prompt: include the probe that lists selected project items, the transcript export skeleton, the marker creation skeleton, and the rules for which values may be adapted.

An implementation prompt reduces that burden. It gives the target agent a tested plan, validated DSL snippets, expected probe output, adaptation rules, and failure handling. The target agent still needs to inspect the current Premiere project, but it does not need to invent the whole solution strategy again.

This matters most for local or limited-context agents. They may be able to call MCP tools, but still struggle to infer the right Runtime DSL program from a broad editorial request. If a powerful agent has already developed and tested the workflow once, use that work to produce a more precise prompt that local agents can follow with much less guesswork.

Use this pattern when you want to turn a working workflow into something repeatable:

  1. develop the workflow first with a strong Automation Agent-aware MCP agent, such as Codex or Claude Code
  2. describe the workflow goal at a high level and let the strong agent inspect, implement, validate, and repair the needed Automation Agent programs
  3. iterate until the workflow works and the important DSL snippets validate
  4. paste the generator prompt below into that same agent session
  5. review the generated implementation prompt
  6. test the implementation prompt in the environment where you want to reuse the workflow

This is useful even if you plan to keep using Codex or Claude Code later. It becomes even more important if the finished workflow should also run with a less capable or more limited local agent, such as LM Studio.

Do not develop workflow prompts with sensitive production data in a cloud-hosted model unless your organization has explicitly approved that use.

From Goal Prompt To Implementation Prompt​

The process starts with a natural-language prompt. You describe the editing goal, not the exact Automation Agent programs needed to achieve it. The strong agent then uses MCP to inspect the project, discover the needed Runtime DSL, validate it, repair it, and run the workflow.

After the workflow works, you ask that same agent to generate a second prompt from what it just learned. That second prompt is the implementation prompt. It contains the technical details that were discovered during development: MCP order, read-only probes, validated Runtime DSL snippets, expected output records, adaptation rules, and failure handling.

That means you do not have to write the technical prompt by hand. You start with the user-facing workflow goal, let a strong agent develop and test the solution once, then ask it to package the working solution into a reusable prompt for future runs.

Start with a goal prompt like this:

I want an Automation Agent workflow for Adobe Premiere that does the following:

[Describe the editorial task and expected result.]

Please inspect the current project through MCP, develop the Automation Agent Runtime DSL needed for this workflow, validate every DSL program before execution, run only the needed steps, and repair validation errors if they occur.

Use non-destructive read-only probes first. Before any broad or hard-to-undo write action, explain what will change.

After the workflow works, keep track of the validated DSL snippets, probe output formats, assumptions, and failure cases because I will ask you to turn this into a reusable implementation prompt.

After the workflow has actually worked, use the generator prompt below. The generator prompt is not meant to solve the original editing task again. It asks the source agent to package what it learned into a prompt that another agent can follow with much less inference.

Generator Prompt​

Paste this after the source agent has successfully performed the workflow:

You just executed an Automation Agent for Adobe Premiere workflow through MCP.

Create a detailed implementation prompt for the workflow you just executed.

Target:
Another MCP agent should be able to run this workflow later, even if it has limited context and no access to the Automation Agent skill, the full Runtime DSL documentation, or the examples library.

The implementation prompt should reduce the target agent's reasoning burden as much as possible. Anything that can be decided, structured, validated, or described independently of the current Premiere project should already be included: inspection order, DSL snippets, expected output records, adaptation rules, workflow decisions, and failure handling. The target agent should mainly inspect project state, replace clearly marked placeholders, validate DSL, and execute.

This is useful for local or limited-context agents, and it is also useful for stronger agents because it can make repeated workflows faster, cheaper, and less error-prone.

Please produce the final implementation prompt, not an explanation of your internal reasoning.

The implementation prompt must include:

1. A short role and task description for the target agent.
2. The exact MCP workflow order.
3. The read-only discovery probes required before any write action.
4. The complete Runtime DSL programs or DSL skeletons needed for the workflow.
5. For each DSL snippet:
   - purpose
   - whether it is read-only or write
   - whether you actually executed it with runDslProgram during the successful workflow
   - which placeholders or variables the target agent may adapt
   - which values the target agent must inspect instead of guessing
   - expected console or output records
6. For repetitive DSL structures:
   - prefer a compact template or skeleton plus one or two representative validated examples
   - explain exactly how the target agent should repeat the structure
   - do not paste a long list of project-specific repeated blocks unless the full list is essential to understanding the workflow
   - use clear placeholder names for project-specific values instead of copying many concrete values from the development project
7. The validation rule:
   - always call validateDsl before runDslProgram
   - only call runDslProgram after validation succeeds
   - if validation fails, repair only the specific reported issues and validate again
8. Write behavior:
   - which write actions are part of the workflow
   - whether the workflow includes a separate review step before writing
   - what the target agent should summarize before writing
   - what the target agent must never delete, overwrite, rename, or move unless the workflow explicitly requires it
9. The workflow-specific decision logic:
   - how to choose records, clips, transcript sections, times, markers, paths, names, or other project-dependent values
   - how to handle existing project state
   - what assumptions are allowed and what must be inspected
10. Failure and uncertainty handling:
   - missing active sequence or selection
   - missing, incomplete, or ambiguous transcripts
   - unclear clip, project item, timeline, or marker mapping
   - too little data to complete the workflow
   - DSL validation failure
   - execution failure
11. A final checklist for the target agent:
   - before execution
   - after execution

Quality rules:
- Use only MCP tools and Runtime DSL blocks that you actually used or validated during the successful workflow.
- Ready-to-run DSL snippets must have passed validateDsl.
- If you include a skeleton with placeholders, clearly label it as a skeleton, not ready-to-run DSL. Tell the target agent to replace every placeholder, then call validateDsl before runDslProgram.
- If a needed ready-to-run snippet was not validated, do not present it as ready to use. Put it in a separate section named "needs validation before publishing".
- Do not use pseudocode function names.
- Do not invent DSL block names, inputs, enum values, refs, paths, clip names, sequence names, effect names, transcript availability, or marker behavior.
- Mark assumptions explicitly.
- Preserve the actual user-facing behavior of the workflow. Do not add a review step or approval step if the workflow intentionally runs in one pass, but do not add destructive actions that were not part of the workflow.
- Write the final prompt so it can be pasted into user documentation with minimal editing.

When To Use The Result​

Use the implementation prompt when:

  • you want a local LM Studio model to run a workflow with Automation Agent MCP
  • you use another MCP client that does not have the Automation Agent skill or examples
  • you want Codex or Claude Code to repeat a workflow faster with less rediscovery
  • you want to document a workflow recipe for a team

Test the implementation prompt on non-sensitive material before relying on it. A generated implementation prompt is a starting point, not a guarantee that every agent or model will handle the workflow correctly.