Ricardo Covo - Blog

Ricardo Covo - Blog - Ephemeral Intelligence: Running On-Demand Copilot Agents in GitHub Workflows

2026-04-13T00:00:00Z

TL;DR: ⚡GitHub Copilot CLI + APM (Agent Package Manager) lets you drop portable, on-demand agent intelligence into any GitHub Actions workflow — no permanent changes to the target repository needed. Here's how I used it to run standardized architecture discovery across 100+ repositories without losing my mind.

The Challenge: Agent Configuration at Scale

Over the past few weeks, I hav been thinking about how to assess the architecture and technical health of every repository across an organization — think 100s of repos — and produce a standardized set of outputs: Tech stack summaries. Dependency inventories. Risk flags. Improvement opportunities. The kind of artifacts that, taken together, would give us a coherent picture of the whole landscape and a defensible starting point for modernization planning.

With GitHub Copilot I knew it could accelerate the analysis dramatically. But here was the real problem: every time I would need update the repo with the right set of prompts, skills, and instructions for architecture discover. It was a bit tedious: Copying files over. Tweaking instructions. Not to mentioned the maintainability of these assets.

That friction is what led me to APM — and it changed how I think about agentic workflows entirely.

📦 APM: Think 'npm' for Agent Primitives (custom agents, instructions, prompts, skills, etc.)

APM (Agent Package Manager) is an open-source tool that does for AI agent configuration what npm does for Node.js dependencies, or pip does for Python. Instead of telling every developer to manually set up their Copilot instructions and prompts, you declare them in a manifest file.

Simply run apm install, and APM resolves and installs everything: custom instructions (.instructions.md), skills (.skill.md), prompts (.prompt.md), agents (.agent.md), and more.

But here's the thing that really unlocked the use case for me: 💡agent primitives don't have to live permanently in the target repository. You can bring them in at workflow time, use them, and leave no trace. Ephemeral, intentional, and fully reproducible.

⚙️ The Setup: A Discovery Factory

The architecture I landed on has two moving parts:

1. A central discovery package — I have around 20 primitives I use for the repository discovery, I packaged them all into a repo-metadata-generator pack.

2. A reusable GitHub Actions workflow that can be dispatched against any target repository. It checks out the repo, installs Copilot CLI and APM, pulls in our discovery pack, runs the prompts, and uploads the results as artifacts.

You can check out the full workflow. Here are the interesting bits:

name: Generate Architect Metadata
...
jobs:
  discover:
    ....
    - name: Download repo-metadata-generator pack
      run: |
        curl -L -o repo-metadata-generator-1.0.0.tar.gz \
            "https://github.com/.../repo-metadata-generator-1.0.0.tar.gz"

    - name: Install GitHub Copilot CLI
      run: npm i -g @github/copilot

    - name: Install APM and Unpack Metadata Generator
      run: |
        curl -sSL https://aka.ms/apm-unix | sh
        apm unpack repo-metadata-generator-1.0.0.tar.gz

    - name: Run Documentation
      env:
        COPILOT_GITHUB_TOKEN: ${{ secrets.COPILOT_GITHUB_TOKEN }}
      run: |
        set -euo pipefail

        copilot --agent repo-analyzer -p "/fleet Run all the prompts in the .github/prompts"
    ...

We're injecting our own discovery-specific manifest, pulling in exactly the primitives we need for this job, doing the analysis, and uploading the results. The target repo is unchanged. The workflow is stateless. You can run it against a repo today, improve the discovery pack tomorrow, bump the version, and re-run.

🔍 What's Inside the Discovery Pack

If you are interested, you can check out the contents of the repo-metadata-generator pack. But be aware this is only a sample pack.

🧠 The Mental Model Shift That Matters

What excites me about this pattern isn't the specific tools. It's what it represents.

We've spent years building reusable code: shared libraries, internal npm packages, Artifactory registries. We've invested heavily in CI/CD so that quality checks, security scans, and deployments are automated and consistent. But AI agent configuration has been the wild west — per-developer, per-project, copy-pasted, undocumented, and completely non-reproducible.

APM brings the same engineering discipline we apply to code dependencies to agent configuration. And when you combine it with GitHub Copilot CLI and GitHub Actions, you get agentic workflows that are portable, versioned, auditable, and scalable.

The same pattern extends naturally to:

✅ Automated PR review checklists — different skill packs for different service types (API, frontend, data pipeline)
🔒 Security audit workflows — triggered automatically when a new repo is created
📝 Release note generators — with org-specific tone, format, and audience targeting
🚀 Developer onboarding agents — that generate a tailored "getting started" guide for each codebase, pulled fresh every time

In every case: define your primitives once, package them, version them, let the workflow do the rest.

Ricardo Covo - Blog - GitHub Copilot Learning Path

2026-02-19T00:00:00Z

GitHub Copilot is quickly becoming a must‑have tool for modern development teams—but learning how to use it effectively can feel overwhelming. With dozens of modules, features, and enterprise considerations, it’s not always clear where to start or how to progress beyond basic code completion. This post outlines a simple, structured learning sequence for GitHub Copilot, guiding developers and organizations from foundational concepts through practical, day‑to‑day usage and into advanced and enterprise‑ready capabilities. Whether you’re an individual developer, a team lead, or supporting adoption at scale, this sequence is designed to help you learn Copilot in the right order and get real value faster.

1) Prerequisites (Recommended)

Build basics so Copilot suggestions make sense in real workflows.

2) Core GitHub Copilot Fundamentals

3) Prompting & Responsible Usage

4) Language-Specific Practical Development (Pick your stack)

5) Day-to-Day Developer Productivity

6) Advanced Capabilities

7) Enterprise, Admin, Governance

Quick Suggested Paths

Individual Developers: Sections 1 → 2 → 3 → 5 → 4 (as needed) → 6
Enterprise Customers / Decision Makers: Sections 1 → 2 → 3 → 7
Hands-on Workshop / Demo: Sections 2 → 5 → 6

Ricardo Covo - Blog - GitHub Copilot for Every Role

2026-02-17T00:00:00Z

GitHub Copilot is more than just a tool for developers—it's a powerful AI assistant that's transforming how cross-functional teams work. From drafting user stories to generating SQL queries and writing test cases, Copilot helps non-developers and technical specialists alike work faster, reduce manual effort, and improve quality.

Whether you're a Product Owner, Business Analyst, Tester, or Data Engineer, Copilot can automate repetitive tasks, bridge technical gaps, and accelerate your workflow. Teams using Copilot have reported significant productivity gains, with some achieving over 20% increases in feature velocity and ROI exceeding 1,500%.

Comparison of Copilot's Benefits and Applications by Role

Role	Key Copilot Assistance	Example Applications
Product Owners (Product Managers)	Drafts and formats product documents, user stories, and specs; explains code in plain English.	PRDs, user stories, release notes, stakeholder summaries.
Business Analysts	Translates business needs into structured artifacts like diagrams, SQL, and documentation.	Process flows, SQL queries, validation rules, traceability matrices.
Testers / QA	Auto-generates unit and integration tests; suggests edge cases and test data.	Unit tests, Gherkin scenarios, mocks, test coverage expansion.
Data Engineers	Speeds up data pipeline development and query generation; suggests optimizations.	ETL scripts, SQL queries, data transformations, documentation.

Sources & Further Reading

Ricardo Covo - Blog - How to save BIG on Azure with Spot Instances

2023-11-16T00:00:00Z

I have been working with Azure for a long time… So I am ashamed to say that I did not know about Spot instances until I saw an announcement this summer about them being available for Azure Container Instances (ACI). Now, I use them in many scenarios and save a ton of money for myself and my clients.

What are Spot Instances?

First things first, Azure Spot Instances are a way to get cheap and scalable computing power on the Azure cloud. They run on unused Azure capacity and can be up to 90% cheaper than the regular price. However, they can also be evicted at any time if Azure needs the capacity back or if the price goes above your limit. So, they are best for workloads that can handle interruptions, like testing, batch processing, or analytics.

Currently, Spot Instances are being offered on Azure Virtual Machines and Azure Container Instances (ACIs are on public preview and only available in West Europe, East US, and West US2).

How does it work?

When you create your instance, you will have the option to “Run with Azure Spot discount”. The image below shows an example of creating a VM, but a similar option appears when creating ACIs:

Once you select your Discount, you can decide the Eviction Type and the Eviction Policy, according to your needs. As a reminder, Spot instances are operating on excess capacity; if resources are needed by Azure, you can and will get evicted. So, these should only be used on non-critical workloads, or on workloads where interruptions are needed.

Benefit$$$?

The main benefit is cost. You can run with tons of computing power, paying only a fraction of the cost. Imagine, for example, a rendering job that runs sporadically but requires powerful machines; you can use Spot Instances to get the job done, at a low cost, and then stop the machine yourself or let it be deallocated. You can use Spot Advisor to calculate your potential savings, but in most cases, the savings are simply amazing:

Sample Savings for Spot VMS

Besides the possibility of getting evicted, Spot Instances are basically identical to the regular service:

Fast and reliable. They use the latest hardware and software technologies to deliver high performance and availability.
Secure and compliant. They are protected by multiple layers of security, including encryption, firewalls, and identity management.
Scalable and flexible. You can easily scale up or down depending on your workload and demand.
Cost-effective and convenient. They have a pay-as-you-go pricing model, which means you only pay for what you use.You can also save money by using reserved instances, spot instances, or hybrid benefit options.
Plus, you can access your virtual machines from anywhere using the Azure portal, CLI, or SDK.

Where have I used them?

I am currently using a Spot VM Machine to run a client application that we are modernizing. The application is running as a reference for our development team, so it is not critical, however, it does require a bit of compute power. Having a Spot Instance just made sense, we have been running it for a month or so and have not been evicted once.

We are also using ACI. We have a nightly process that manages images, it requires a fair bit of computing power, but in the right environment should only run for an hour or so. The ACI running our image is started/stopped programmatically, and because it knows how to stop/resume its process, we are not very concerned about being evicted in the middle of a run.

I am sure there are many other scenarios where this can be used, now that I know about them, I keep my eyes open to cost savings 😄

Is worth saying again: Really think about the scenario before you jump into Spot Instances, no critical workloads should be running on them.

Ricardo Covo - Blog - Writing a simple API in minutes with Azure Functions and SQL

2023-06-27T00:00:00Z

For a long time, developers using SQL Server have felt forgotten when it comes to Azure Functions. While Cosmos DB bindings have been available since the beginning, the equivalent SQL Server ones have been lagging.

Last month (May 2023), the General Availability of SQL Bindings for Azure functions was finally announced and I could't wait to jump into it. If you have used the CosmosDB bindings, there won’t be many surprises, they have done a good job in keeping things consistent.

To summarize, this is what they have made available:

Input / Output bindings (General Availability) — You can use Text Commands or Stored Procedures.
Track Changes Trigger (In Preview)
Update Dec 6, 2023: Now Generally Available. (annoucement)

I decided to write a simple API using these new capabilities, I am working with a model Listing, and aim to create a RESTful API for it. I am using SQL Server running on a container on my machine, but this should work with Azure SQL as well.

Here we go:

Get All Listings

Using the input binding, it selects all active listings from my table.


[FunctionName("GetListings")]
public static IActionResult Run(
  [HttpTrigger(AuthorizationLevel.Function, "get", Route = "listing")] HttpRequest req,
  [Sql("SELECT * FROM [dbo].[Listings] WHERE IsActive = 1", "SqlConnectionString")] IEnumerable<Object> result,
  ILogger log)
{ 
  return new OkObjectResult(result);
}

Get Single Listing

Using the input binding again, using the route parameter (Id) to query the database.


[FunctionName("GetListing")]
public static IActionResult Run(
  [HttpTrigger(AuthorizationLevel.Function, "get", Route = "listing/{id}")] HttpRequest req,
  [Sql("SELECT * FROM [dbo].[Listings] WHERE Id = @Id", "SqlConnectionString", "@Id={id}")] IEnumerable<Object> result,
  ILogger log)
{
  return result.Count() == 0 ?
      new NotFoundResult() : 
      new OkObjectResult(result.First());
}

Create Listing

Using the output binding with an ASync collector. It's important to notice the AddItem is actually an upsert. We will use it on updates as well.


[FunctionName("CreateListing")]
public static async Task Run(
    [HttpTrigger(AuthorizationLevel.Function, "post", Route = "listing")] HttpRequest req,            
    ILogger log,
    [Sql("[dbo].[Listings]", "SqlConnectionString")] IAsyncCollector<Listing> listings)
{
    string requestBody = await new StreamReader(req.Body).ReadToEndAsync();
    var listing = JsonConvert.DeserializeObject<Listing>(requestBody);
    listing.Id = Guid.NewGuid();
    listing.CreatedDate = listing.UpdatedDate = DateTime.Now;
    listing.IsActive = true;
    
    await listings.AddAsync(listing);
    await listings.FlushAsync();
    
    return new CreatedResult($"/listing", listing);
}

Update Listing

Output binding again, but with some validation on the input to compare to the route param (Id). There are many ways to be creative with the update, let me say this is just a simple example.


[FunctionName("UpdateListing")]
public static async Task Run(
    [HttpTrigger(AuthorizationLevel.Function, "put", Route = "listing/{id}")] HttpRequest req,
    Guid id,
    ILogger log,
    [Sql("[dbo].[Listings]", "SqlConnectionString")] IAsyncCollector<Listing> listings)
{
    string requestBody = await new StreamReader(req.Body).ReadToEndAsync();
    var listing = JsonConvert.DeserializeObject<Listing>(requestBody);
    if (id != listing.Id) {
    return new BadRequestResult();
    
    }
    //prepare
    listing.UpdatedDate = DateTime.Now;
    //Update  
    await listings.AddAsync(listing);
    await listings.FlushAsync();
    
    return new OkObjectResult(listing);
}

Delete Listing

Output binding as well. Output Bindings are flexible, although I am using a SQL Text command, you can also use Stored Procedures for all of these.


[FunctionName("DeleteListing")]
public static IActionResult Run(
    [HttpTrigger(AuthorizationLevel.Function, "delete", Route = "listing/{id}")] HttpRequest req,
    [Sql("DELETE FROM [dbo].[Listings] WHERE Id = @Id", "SqlConnectionString", "@Id={id}")] IEnumerable<Object> result,
    ILogger log)
{
    return new OkResult();
}

Track Changes Trigger

You will also need to enable change tracking on your database:


ALTER DATABASE [Database]
SET CHANGE_TRACKING = ON
(CHANGE_RETENTION = 2 DAYS, AUTO_CLEANUP = ON);
ALTER TABLE [dbo].[Table]
ENABLE CHANGE_TRACKING;

The Change Feed trigger basically allows you to get notified when something happens in your database, it is very useful if you are in an event-driven/distributed architecture. Here is what the code looks like:


[FunctionName("ChangeFeedTrigger")]
public static void Run(
    [SqlTrigger("[dbo].[Listings]", "SqlConnectionString")]
    IReadOnlyList> changes,
    ILogger logger)
{
    foreach (SqlChange change in changes)
    {
        Listing listing = change.Item;
        //Do your action
        logger.LogInformation($"Change operation: {change.Operation}");
        logger.LogInformation($"Id: {listing.Id}, Title: {listing.Name}");
    }
}

For this particular code, here is a sample output after I insert and then update a record:


[2023-06-23T17:29:20.743Z] Change operation: Insert
[2023-06-23T17:29:20.744Z] Id: 0e5d476f-f450-4f09-965b-54c4ae5f1c96, Title: Casa Amore - Merida

[2023-06-23T17:31:11.349Z] Change operation: Update
[2023-06-23T17:31:11.350Z] Id: 7e4e7b10-6d5d-4b02-903d-1ffc93333f55, Title: Casa Amore - Merida

That's a Wrap

That is it, pretty simple and straightforward, it took way too long for this functionality to come to Azure Functions but is finally here.

Here is my source code for your reference. Remember is just a playground 😄

Here is the official documentation and more sample code (from MS).

Last thoughts…

Every time I do a RestAPI with Azure Functions I put them behind an API Management (APIM) service. Just saying….

Hope this helps 😎