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) ...

The role of ActivitySource in OpenTelemetry for .NET

While doing some pair programming to integrate OpenTelemetry tracing to a .NET application, we had a discussion on how to use the ActivitySource . It looks simple. You new one up, give it a name, start an activity, done. The discussion started when we added a second ActivitySource with the exact same name in a different class. This made us wonder: "Are we duplicating traces now? Is this a memory leak? Do we need a singleton?" So we decided to dig deeper. This post is what we learned… What ActivitySource actually is ActivitySource is part of System.Diagnostics , not part of the OpenTelemetry NuGet packages. Microsoft built tracing primitives directly into the BCL, and OpenTelemetry's .NET SDK simply listens to them. This is why you can add distributed tracing to a library without taking a dependency on OpenTelemetry at all. An ActivitySource is a factory for Activity objects, and an Activity is .NET's name for what OpenTelemetry calls a span.(don’t ask m...