Skip to main content

Sharing your VS Code automations

Last week I talked about Continuous AI and how the VSCode Automation feature is one example of this vision

My blog posts were just written when a new VS Code update landed on my machine with some Automation improvements included. First the automation feature is no longer in preview but enabled by default.

But the feature I want to talk about is that you can start sharing automations; either by shipping automation templates through an agent plugin, or by exporting and importing automations as a file.

Let's look at both.

What gets shared?

An automation is a saved prompt, a session configuration and a schedule. Not all of that travels well between machines, so VS Code only shares the portable part:

  • Name and prompt
  • Schedule (manual, hourly, daily or weekly)
  • File format version and an identifier

What is not shared: workspace, provider, model, permissions, enabled state and run history. The person who receives the automation makes those choices locally.

This makes sense. You don't want someone else's permission settings silently landing on your machine.

Option 1: Automation templates in an agent plugin

Agent plugins can now contribute automation templates next to the list of built-in templates. 

Put them in an automations/ folder at the root of your plugin. Every file needs the .automation.md suffix.

my-team-plugin/
  plugin.json
  automations/
    daily-commit-summary.automation.md

The plugin.json is the regular Agent Plugins manifest:

{
  "$schema": "https://agent-plugins.org/schemas/1.0.0/plugin.schema.json",
  "name": "my-team-plugin",
  "description": "Automation templates for our team",
  "version": "1.0.0"
}

A template is a Markdown file with YAML frontmatter. The Markdown body is the prompt:

---
version: 1
id: daily-commit-summary
name: Daily commit summary
description: Summarize the commits of the last 24 hours.
schedule:
  kind: cron
  expression: "0 8 * * *"
  timeZone: local
---
Summarize the commits on the current branch from the last 24 hours.
Group them by feature, fix and maintenance.
Do not modify any files.

For the schedule you have these options:

  • kind: manual
  • kind: hourly
  • kind: cron with a five-field expression for a daily or weekly schedule, together with timeZone: local

Remark: Only local-time cron expressions that represent a daily or weekly schedule are supported. Anything else is ignored. VS Code doesn't try to fix your schedule for you.

Tip: Don't want to use the default automations/ folder? Add extra folders through extensions.com.github.copilot.automations.paths in plugin.json. Set exclusive to true to load templates only from those folders.

Using the templates

Install the plugin, for example through Install Plugin from Source on the Plugins page of the Agent Customizations editor, or by registering a local folder in the chat.pluginLocations setting.

Then open Automations in the Agents window. Your templates show up under Templates from Plugins, with a Plugin badge and the name of the source plugin. A blue marker tells you a plugin contributed a new template.

Select a template and the New Automation dialog opens. Review the prompt and the schedule, choose workspace, agent, model, permissions and isolation, and select Create. The Enabled checkbox is cleared by default.

Installing the plugin doesn't create or enable anything. Disabling the plugin removes its templates from the view, but automations you already created from them (including their run history) stay.

Option 2: Export and import

Sometimes a plugin is overkill. You have one automation and you want to send it to one person.

To export:

  1. Hover over the automation card and open More Actions
  2. Select Export
  3. Choose where to save the .automation.md file

The result is the same format as a plugin template: readable Markdown with YAML frontmatter. Open it in an editor before you share it. That's a good habit anyway.

To import:

  1. Select Import Automation in the Automations view and choose the file, or drag the file onto the view
  2. Review the name, prompt and schedule in the New Automation dialog
  3. Choose workspace, agent, model, permissions and isolation
  4. Select Enabled when you are happy, then Create

Files that VS Code doesn't support are rejected instead of being imported with a changed schedule or with execution permissions.

Remark: An automation can read files, run commands and make changes based on the permissions of its agent. Review the permission level before you schedule anything unattended, certainly for an automation you received from someone else.

Which one should you use?

  • Agent plugin: for templates you want to maintain and distribute to a team. Update the plugin and everyone gets the new version.
  • Export/import: for one-off sharing between two people or two machines.

Both end up in the same place: the New Automation dialog, disabled, waiting for your review.

More information

Popular posts from this blog

Podman– Command execution failed with exit code 125

After updating WSL on one of the developer machines, Podman failed to work. When we took a look through Podman Desktop, we noticed that Podman had stopped running and returned the following error message: Error: Command execution failed with exit code 125 Here are the steps we tried to fix the issue: We started by running podman info to get some extra details on what could be wrong: >podman info OS: windows/amd64 provider: wsl version: 5.3.1 Cannot connect to Podman. Please verify your connection to the Linux system using `podman system connection list`, or try `podman machine init` and `podman machine start` to manage a new Linux VM Error: unable to connect to Podman socket: failed to connect: dial tcp 127.0.0.1:2655: connectex: No connection could be made because the target machine actively refused it. That makes sense as the podman VM was not running. Let’s check the VM: >podman machine list NAME         ...

Cache stampede: when our cache turned against us

While investigating some performance issues, we ran into an ASP.NET Core API that cached a fairly expensive aggregation query for 60 seconds. Under normal load, that was fine: one request rebuilds the cache, everyone else reads from it. Under peak load, dozens of requests would arrive in that same expiry window, all see a cache miss, and all fire the same expensive query in parallel. The database didn't like that. That was the moment when our caching layer stopped helping and started hurting. A burst of requests comes in at the same time, all miss the cache, and all go hammer the database or the downstream API at once. That's a cache stampede . The cache was supposed to protect our backend, and for a few hundred milliseconds it did the opposite. Why this happens IMemoryCache.GetOrCreate (and its async sibling) looks like it protects you, but it doesn't add any locking on its own. Look at the naive version: public async Task<Report> GetReportAsync(string key) ...

VS Code Planning mode

After the introduction of Plan mode in Visual Studio , it now also found its way into VS Code. Planning mode, or as I like to call it 'Hannibal mode', extends GitHub Copilot's Agent Mode capabilities to handle larger, multi-step coding tasks with a structured approach. Instead of jumping straight into code generation, Planning mode creates a detailed execution plan. If you want more details, have a look at my previous post . Putting plan mode into action VS Code takes a different approach compared to Visual Studio when using plan mode. Instead of a configuration setting that you can activate but have limited control over, planning is available as a separate chat mode/agent: I like this approach better than how Visual Studio does it as you have explicit control when plan mode is activated. Instead of immediately diving into execution, the plan agent creates a plan and asks some follow up questions: You can further edit the plan by clicking on ‘Open in Editor’: ...