That's the wrong question. And answering it is how you end up with an org-wide PAT checking out 14 repos at main on every build.

The better question is what does that repo publish? And right behind it, who runs whose tests? Answer those two and the rest of your pipeline design mostly falls out.

The Default Everyone Builds​

It usually looks like this:

- uses: actions/checkout@v7
  with:
    repository: acme/shared-lib
    ref: main
    token: ${{ secrets.ORG_WIDE_PAT }}
    path: shared-lib

Multiply by however many repos your build "needs." What you've actually built:

• Source coupling. Your build depends on whatever happens to be on someone else's main right now. They merge, you break, and nobody on their team ever sees the red.
• A non-reproducible build. Rerun yesterday's job and you get different code. Good luck bisecting.
• A long-lived secret with way too much reach. That PAT is tied to a person (or a "bot" account someone shares), can usually read far more than this one build needs, and lives forever. Exactly the kind of credential that shows up in supply chain incidents.

None of this is specific to GitHub Actions. You'd build the same mess in Jenkins.

Couple to Artifacts and Contracts​

Left side, every repo is part of every other repo's build. Right side, each repo has one job: build, test, publish a versioned thing. Consumers pin a version. Upgrades are PRs you can review and revert.

Honestly this is also why monorepo vs polyrepo is mostly the wrong argument. Big monorepos work because everything builds and tests together at one commit. Polyrepos work when repos talk through versioned contracts. What doesn't work is polyrepos pretending to be a monorepo by cloning each other at main. You get the costs of both and the benefits of neither.

1. Consume Artifacts, Not Source​

If another team's code is something you build against, it should be a package. npm, Maven, NuGet, a container image, whatever fits. GitHub Packages and the Container registry handle this fine, and the producer's workflow can push with GITHUB_TOKEN and packages: write. Consumers read with GITHUB_TOKEN too, once you grant their repos access to the package. No extra credentials.

Consumers pin an exact version and let Dependabot open the bump PRs. Point it at your private registries and group the updates so you don't drown in them. Now every upgrade runs your full CI before it lands, which is the whole point.

Sometimes you do need source (codegen, a vendored tool, whatever). Fine. Pin it to a full commit SHA, and if it matters enough, vendor it into your repo. Large monorepos do exactly this with third-party code for a reason. Never float on main.

2. Auth Without PATs​

Once you're consuming artifacts, most cross-repo access disappears. For what's left, stop minting PATs.

• Sharing actions and reusable workflows doesn't need a token at all. Turn on access for private repos or internal repos across your enterprise in the repo's Actions settings.
• Cloud credentials go through OIDC. No stored keys.
• Actual cross-repo API calls use a GitHub App installation token, scoped to the exact repos and permissions the job needs:

- uses: actions/create-github-app-token@v3
  id: app-token
  with:
    client-id: ${{ vars.CI_APP_CLIENT_ID }}
    private-key: ${{ secrets.CI_APP_PRIVATE_KEY }}
    owner: ${{ github.repository_owner }}
    repositories: shared-proto
    permission-contents: read

Yes, the private key is still a secret. But it isn't tied to a human, it can only mint tokens that expire in an hour, and every token is scoped to what you wrote down in the workflow. That's a much smaller blast radius than a PAT someone made in 2021 with repo scope.

3. Platform Owns the Pipeline​

If 400 repos each hand-roll their own build, every pipeline fix is 400 PRs.

Put the golden path in a central repo as reusable workflows. App repos call it with inputs and stay tiny:

name: CI
on:
  pull_request:
  merge_group:

permissions:
  contents: read
  packages: write
  id-token: write

jobs:
  ci:
    uses: acme/platform-workflows/.github/workflows/node-service.yml@v3
    with:
      node-version: 24

The platform team versions it, ships improvements once, and every repo gets them on the next bump. For the stuff that isn't optional (security scans, provenance, policy checks), enforce it with org-level ruleset workflows so it runs whether the app repo calls it or not.

4. Flip Integration Testing Around​

This is the one that changes the most, and the one almost nobody does.

The default: the consumer clones its dependencies and runs integration tests. So when shared-lib merges a breaking change, the failure shows up later, in somebody else's repo, owned by somebody who didn't make the change.

Flip it. The dependency triggers the consumer's tests. When a PR opens on shared-lib, it publishes a preview version (say 2.4.0-pr.123) and kicks off each known consumer's test suite with workflow_dispatch or repository_dispatch. The consumer runs its tests against that preview, then reports back by creating a check run on the producer's PR.

The producer side is one step with an App token that has permission-actions: write on the consumer:

gh workflow run contract-tests.yml -R acme/checkout-service \
  -f producer-repo=acme/shared-lib \
  -f producer-sha="$PR_HEAD_SHA" \
  -f version=2.4.0-pr.123

The consumer side:

name: Contract tests
on:
  workflow_dispatch:
    inputs:
      producer-repo:
        required: true
      producer-sha:
        required: true
      version:
        required: true

permissions:
  contents: read
  packages: read

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - uses: actions/setup-node@v7
        with:
          node-version: 24
          registry-url: https://npm.pkg.github.com
      - run: npm ci
      - run: npm install "@acme/shared-lib@$VERSION"
        env:
          VERSION: ${{ inputs.version }}
          NODE_AUTH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      - run: npm test

      - uses: actions/create-github-app-token@v3
        if: ${{ !cancelled() }}
        id: app-token
        with:
          client-id: ${{ vars.CI_APP_CLIENT_ID }}
          private-key: ${{ secrets.CI_APP_PRIVATE_KEY }}
          owner: ${{ github.repository_owner }}
          repositories: shared-lib
          permission-checks: write
      - if: ${{ !cancelled() }}
        env:
          GH_TOKEN: ${{ steps.app-token.outputs.token }}
          PRODUCER_REPO: ${{ inputs.producer-repo }}
          PRODUCER_SHA: ${{ inputs.producer-sha }}
          CONCLUSION: ${{ job.status == 'success' && 'success' || 'failure' }}
        run: |
          gh api "repos/$PRODUCER_REPO/check-runs" \
            -f name="consumer / $GITHUB_REPOSITORY" \
            -f head_sha="$PRODUCER_SHA" \
            -f status=completed \
            -f conclusion="$CONCLUSION" \
            -f details_url="$GITHUB_SERVER_URL/$GITHUB_REPOSITORY/actions/runs/$GITHUB_RUN_ID"

Why an App and not GITHUB_TOKEN? GITHUB_TOKEN is scoped to the repo it runs in, and write access to checks is only available to GitHub Apps. Bonus: make that check required on the producer and set your App as the expected source, so nobody can fake it with a random status.

Now the breaking change goes red on the PR that introduced it, in front of the person who wrote it, before it merges. That's the entire value of integration testing, delivered to the right person.

5. Make the Feedback Loop Fast​

All of this only works if CI is fast enough that people don't route around it.

• Merge queue. Add the merge_group trigger and let the queue test PRs together against the real tip of main. GitHub runs its own large monorepo on it: over 500 engineers merge 2,500 PRs a month through merge queue, with a 33% drop in average time to ship.
• Don't redo green work. Path filters, caching, and build tools that know what changed. If nothing in a service changed, don't test it again.
• Bigger machines. Larger GitHub-hosted runners are a runs-on change. Your engineers waiting 20 minutes on a 2-core box costs way more than the compute.

Microservices: Same Idea, Runtime Edition​

Microservices make this more obvious, not less. Services talk to each other at runtime, over the network. There's no reason one service's build should touch another service's source. Each one should build, test, and deploy on its own.

What they share is a contract, so treat the contract like the artifact:

• Publish API contracts as packages. Protobuf or OpenAPI specs, versioned and pinned like any other dependency.
• Break the build in the producer's PR. buf breaking for protobuf, or consumer-driven contracts with Pact, so removing a field fails CI on the service that removed it.
• Change schemas in two steps. Expand, migrate, contract. Add the new field, move consumers over, then remove the old one.
• Decouple deploy from release. Ship dark behind feature flags so deploying a service doesn't mean every other service has to be ready.
• Ephemeral environments for E2E smoke. Spin up a real environment per PR or per merge group for a handful of end-to-end checks, gated with environments. Not on every push, and not as your main line of defense.

And the honest diagnosis. If service A can't ship unless B and C ship with it, that's a distributed monolith. A monolith with network hops in the middle. Either fix the contracts so they can ship independently, or put them in one repo and build them together. Separate repos only pay for themselves if the things in them actually deploy separately.

Start Here​

Pick your worst build, the one with the most repository: lines in a checkout step. For each one, ask what that repo should be publishing instead. That list is your migration plan.

OIDC solves one thing: credential persistence. No more static keys sitting in a secret store waiting to leak. But it does nothing about the actual job of a pipeline, which is to execute arbitrary code on your behalf. Your keys are only one of the things that code can abuse, and most of the attacks landing in the wild right now never touch your OIDC token at all. They hijack the pipeline before identity is even in the picture.

So treat keyless auth as table stakes, not a finish line. Here's everything it leaves on the table.

The Workload Identity Paradox​

When you tie identity to the pipeline environment via OIDC, you're making one assumption: the code running in the pipeline is trustworthy.

It isn't. Pipelines exist to execute arbitrary code automatically. That's their whole job. The moment a developer account is compromised, or a malicious package slips into your tree during npm install, that script runs on a runner with the exact same trust as your real deploy step.

Now broker a network tunnel from that runner into your private subnet with Tailscale or Cloudflare Access and you've handed the attacker an authenticated bridge straight into your infra. Identity is tied to the environment, so the malicious code inherits the keys to the kingdom. This is exactly the failure mode behind real-world incidents like the tj-actions/changed-files compromise and the Codecov bash uploader breach.

Five Ways In That Have Nothing To Do With Your Keys​

Before you ever broker a token, an attacker has cheaper paths into your runner. None of these care whether you went keyless. And they don't stay contained: the 2026 wave of attacks, Megalodon, GhostAction, the Shai-Hulud worm, is self-propagating. A pipeline dumps its secrets, those secrets backdoor a package, the package compromises more developer machines, and those machines harvest more credentials. Your pipeline isn't just a target. It's a node in a worm, and every secret it leaks is a seed for the next hop. Containing the blast radius isn't only about protecting yourself; it's about refusing to be a vector.

Stolen credentials push workflows straight to main​

This is the single biggest vector in the wild right now, and it doesn't involve a fork or a dependency at all. An attacker gets a compromised PAT or gh CLI OAuth token (usually harvested from a previous supply-chain hop), commits a malicious workflow directly to main across every repo that credential can write to, triggers it to dump every secret, then deletes the runs with the same token so there's no public log. The root cause is structural: repository write access automatically grants secret access, with no second factor. The defense is to decouple the two: gate secret-bearing jobs behind a GitHub Environment with required reviewers, or pull them from an external secret vault via OIDC, so that write access alone can't silently exfiltrate anything.

Mutable tags get re-resolved on every run​

uses: owner/action@v2 looks like a pinned dependency. It isn't. It's a declaration the runner re-resolves on every single execution against a mutable git tag. Actions is effectively a package manager with no lockfile, no integrity hashes, and no transitive visibility, where the uses: line is re-resolved on every run. Compromise a maintainer's token, repoint v2 to an imposter commit, and every consumer pulls the malicious code on their next run with no PR, no diff, no warning. That's the entire mechanism behind the tj-actions and actions-cool/issues-helper mass tag rewrites. Pinning to a full commit SHA is the only thing that closes it, because a SHA is content-addressed and can't be repointed underneath you.

Cache poisoning crosses job boundaries​

The Actions cache is shared across jobs in a repo. That means a low-privilege job, the one running untrusted PR code or third-party dependencies, can write a poisoned entry that a later privileged job restores and trusts. The cache is a covert channel straight through any isolation you think you built. The TanStack compromise used exactly this as its escalation vector. Treat restored cache as untrusted input, scope reads and writes as discrete permissions so a sensitive deploy can be granted neither, and keep caching off your privileged paths entirely.

pull_request_target runs attacker code with your secrets​

A pull_request_target workflow runs in the context of your base repo, with secrets in scope, but it's triggered by forked PRs from anyone. The trigger itself isn't the bug. The bug is pull_request_target plus checking out the PR's head or merge ref plus executing it, which is when a stranger's code runs with your secrets. It's the classic pwn request. The same shape shows up on other privileged triggers, and they're easier to overlook: workflow_run hands you artifacts a pull_request run uploaded, and treating that artifact's contents as trusted (extracting it into your workdir, reading a "PR number" an attacker actually controls) is the same vulnerability one step removed. issue_comment and label-driven ops add a time-of-check/time-of-use twist: you approve a PR once, but the checkout runs on every comment, so the attacker pushes a fresh malicious commit after approval. Never check out and run untrusted PR code in a privileged trigger, never trust an artifact from a less-privileged run, and default every workflow to permissions: {} so nothing is in scope unless you explicitly grant it.

Dependency confusion resolves your private action to a public impostor​

This one is subtler because the workflow file never changes. An action or a build step references a dependency it assumes lives in your private registry. The private copy goes away, the name fails to resolve internally, and resolution silently falls back to a public registry where it was never published. An attacker who registered that name in the public namespace gets their code executed instead. It's the dependency confusion attack Alex Birsan used to breach Apple, Microsoft, and dozens of others, and the same fallback exists anywhere you mix public and private resolution, including self-hosted GitHub setups that resolve missing actions from github.com. Pin the source, not just the version: be explicit about which registry or host a dependency comes from, and never let a private name silently resolve to a public one.

Limiting the Blast Radius​

Stop building a taller wall around the credentials. Isolate the execution environment instead. Five moves.

1. The "Build vs. Deploy" airgap​

Never request your OIDC token in the same job that fetches third-party dependencies or runs tests. Split the workflow into two isolated jobs:

• The dirty room (build). Runs npm install, tests, and your build. No id-token permission here. Poison a dependency and it finds no credentials and no network. Output is a compiled, signed artifact.
• The vault (deploy). Depends on the build passing, downloads the verified artifact, and is the only job that requests the OIDC token. No third-party code runs here, so the token stays clean.

One catch: an airgap built only on job boundaries leaks through the shared cache. If the dirty room can write a cache entry the vault restores, you've reconnected the two rooms through the back door. Keep caching out of the deploy job, and gate that job behind a GitHub Environment with required reviewers, scoping your IAM trust policy to that environment's sub claim.

And make that claim hard to spoof, because OIDC is only as strong as the trust condition you write against it. Prefer an immutable identifier like repository_id over a mutable repo:owner/name string, since repos get renamed and re-created but IDs don't, and reach for job_workflow_ref to pin the exact workflow file when you're federating reusable workflows. GitHub recently shipped immutable subject claims to close one spoofing gap, but the cloud side still has to ask for the strict claim, and note that aud is attacker-influenced and unvalidated by GitHub, so your provider has to check it. A wildcard sub match is a keyless credential anyone in your org can mint.

2. Egress filtering at the runner level​

Once an attacker has code execution, the next step is exfiltrating the token or pulling a second-stage payload. Secret masking won't save you here: the runner redacts known secret values from logs, but a hijacked step can base64-encode a token to slip past the masker and POST it straight out. Masking stops accidental logging, not deliberate exfiltration. So kill it at the kernel. Tools like StepSecurity Harden-Runner use eBPF to enforce network egress policies on the runner. Allowlist github.com, your package registries, and your target cloud endpoints. A hijacked script that tries to curl a random IP dies on the spot, and you get an audit trail of what it tried to reach.

On GitHub-hosted runners the platform-level version of this is GitHub's native egress firewall: a Layer 7 allowlist that runs outside the runner VM, so it holds even if an attacker gets root inside the job. Until it's GA you can approximate it by pulling the allowed-domain list from the meta API and refreshing your firewall on a schedule. Either way the principle is the same: network controls belong at the network layer, not bolted onto a runner an attacker may already control.

3. Absolute dependency pinning​

Now make the SHA discipline from above operational and complete. Pin every Action to a full commit SHA, never a tag like @v2. Strip ^ and ~ from package.json and commit a lockfile, then use npm ci for reproducible installs. Turn on Dependabot to bump those SHAs safely, since the moment you pin to a commit you've opted out of automatic updates and Dependabot is what keeps the pin current (it understands SHA-pinned actions and rewrites the SHA with a version comment). Pair it with Dependabot alerts, which cross-reference the GitHub Advisory Database so a dependency with a known published vulnerability gets flagged and auto-PR'd instead of sitting silently in your tree. Then require CODEOWNERS approval plus a branch protection rule on anything touching .github/, so Dependabot can open the PR but a human still has to approve the change and it never becomes its own auto-merge backdoor. Pin your runner's tools too with actions/setup-node and consider allowed_actions policies at the org level.

One honest limit: pinning your top-level uses: to a SHA does nothing for the transitive actions those actions call, which still resolve their own tags at runtime. You can't hand-pin that tree today, which is exactly why native workflow dependency locking is on GitHub's roadmap. Until it lands, prefer actions with shallow dependency trees and pin what you can.

Two sharp edges even a SHA pin doesn't sand down. First, imposter commits: you can reference a commit that lives in a repo's fork network but was never in the parent repo itself, so the SHA looks legitimate while pointing at attacker code that no maintainer ever merged. This was the trick behind the Trivy action compromise, and the real fix is a commit reachability check, confirming the SHA is actually reachable from the repo's own branches, not just resolvable. You can scan for these today with a dedicated imposter-commit detector before you trust a pin. Second, repo-jacking: rename owner/action, GitHub redirects the old name seamlessly, an attacker re-registers the vacated name, and consumers who never updated silently pull the new malicious repo. A SHA pin tied only to owner/repo doesn't save you here; durable protection means pinning to the immutable repository ID, which doesn't survive a takeover. And worth knowing: Git's SHA-1 is cryptographically weakening and the ecosystem is migrating to SHA-256, so a pin is strong today but not eternal.

The cheapest pin of all is the dependency you never take. Actions inherited npm's culture, not Go's: where the Go community leans on a fat standard library and treats every third-party import as a liability, the Actions ecosystem encourages reaching for a marketplace action for everything. That breadth is exactly why a single compromised action immediately compromises every consumer. Audit your uses: list the way you'd audit package.json, drop the actions you could replace with a few lines of shell, and you shrink the attack surface before any pinning even matters.

4. Granular network scoping​

If the OIDC token brokers a Zero Trust connection, enforce least privilege on the tunnel itself. Don't route to the whole VPC. Route to the single IP and port the deploy actually needs, scoped with a security group or Tailscale ACL tag. The token should be a key to one door, not the building.

The same discipline applies to how the runner reaches your network in the first place. Hosted runners get a few sanctioned bridges into private resources, in increasing order of real isolation: static IP allowlisting on larger runners (easy, but it's still public-internet IP trust and a static target worth questioning), an API gateway fronted by OIDC, and Azure VNet injection, where the runner pulls an IP from your subnet and you own the NSGs. VNet injection is the most complete, but mind the edges: each concurrent job consumes one IP, so size the subnet (a /27 minimum) or jobs stop queueing, and a firewall doing TLS inspection breaks runners that won't trust your internal CA. The throughline across all three is to move the trust boundary off public-IP reputation and onto identity wherever you can.

5. Lint the workflows themselves​

Most of the mistakes above are detectable statically. Run zizmor over your .github/workflows to catch dangerous triggers, missing permissions: blocks, unpinned actions, and template-injection sinks before they ship, and wire it into CI so a risky pattern fails the PR. GitHub's own CodeQL Actions analysis covers similar ground and is free for public repos. Neither one catches a malicious dependency, that's what the pinning and isolation above are for, and Dependabot alerts handle the known-vulnerable ones, but they're the cheapest way to stop your own workflows from being the hole.

The Bottom Line​

OIDC for CI/CD is non-negotiable, but it's only the authentication layer, and most real-world attacks never reach it. They hijack the runner first through a stolen write token, a mutable tag, a poisoned cache, or a fork PR running with your secrets, and then they worm onward using whatever they steal. You can't scan your way out of this either: the minimal backdoor is swapping one trusted SHA for a malicious one, which defeats any string or pattern matching and turns detection into cat-and-mouse. The durable fixes are structural, not reactive. Without SHA pinning, cache discipline, locked-down triggers, write access decoupled from secrets, job isolation, egress filtering, and real observability into what your runners are doing, you haven't eliminated the risk. You've moved it deeper into the pipeline where it's harder to see.

Trust the identity. Verify the execution. For the full checklist, GitHub's security hardening guide and the OpenSSF Scorecard are the right places to start.

This is part 5 of a series on AI-native CI/CD. See also: Automation is The Obvious Choice, GitHub Actions: The AI-Native Platform, Agentic Workflows on GitHub Events, and Prompt Design for Headless Agents.

The Local Machine Bottleneck​

Right now, you're running one agent in your IDE. Maybe a second one on a coding task. That's about all your local machine can handle.

But where this is going is many agents, working in parallel, each on a different task. And that breaks the local machine model:

• Each agent needs its own isolated workspace, you can't have 5 agents editing the same files
• Different agents need different permissions and boundaries, a security scanning agent shouldn't have the same access as a deployment agent
• Performance becomes a real constraint, local CPU, RAM, disk I/O can't scale to 10 concurrent agent sessions
• Security, agents running LLM-generated code on your local machine is a risk surface you don't want to manage

Right now, you fire up Copilot in VS Code and it works great. But what happens when you want to spin up 5 agents, each working on a different issue, each in its own isolated environment, each with scoped permissions? Your laptop will struggle with that.

Why Not Just Use CI Runners?​

Fair question. Actions runners are purpose-built for async CI/CD jobs, fire-and-forget pipelines that start clean and end clean. That's perfect for builds and deployments. But agents need fundamentally different compute:

CI runners will still be the right answer for CI/CD. But agent compute is a different problem space.

What Agent Compute Looks Like​

The industry is converging on a new compute layer purpose-built for agentic workloads. The core requirements:

1. MicroVMs, Not Full VMs​

Full VMs are overkill for an agent that needs to run for 30 seconds. MicroVM architectures (think Firecracker, CloudHypervisor) provide:

• Sub-second startup
• Strong isolation (hardware-level, not just containers)
• Dramatically lower cost per invocation
• OCI image support for custom environments

2. Snapshot/Resume​

Agents aren't purely autonomous. They hit decision points where a human needs to review. The compute needs to support:

• Save full state (memory, disk, execution context)
• Hand off to a human for review
• Resume exactly where it left off

This is the biggest gap in current CI systems. Every CI runner is fire-and-forget. Agent compute needs to be pause-and-resume.

3. Scoped Permissions Per Instance​

Each agent instance needs its own permission boundary:

• Agent A can read code + write PRs
• Agent B can read issues + write labels
• Agent C can deploy to staging, not production

This goes beyond repo-level GITHUB_TOKEN scoping. It's per-agent identity and access control.

4. Enterprise Governance​

At scale, you need:

• Auditability, who spawned which agent, what did it do, what resources did it touch
• Network controls, VNET/firewall integration per agent instance
• Policy enforcement, which models can be used, which tools are allowed, cost limits per run
• Identity, tied to the developer who spawned it, not a shared service account

The Compute Stack Is Converging​

What's becoming clear is that the modern development platform needs three distinct compute layers, each purpose-built for its workload:

GitHub already has the first two: Actions for CI/CD, Codespaces for development. The third layer, agent compute, is where GitHub and the entire industry is heading.

The Competitive Landscape​

Everyone sees this opportunity. Vercel, Docker, Deno, E2B, Daytona, all building sandbox compute for agents. The differentiator will be:

• Platform integration, how deeply the compute layer connects to the developer's existing workflow
• Governance, enterprise controls, audit trails, compliance
• Agent-native primitives, snapshot/resume, scoped permissions, tool allowlisting

The platforms that win will be the ones that make agent compute feel as natural as running a CI job today.

What You Should Do Now​

You don't have to wait for dedicated agent compute to start building agentic workflows. The pieces are already in place:

1. Start with Actions, run agents in CI today using Copilot CLI or GitHub Agentic Workflows
2. Use GitHub-hosted runners, ephemeral, isolated, zero-maintenance compute that's ready for agentic workloads
3. Build the prompt architecture, design for headless execution now and you'll be ready when dedicated agent compute arrives
4. Invest in your CI/CD suites, the stronger your test/lint/scan pipeline, the more autonomy you can safely give agents

The future of compute is converging. Actions is the foundation everything else builds on. Start there.

📊 View the visual presentation →

This post is part of a series on AI-native CI/CD. Start from the beginning: Automation is The Obvious Choice.

This is part 4 of a series on AI-native CI/CD. See also: Automation is The Obvious Choice, GitHub Actions: The AI-Native Platform, Agentic Workflows on GitHub Events, and The Future of Developer Compute.

The Aha Moment​

You don't have to build the engine. You just have to build the guardrails.

When you write prompts for built-in orchestrators like Copilot CLI, you're not writing a traditional "prompt." You're writing a configuration file for an execution engine.

These agents already have a programmatic while loop running under the hood: Reason → Act → Observe → Repeat. If your prompt tries to manually dictate "do this, then loop back," you'll clash with the agent's native programming.

Interactive Agents: 5 Strategies​

1. Stop Micromanaging the Loop​

Don't tell the agent how to loop. Tell it what tools it has and what the finish line looks like. Let the agent's native backend handle execution cycles.

2. Define Strict Exit Criteria, and Enforce Them with Hooks​

Autonomous agents either give up too early or loop forever. Give it an undeniable, physical checklist:

"You may not consider this task complete until output.md is written to disk AND the YAML frontmatter contains the required fields."

But prompts are suggestions. Hooks are enforcement.

Agent hooks let you gate the agent's lifecycle with deterministic code. The Stop hook is the killer feature. It fires when the agent tries to stop, and you can block it with a script that runs a real check:

{
  "hooks": {
    "Stop": [
      {
        "type": "command",
        "command": "./scripts/validate-output.sh"
      }
    ]
  }
}

Your script checks the actual deliverables and returns:

{
  "hookSpecificOutput": {
    "hookEventName": "Stop",
    "decision": "block",
    "reason": "output.md is missing the enterprise_slug field. Add it before finishing."
  }
}

The prompt says "don't stop until X is done." The hook enforces it. The script runs a deterministic check: does the file exist? Does it pass validation? If it fails, the agent gets a new prompt injected telling it exactly what's still missing.

This is the bridge between non-deterministic AI and deterministic automation.

All 8 Hook Lifecycle Events​

Powerful patterns:

• PreToolUse, block dangerous commands regardless of what the agent was prompted to do
• PostToolUse, auto-run linters after every file edit, inject "you have lint errors, fix them" back into the conversation
• SessionStart, inject project context so the agent starts informed

3. Externalize Memory to the File System​

Context windows get bloated. Agents forget what step they're on. Force the agent to write state to a file (.agent-state.md, sync-plan.json). If it crashes, it reads the file to resume.

4. Constrain the Blast Radius​

Agents are curious. If they can't find data, they start running grep across your entire workspace, wasting time and tokens.

Explicit whitelist:

"You may ONLY use the copilot-cli action and the GitHub MCP tools. DO NOT use system grep or workspace-wide searches."

5. Establish Yield Protocols​

When a tool breaks, agents hallucinate workarounds or bash the same broken command repeatedly. Define exactly when to stop:

"If the API returns a 401, move on."

Going Headless: What Changes When There's No Human​

Taking an agent out of your IDE and putting it on a background cron job is the final boss of agentic workflows. If you just schedule your interactive prompt to run every hour, it will eventually hang, wait for input that never comes, and silently burn through your compute budget.

1. Do not Yield​

Replace "ask the user" with "log the error and terminate."

"Under NO circumstances should you ask for clarification. If you lack data after 2 retries, write to logs/failed_runs.log and terminate immediately."

2. Design for Idempotency​

If the script runs every hour, the first task is checking: "Did I already do this?"

"Read notes/YYYY-MM-DD/. If output already exists for this run, output 'previously completed' and terminate."

3. Pre-Authenticate Everything​

No az login --use-device-code. No browser SSO. None of that works headlessly. Your infrastructure must inject pre-authenticated tokens or managed identities as environment variables BEFORE the agent spins up.

"Assume all tools are pre-authenticated. If you get a 401, log 'Auth Pipeline Broken' and terminate."

4. Hardcode Loop Limits​

In your IDE, you can Ctrl+C a rogue agent. On a server at 3 AM, it can loop 200 times and cost $50 before you wake up.

"Maximum 10 tool calls per execution. If the task isn't complete, compile what you have, write the output, and terminate."

5. Shift to Audit Logging​

No one is watching the terminal. The agent's reasoning must be written to a permanent file.

"Append your reasoning, tool choices, and errors in JSON to audit.jsonl before each action."

The Prompt Templates​

Headless Agent Prompt (No Human)​

1. <objective>              The specific, narrow task for this run
2. <idempotency_check>      Check if work was already done
3. <authorized_tools>       Restricted tool whitelist
4. <headless_constraints>   No questions, no interactive auth, max N loops
5. <failure_protocol>       Where to log errors, then terminate
6. <exit_criteria>          Definition of "done" → save and shutdown

Example: Headless Daily Audit Agent​

- uses: austenstone/copilot-cli@v3
  with:
    autopilot: true
    no-ask-user: true
    prompt: |
      <objective>
      Audit open issues labeled "needs-triage" and add priority labels.
      </objective>

      <idempotency_check>
      Check if today's audit log exists at logs/audit-YYYY-MM-DD.jsonl.
      If it does, output "previously completed" and terminate.
      </idempotency_check>

      <authorized_tools>
      GitHub CLI (gh issue list, gh issue edit). Nothing else.
      </authorized_tools>

      <headless_constraints>
      - Do NOT ask for clarification. Ever.
      - Maximum 20 tool calls.
      - No interactive authentication.
      </headless_constraints>

      <failure_protocol>
      On any error after 2 retries: log to logs/failed_runs.log and terminate.
      </failure_protocol>

      <exit_criteria>
      All "needs-triage" issues have been labeled. Write results to
      logs/audit-YYYY-MM-DD.jsonl with issue numbers and assigned labels.
      </exit_criteria>

The prompt IS the configuration. Get it right and the engine runs itself.

📊 View the visual presentation →

Next up: The Future of Developer Compute. Your laptop is about to stop being where work happens.

This is part 3 of a series on AI-native CI/CD. See also: Automation is The Obvious Choice, GitHub Actions: The AI-Native Platform, Prompt Design for Headless Agents, and The Future of Developer Compute.

There are five ways to use AI in Actions, from simple inference to full agent frameworks.

1. Copilot Models: Basic Inference​

Before you reach for agents, sometimes all you need is a single LLM call. Copilot Models lets you call AI models directly from a workflow step. No agent loop, no tool use, just prompt in → response out.

This is perfect for tasks that don't need autonomy:

• Validate a PR title or description against a convention
• Classify or label an issue
• Generate release notes from a diff
• Summarize a changelog
• Generate mock data for tests

Example: Auto-Label Issues​

name: Auto-Label Issue
on:
  issues:
    types: [opened]

permissions:
  issues: write
  copilot-requests: write

jobs:
  label:
    runs-on: ubuntu-latest
    steps:
      - uses: austenstone/copilot-models@v1
        id: classify
        with:
          prompt: |
            Classify this GitHub issue into exactly one category:
            bug, feature, question, documentation

            Title: ${{ github.event.issue.title }}
            Body: ${{ github.event.issue.body }}

            Respond with ONLY the category label, nothing else.
      - run: gh issue edit ${{ github.event.issue.number }} --add-label "${{ steps.classify.outputs.response }}"
        env:
          GH_TOKEN: ${{ github.token }}

No agent loop. No tool calling. Just a single inference call that returns a label. Sometimes that's all you need.

2. Copilot Coding Agent: Assign and Walk Away​

The Copilot Coding Agent is the simplest way to get an AI agent working on your code. Assign it to an issue, and it spins up on a GitHub-hosted runner, plans the fix, writes the code, runs tests, and opens a PR, all autonomously.

You can trigger it manually from the GitHub UI, or chain it from a workflow:

1. A workflow event fires (e.g., a new issue is labeled autofix)
2. A step assigns Copilot Coding Agent to the issue
3. CCA spins up on an ephemeral GHR, plans, codes, tests, opens a PR

Fully automated chain: event → agent → PR → review. No human in the loop until it's time to merge.

This is the zero-config option. No prompts to write, no YAML to author. If your task maps to a well-scoped issue, CCA just handles it.

3. GitHub Agentic Workflows (gh aw): The Paved Path​

GitHub Agentic Workflows is purpose-built for repository automation, running coding agents with strong guardrails in GitHub Actions.

Why to do it this way:

• Markdown-defined workflows, write automation in markdown, not complex YAML
• Event-triggered + scheduled like on: schedule: daily, on: issues, on: pull_request, etc.
• Multiple AI engines including Copilot, Claude, Codex, and custom AI processors
• Guardrails built-in:
  • Read-only permissions by default
  • Write operations require explicit approval through sanitized "safe outputs"
  • Sandboxed execution, tool allowlisting, network isolation

Example: Daily Issues Report​

This entire automation is defined in markdown:

on:
  schedule: daily
permissions:
  contents: read
  issues: read
  pull-requests: read
safe-outputs:
  create-issue:
    title-prefix: "[team-status] "
    labels: [report, daily-status]
    close-older-issues: true

## Daily Issues Report
Create an upbeat daily status report for the team as a GitHub issue.

## What to include
- Recent repository activity (issues, PRs, discussions, releases)
- Progress tracking and highlights
- Actionable next steps for maintainers

Use Case Gallery​

• Issue & PR Management, automated triage, labeling, project coordination
• Continuous Documentation, automated maintenance and consistency
• Continuous Improvement, daily code simplification, refactoring
• Metrics & Analytics, daily reports, trend analysis, workflow health
• Quality & Testing, CI failure diagnosis, test improvements
• Multi-Repository, feature sync and cross-repo tracking

This is the paved path. If you're starting with agentic repo automation, start here.

4. Copilot CLI in Actions: The Raw Power​

Run Copilot CLI directly in your workflow steps. The same agent you use in VS Code or your terminal, but triggered on any GitHub event.

Action: austenstone/copilot-cli (v3)

Key capabilities:

• copilot-requests: write permission, uses the default GITHUB_TOKEN, no PAT required
• Full autopilot mode: autopilot: true, no-ask-user: true for fully autonomous CI
• MCP server support for extending Copilot with custom tool integrations
• Model selection including Claude, GPT-5, etc.
• Session management to resume, share sessions as markdown or gists

Example: AI PR Review on Every Pull Request​

name: 'Copilot Automation'
on: [pull_request]

permissions:
  copilot-requests: write
  pull-requests: write

jobs:
  copilot:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - uses: austenstone/copilot-cli@v3
        with:
          prompt: |
            Review this pull request for:
            1. Code quality and best practices
            2. Security vulnerabilities
            3. Performance implications
            4. Documentation completeness

5. Copilot SDK: Full Control​

If you need the raw model APIs, custom orchestration, or your own agent framework, the Copilot SDK gives you that. Build your own agents with the same models that power Copilot, running in Actions.

This is the power user escape hatch for teams building custom AI tooling on top of the Copilot models.

Choosing Your Approach​

Start with Copilot Models for single inference calls. Use the Coding Agent when the task maps to an issue. Reach for gh aw for recurring repo automation. Use Copilot CLI when you need full CI integration with custom prompts. Drop to the SDK when you need complete control.

📊 View the visual presentation →

Next up: Prompt Design for Headless AI Agents, the part nobody talks about. How do you write prompts that work when there's no human at the keyboard?

This is part 2 of a series on AI-native CI/CD. See also: Automation is The Obvious Choice, Agentic Workflows on GitHub Events, Prompt Design for Headless Agents, and The Future of Developer Compute.

Why Actions Is Purpose-Built for AI​

LLMs Understand It Best​

GitHub Actions has the largest usage base of any CI platform, which means the most training data for LLMs. AI models write better Actions YAML than any other CI system because they've seen more of it. More examples, more documentation, more community workflows → better AI-generated output.

Building Block Architecture Is Perfect for AI​

Actions' composable approach (actions, reusable workflows, composite actions) creates black boxes with clear interfaces. AIs excel when they can reason about well-defined inputs/outputs without understanding internal complexity.

uses: actions/checkout@v5 is easier for an LLM than "write the equivalent 20 lines of shell script."

Reusability = Token Efficiency​

Reusable workflows, shared actions, org-level templates → call once, use everywhere. Token efficiency matters when agents are running 10x more jobs.

Actions does this better than any competitor: reusable workflows across repos, composite actions, the Actions marketplace with 20K+ pre-built blocks. Every time you call a pre-built action instead of inline script, you save tokens AND reduce error surface.

Repo-Centric Security = Safe by Default​

Actions' limited, per-repo permission model is secure by default. No global admin key that unlocks everything. Developers can go wild experimenting → organizational governance via org-level policies, required workflows, IP allow lists.

This is critical for agentic workloads: you WANT agents to experiment freely within a safe boundary. Reduces friction → faster adoption → compounding AI value.

What's Already Running on Actions​

Before we talk about what you can build, let's talk about what's already running on Actions — things you use every day that you might not realize are Actions under the hood.

If you're using Copilot Code Review, that's Actions. Dependabot? Actions. CodeQL scanning? Actions. GitHub Pages? Actions. Codespace prebuilds? Actions. The Coding Agent? Actions.

The Execution Layer​

Actions is the compute substrate that much of the GitHub platform runs on. Every feature listed above is just a workflow triggered by a GitHub event, running on a runner, producing an output. The same primitives you use for CI/CD.

This matters because it means you can build on that same layer. The same event triggers, the same runner infrastructure, the same security model that powers GitHub's own features — all available to you.

The Event System​

GitHub exposes dozens of webhook events that can trigger workflows:

• push, pull_request
• issues, issue_comment
• discussion, discussion_comment
• schedule
• workflow_dispatch
• etc.

Every one of these is a hook you can attach automation to. And with AI agents now cheap enough to run on any event, the question shifts from "what can we automate?" to "what should we automate first?"

Why This Matters for AI​

The fact that Actions is the platform — not just a CI tool — has a compounding effect on AI adoption:

1. One execution model to learn. If you know how to write a workflow, you know how to orchestrate an AI agent.
2. One security model. Permissions, secrets, OIDC — all the same whether you're building a Docker image or running an LLM.
3. One observability story. Workflow logs, job summaries, Actions Data Stream — the same tools for CI and for agent monitoring.
4. Network effects. Every improvement GitHub makes to Actions benefits your CI/CD AND your AI automations simultaneously.

The Thesis: AI Amplifies CI/CD​

AI agents are non-deterministic by nature. They generate different code each time, make judgment calls, and experiment. You need strong deterministic automation suites wrapped around them (tests, linting, security scanning, deployment gates) to catch what agents get wrong.

Without robust CI/CD, you're shipping AI-generated code with no safety net. CI/CD is the guardrail layer that makes agentic workflows safe enough to trust. The better your CI/CD pipeline, the more autonomy you can give your agents, and the more value you get from them.

The more you delegate to agents, the more you need ironclad testing, scanning, and validation to catch what they get wrong. CI/CD isn't a nice-to-have anymore. It's the control plane for AI-generated code.

Why GitHub-Hosted Runners​

The platform story matters, but so does where the agents run. There are five operational concerns that matter when choosing runner infrastructure: Security, Performance, Availability, Total Cost of Ownership (TCO), and Troubleshooting. GHRs win on all five.

Security: Ephemeral by Default​

Imagine someone gets onto a self-hosted runner in your data center through a supply chain attack, a compromised npm package, a malicious action, a poisoned container image. They now have a foothold inside your network. From a self-hosted runner, they can potentially reach your internal services, your databases, your secrets. That runner persists between jobs. It's on your network.

GitHub-hosted runners (GHRs) eliminate this:

• Ephemeral — fresh VM every job, destroyed after. No persistence, no lateral movement.
• Isolated — no shared state between jobs, even from the same repo
• Network-isolated by default — VNET injection only when YOU choose to open access
• GitHub owns the SLA — patching, hardening, compliance is GitHub's problem

Now multiply that risk by what agents do. AI agents run code they generate themselves. They install packages. They make API calls. They iterate. If that's happening on a persistent runner in your network, that's a surface area problem. On ephemeral GHRs, every agent run starts clean and ends clean.

Right-Sizing with Telemetry​

Most teams pick ubuntu-latest and never think about it again. That's leaving performance and money on the table.

GitHub doesn't offer built-in per-step compute telemetry (CPU, memory, disk I/O) out of the box. But you can add it yourself with OpenTelemetry. The simplest approach is a drop-in action like Workflow Telemetry:

steps:
  - uses: tsviz/actions-runner-telemetry@v1

This gives you per-step CPU usage, memory consumption, disk I/O, and network stats right in your workflow summary. No config, no infrastructure. One line.

For deeper instrumentation, the OpenTelemetry CI/CD Action exports full OTLP traces that you can ship to Datadog, Honeycomb, Grafana, or any OTEL-compatible backend. Now you're not just seeing "this job took 8 minutes," you're seeing which steps were CPU-bound, which were waiting on network, and where memory peaked.

If you're using custom runner images (and you should be), you can go even further: install the OpenTelemetry Collector directly on the base image. Every workflow that runs on that image gets telemetry for free without any workflow changes.

This data is what lets you right-size. If your 8-core runner is peaking at 30% CPU, drop to a 4-core. If your builds are OOM-killing on a 2-core, step up. Without telemetry, you're guessing. With it, you're making data-driven decisions that directly impact cost and performance.

Custom Runner Images​

Step two is what's ON the runner when it starts.

• Pre-install your dependencies, SDKs, build tools in the image
• Attach caches directly to the image — no download step, no cache miss
• Use pre-job and post-job hooks for setup/teardown automation

Real example: the github/github repo went from ~60 min builds to <10 min builds — a 6x improvement from image optimization alone. Not code changes. Not runner changes. Just baking dependencies into the image.

Private Networking​

The #1 objection I hear: "We'd love to use GitHub-hosted runners, but we need to reach private resources."

There are multiple ways to solve this depending on your cloud provider, and none of them require self-hosted runners.

Azure: VNET Injection​

The most native option. Azure Private Networking lets GitHub provision GHRs directly into your Azure VNET with a private NIC. You pick the region, GitHub spins up ephemeral VMs that flow through your private network.

• Access private container registries, internal APIs, databases with no VPN, no bastion
• Combine with OIDC for zero-trust auth, no long-lived secrets
• Available for Linux, Windows, AND macOS

This isn't "connecting" to your network. The runner is on your network.

AWS & GCP: OIDC + API Gateway​

For AWS and GCP, the pattern is OIDC federation paired with an API gateway. GitHub Actions mints a short-lived OIDC token per job. Your cloud provider validates that token and grants scoped, temporary credentials.

AWS: Use OIDC federation with IAM to assume roles. For private resources behind a VPC, front them with API Gateway (with IAM auth) or AWS PrivateLink. The OIDC claims (repo, branch, environment) become your access control policy. No static keys anywhere.

GCP: Same concept via Workload Identity Federation. Authenticate as a service account scoped to the specific repo/environment, then hit private resources through Identity-Aware Proxy or a Cloud Endpoints gateway.

In both cases, OIDC claims are the key. You're not granting "GitHub Actions" access to your cloud. You're granting this specific repo, on this specific branch, in this specific environment access to exactly the resources it needs.

Any Cloud: Tailscale / WireGuard Overlay​

For teams that span multiple clouds or have on-prem resources, a mesh VPN overlay like Tailscale or WireGuard is a clean solution. Install the Tailscale client as a workflow step, authenticate via OIDC, and the ephemeral runner joins your tailnet for the duration of the job.

- uses: tailscale/github-action@v3
  with:
    oauth-client-id: ${{ secrets.TS_OAUTH_CLIENT_ID }}
    oauth-secret: ${{ secrets.TS_OAUTH_SECRET }}
    tags: tag:ci

The runner gets a Tailscale IP, can reach any node on your tailnet, and the connection dies with the VM. Works across AWS, GCP, Azure, and on-prem simultaneously. Most teams combine this OIDC claims.

Whatever your cloud, the networking story is solved. This is a proper and modern network security model.

Availability: GitHub Owns the SLA​

Self-hosted runner fleets are an operational burden that never sleeps. Someone on your platform team is responsible for uptime, patching, scaling, and disaster recovery. When a runner goes down at 2 AM, that's your page.

With GHRs, GitHub owns all of it:

• Auto-scaling — burst from 10 to 500 concurrent runners instantly, no capacity planning
• Multi-region — GitHub provisions in multiple regions, no single point of failure
• Zero maintenance — OS patches, security updates, runner agent upgrades, all handled by GitHub
• 99.9% SLA — backed by GitHub's infrastructure team, not your on-call rotation

Your platform engineers should be building internal developer platforms, not babysitting runner fleets.

TCO: The Buffet Minute​

The sticker price of GHRs looks higher per-minute than running your own VMs. But sticker price is the wrong lens. GHRs are an all-inclusive "buffet minute": compute, networking, storage, OS licensing, patching, monitoring, scaling, and incident response are all baked in.

Self-hosted runners carry massive hidden costs:

• Headcount — someone has to manage the fleet (ARC/K8s clusters, VM images, autoscaling)
• Idle compute — you're paying for VMs sitting empty between jobs
• Networking egress — data transfer costs that don't show up on the runner bill
• Incident response — when runners break, your pipeline stops and developers wait

The January 2026 30% price drop on GHRs shifted the math dramatically. For most organizations, GHRs are now cheaper than self-hosted when you account for total cost of ownership.

Troubleshooting: One Pane of Glass​

When a build fails on a self-hosted runner, the debugging surface area is enormous. Is it the runner? The network? A stale cache from a previous job? A dependency that was installed by another workflow and left behind? An OS patch that changed behavior?

GHRs collapse the troubleshooting space:

• Clean every time — if it worked yesterday and fails today, the runner isn't the variable
• Standardized environment — same OS, same tools, same network config across all runs
• Workflow logs — complete step-by-step execution logs, no SSH-ing into machines
• Actions Data Stream — real-time telemetry fed into Datadog, Splunk, Elastic for org-wide observability
• Job summaries — structured output right in the PR, no digging through CI artifacts

When something breaks, you're debugging your code, not your infrastructure. That's a fundamentally different (and faster) troubleshooting experience.

The Full Picture​

Convenient? Yes. But the real value is security, availability, and freeing your platform team from runner management.

📊 View the visual presentation →

Next up: Agentic Workflows on GitHub Events — triggering AI agents on any GitHub event, safely and autonomously.

This is part 1 of a series on AI-native CI/CD. See also: GitHub Actions: The AI-Native Platform, Agentic Workflows on GitHub Events, Prompt Design for Headless Agents, and The Future of Developer Compute.

The Trap: Doing the Same Work Faster​

If you're using Copilot or a coding agent today, you've probably noticed you're crushing Jira tickets in a fraction of the time. That feels great. But here's the thing: being able to write code faster doesn't mean you can ship 10x faster. The bottleneck was almost never your programming abilities or typing speed.

Where Is Your Time Actually Going?​

Writing code? Maybe 20% of your day. The rest:

• Code reviews
• Debugging CI failures
• Triaging issues
• Updating docs
• Fixing flaky tests
• Provisioning infrastructure
• Responding to alerts
• Context-switching between repos

Everyone should constantly be asking: "What am I spending my time on, and can this be automated?"

That's what we do. We're engineers. We solve problems and we automate.

The Old Automation Math​

Automation was always valuable, but the ROI bar was high. Building an automation had to be worth the time investment. It needed large scale and a long lifetime to justify the cost.

So most teams... didn't automate. It was easier to just do the task manually. This becomes the norm. Organizations sink into it. Manual processes calcify. "That's just how we do it."

GitHub Actions was built to change this:

• Remove as much friction as possible, making automation easy by default
• Build a DRY, reusable story that leans on open source and encourages innersource for private enterprises
• Building blocks (Actions) that are composable, traceable, and version-pinned
• Extremely easy to do most things, possible to do almost anything
• The philosophy: if automation is frictionless enough, people will actually do it

But even with Actions, there were limits. It wasn't feasible to automate every task for every repo. Some automations were too bespoke, too context-dependent, too expensive to build. There were always plenty of automations we wished existed but couldn't justify building.

Just Automate it​

We've entered a new world. If a task can be automated, then choosing to automate it is almost always the better choice. The cost of building automations has collapsed. AI can generate the workflow, write the action, compose the pipeline. The ROI bar that used to filter out 80% of automation ideas? It's basically on the floor.

The Compounding Factor​

This is where it gets exponential, not linear:

1. Use AI to build "traditional" tools like tests, linters, deployment pipelines, and monitoring
2. Those tools continue to propel you faster, even when the AI isn't running
3. Every automation you build runs thousands of times across dozens of repos
4. The AI builds the automation, the automation keeps compounding

AI writes automation → automation runs 1000x → saves 1000x manual effort
                       ↑
                       └── this keeps running even when AI is idle

Stop using AI just to write features faster. Start using AI to build the automations that make your entire team faster. That's where the real leverage is.

The Mental Shift​

The question is no longer "is this worth automating?" It almost always is now. The new questions are:

• What should I automate first? (highest frequency × highest toil)
• How do I make this automation trustworthy? (testing, guardrails, monitoring)
• How do I scale this across my org? (reusable workflows, templates, innersource)

AI productivity becomes exponential when you stop using it for linear speedups and start using it to build the automation infrastructure that compounds over time.

📊 View the visual presentation →

Next up: GitHub Actions: The AI-Native Platform. You'd be surprised what's already running on Actions under the hood.

In reality most people are using AI as a tool to improve aspects of our workflows rather than building full blown automated solutions.

• AI tooling can help us build traditional automations faster. Writing scripts has never been easier with the help of AI powered development tools.
• Developers can incorporate AI directly into their software to perform inference. This unlocks new use cases by giving us probabilistic functions instead of just deterministic ones.
• An Agent equipped with tools can act as a probabilistic runtime loop for any task.

All of these automations need to run somewhere, and many of them related to software will live on a CI/CD platform.

CI/CD History​

The advancements in CI solutions over the last couple decades didn’t just make developers more efficient but they also perfectly support AI developer tools.

The First Wave (2007)​

Tools like Jenkins introduced CI servers, solving the problem of manual builds but eventually leading to "maintenance hell" due to the manual creation and management of hundreds of jobs.

It’s critical that AI automation happens in a safe and isolated environment.

The Second Wave (2013–2019)​

Platforms like TravisCI and eventually GitLab CI popularized "Pipeline-as-Code." This allowed developers to define pipelines in code repositories. While GitLab improved reusability with templates, pipelines still often required writing repetitive boilerplate code.

AI needs a language to describe structured pipelines.

The Third Wave (Late 2019+)​

GitHub Actions sets itself apart by moving beyond just defining pipelines in code. The "Actions" themselves serve as modular, reusable building blocks. Actions also made CI more event-driven by exposing more events to trigger these automations.

AI improves with lots of training data and it can leverage modular reusable blocks well.

Why GitHub Actions?​

With this modular reusable building blocks story you can now create robust automations quicker than ever before.

GitHub’s community is massive. It’s the home for open source. The Actions marketplace will only continue to grow with new and improved building blocks. AI will continue to leverage these building blocks and there will be a large amount of training data available.

GitHub has the infrastructure to scale with the backing of Microsoft Azure. They give away enormous amounts of compute for free to the open source community.

What does the future of automation look like?​

AI developer tools have accelerated development, allowing us to build automations we never previously had time for. With Copilot you can asynchronously vibe script just about any automation task with great accuracy and small time investment.

What is “hard” to automate?​

We will eventually hit a wall with automation. A limit on what we can script with traditional methods because we cannot "grep ambiguity".

• The Cost of Determinism: The old way of automation required predicting every possible failure state. It starts to take more time writing handling for our scripts than writing the scripts themselves.
• The Unknowns: Those tasks left over require intelligence or human intervention. AI allows us to finally handle these "unknown unknowns".

AI Unlocks new automation capabilities​

The shift from traditional script automation to AI inference is moving from deterministic execution (if X, then Y) to probabilistic reasoning (X is 99% likely to cause Y). The shift makes automations possible that previously required human intuition or were simply too complex to script.

Level 1: The LLM as a Function​

Using basic Inference allows the user to implement the most basic version of LLMs in CI. This is great for things like:

• Instead of a regex to validate a PR title, use a model to ask "Does this PR title adhere to X?"
• Validating a PR description or commit message
• Choosing the label for an issue
• Generating release notes
• Summarizing content
• Mock data generation

Level 2: Agentic​

We are entering a world where AI performs tasks using tools. Unlike simple inference, agents are multi-turn and loop: they try, fail, read the error, correct, and try again. The AI isn't just chatting; it is running the terminal, fetching webpages, and reading or writing files.

Agentic Tools​

Agents typically get their tooling through the Model Context Protocol. This is the USB-C for Agents.

GitHub Actions is ready for this agentic world:

• GitHub’s MCP Server has actions tools
• The GH CLI is easy for AI to use
• GitHub has an enormous amount of APIs. REST, GraphQL

How do you run Agents in GitHub Actions?​

The GitHub CLI is a great tool for AI use, and the Copilot CLI allows us to programmatically invoke GitHub Copilot’s agent mode directly from a shell environment. This means you can call the Copilot CLI from within GitHub Actions. This will act as our runtime that can be triggered off of just about anything that happens in GitHub.

Why run Agents in GitHub Actions?​

Running autonomous agents on a developer's machine is dangerous; we must consider the worst-case scenario where an agent injects malicious code, steals secrets, or deletes assets. We need to isolate the agent.

GitHub Actions is the perfect runtime for this because:

• Ephemeral & Secure: The environment is 100% ephemeral and secure by default, using OIDC tokens that are short-lived.
• Human in the Loop: To solve the problem of agents hallucinating, we can use GitHub Actions "Environments" and "Approvals". We can treat an AI Agent like a junior developer: it can do the work, but it cannot merge to production without a human clicking "Approve" in the interface.
• Deep Context & Integration: The event context contains tons of useful structured information for agents.

We also need to consider the scalability and maintainability of these agents as they become more complex and integral to our development workflows.

Okay that's not bad... Let's try to get some ideas on what to eat.

Wow... okay! I eat out more than I should and even I'm impressed by these options! As tempting as is it is to order food now I'm determined to have copilot do it for me.

Let's make up our mind. The Naked Farmer bowl with spicy harissa sauce is calling my name!

After struggling with copilot a bit I had it add the item and funny enough it started deciding the ingredients for me. Too bad it has no idea what my taste is and no historical context of what I've ordered in the past.

Okay this technically worked but I could do it faster myself without all the back and forth. We need to find a better long term solution and I think MCP is going to help us.

I have some ideas on how we can improve:

1. We need the agent to know about my preferences, where I live, etc.
2. I want the agent to find ideas for me including new restaurants in the area.
3. I'd like a predefined prompt to more efficiently order the things I want.
4. We need to find or create an Uber Eats MCP server for this that is pre-authenticated.

Let's create a new repository to house our copilot customizations.

All the major AI companies now have agents as CLI tools:

• Gemini CLI
• Claude Code
• OpenAI Codex

And of course, GitHub Copilot is taking the more native approach.

We need a place to run these agents, and GitHub Actions is a great fit.

There are a handful of use cases for AI agents in GitHub Actions:

• Code Review - Use AI to review pull requests, suggest improvements, and catch bugs.
• Create Code - Generate boilerplate code, documentation, or even entire functions based on your specifications.
• Review Code - Analyze existing code for quality, security, and performance issues.
• Generate Tests - Automatically create unit tests or integration tests for your code.

Check out some example workflows, issues, prs:

Example Workflows

GitHub Repository

The catch is that Google Photos doesn't make it easy to get simple, direct links to your images. I just wanted a clean list of URLs for an album I could plug into my site.

I'm kind of into photography. About a year ago I bought this fancy S5II Full Frame Mirrorless Camera. It was mostly to use as a webcam for zoom meetings but I always thought photography and film were really cool. I took a photography class growing up and I took a lot of pictures back when I worked at the PR firm so I had a general sense of how to shoot. I'm still an amateur but It's fun for me.

You've probably seen a theme of me using GitHub Copilot so of course I vibe coded most of this project. I pointed to blog posts I found, asked it to come up with a plan. It wrote the plan to a file. Then I wrote all the code with Claude Sonnet 4.

Claude was caught up on the lazy loading images and scrolling through them properly. It did figure it out but not well enough to exhaustively get a full list of images. I was able to figure out the proper scrolling technique and we continued on with the headless automation solution.

Check out the code on GitHub:

google-photos-scraper

Or run the tool yourself:

npx google-photos-scraper https://photos.app.goo.gl/kXEc4X8Lfrh7qEKdA

It works great and was fairly easy to setup. To prove it, here are some photos from my recent trip to Spain, all sourced using the tool.

Inspiration​

• How I used Google Photos to host my website picture gallery
• Get a public link for sharing Google Photos image

Customizing Copilot​

The magic starts with Customizing AI responses in VS Code. Instead of repeatedly explaining my preferences to the AI, I can now define:

• Custom instructions for consistent coding practices
• Custom prompts for reusable task templates
• Custom chat modes with specific tool configurations

This foundation allows me to create specialized AI assistants for different phases of development.

VS Code Settings​

Here are my VS Code settings. I have enabled experimental features and changed some settings to allow the agent to run without my intervention.

{
  "github.copilot.nextEditSuggestions.enabled": true,
  "github.copilot.enable": {
    "*": true
  },
  "github.copilot.renameSuggestions.triggerAutomatically": true,
  "github.copilot.editor.enableCodeActions": true,
  "github.copilot.chat.startDebugging.enabled": true,
  "github.copilot.chat.codeGeneration.instructions": [
    {
      "file": ".copilot-instructions.md"
    },
    {
      "text": "Prefer to use TypeScript over Javascript"
    },
    {
      "text": "My github username is austenstone."
    }
  ],
  "github.copilot.chat.testGeneration.instructions": [],
  "github.copilot.chat.reviewSelection.instructions": [],
  "github.copilot.chat.commitMessageGeneration.instructions": [
    {
      "file": ".copilot-commit-message-instructions.md"
    },
    {
      "text": "Keep the commit message short and concise. Use imperative mood and avoid unnecessary details."
    }
  ],
  "github.copilot.chat.reviewSelection.enabled": true,
  "github.copilot.chat.setupTests.enabled": true,
  "github.copilot.chat.useProjectTemplates": true,
  "github.copilot.chat.generateTests.codeLens": true,
  "github.copilot.chat.edits.temporalContext.enabled": true,
  "github.copilot.chat.languageContext.typescript.enabled": true,
  "github.copilot.chat.completionContext.typescript.mode": "sidecar",
  "github.copilot.chat.editor.temporalContext.enabled": true,
  "github.copilot.chat.codesearch.enabled": true,
  "github.copilot.chat.newWorkspaceCreation.enabled": true,
  "github.copilot.chat.agent.thinkingTool": true,
  "github.copilot.nextEditSuggestions.fixes": true,
  "github.copilot.chat.languageContext.fix.typescript.enabled": true,
  "github.copilot.chat.languageContext.inline.typescript.enabled": true,
  "github.copilot.chat.notebook.followCellExecution.enabled": true,
  "chat.editing.autoAcceptDelay": 5, // Delay in seconds before automatically accepting edits
  "chat.tools.autoApprove": true, // Automatically approve run commands and tool requests
  "chat.agent.maxRequests": 100, // Maximum iterations before asking to continue
  "chat.renderRelatedFiles": true,
  "chat.setup.continueLaterIndicator": true,
  "inlineChat.enableV2": true,
  "inlineChat.hideOnRequest": true,
  "inlineChat.finishOnType": true,
  "inlineChat.lineEmptyHint": true,
  "mcp": {
    "servers": {
      "playwright": { // Useful for operating browser
        "command": "npx",
        "args": [
          "@playwright/mcp@latest"
        ]
      },
      "serena": { // An entirely separate coding assistant than copilot
        "command": "uvx",
        "args": [
          "--from",
          "git+https://github.com/oraios/serena",
          "serena-mcp-server.exe"
        ]
      },
      "time": { // Get the current time
        "command": "uvx",
        "args": [
          "mcp-server-time",
          "--local-timezone",
          "America/New_York"
        ]
      },
      "searxng": { // Search the web using SearxNG
        "command": "npx",
        "args": [
          "-y",
          "mcp-searxng"
        ],
        "env": {
          "SEARXNG_URL": "http://localhost/"
        }
      },
      "sequential-thinking": { // Sequential thinking tool for reasoning
        "command": "npx",
        "args": [
          "-y",
          "@modelcontextprotocol/server-sequential-thinking"
        ]
      },
      "supabase": { // Supabase tool for database operations
        "command": "npx",
        "args": [
          "-y",
          "@supabase/mcp-server-supabase@latest",
          "--read-only"
        ],
        "env": {
          "SUPABASE_ACCESS_TOKEN": "${env:SUPABASE_ACCESS_TOKEN}"
        }
      },
      "github": { // Interact with the GitHub platform
        "url": "https://api.githubcopilot.com/mcp/",
        "headers": {
          "Authorization": "Bearer ${input:github_mcp_pat}"
        }
      }
    },
    "inputs": [
      {
        "type": "promptString",
        "id": "github_mcp_pat",
        "description": "GitHub Personal Access Token",
        "password": true
      }
    ]
  }
}

• github.copilot.chat.codeGeneration.instructions - I have custom instructions personal to me
• chat.agent.maxRequests - Let's me allow the agent to run longer without asking for permission
• chat.tools.autoApprove - Automatically approves run commands and tool requests from the agent

GitHub Copilot in VS Code settings reference

MCP Tools​

The Using Model Context Protocol (MCP) in VS Code allows me to provide the agent with access to external tools and data sources.

Some of the MCP servers I use include:

• Sequential Thinking - Dynamic and reflective problem-solving through thought sequences
• SearXNG - Integrates the SearXNG API, providing web search capabilities.
• Playwright - This MCP Server will help you run browser automation and webscraping using Playwright
• GitHub - Repository management, file operations, and GitHub API integration
• time - For getting the current time and date
• Fetch - Web content fetching and conversion for efficient LLM usage

The repo modelcontextprotocol/servers contains a list of available MCP servers.

Development Workflow​

Research​

Before diving into coding, I often need to research new concepts or technologies. For this, I use a custom chat mode called research that includes tools like web search, and sequential thinking.

---
description: 'Research mode for gathering information and analyzing topics in depth.'
tools: ['changes', 'codebase', 'extensions', 'fetch', 'findTestFiles', 'githubRepo', 'new', 'openSimpleBrowser', 'problems', 'runCommands', 'runNotebooks', 'runTasks', 'search', 'searchResults', 'terminalLastCommand', 'terminalSelection', 'testFailure', 'usages', 'vscodeAPI', 'playwright', 'time', 'get_current_time', 'searxng', 'searxng_web_search', 'web_url_read', 'sequential-thinking', 'supabase', 'list_branches', 'github', 'list_branches', 'list_code_scanning_alerts', 'list_commits', 'list_issues', 'list_notifications', 'list_pull_requests', 'list_secret_scanning_alerts', 'list_tags', 'search_code', 'search_issues', 'search_repositories', 'search_users', 'sequentialthinking']
---

Activate research mode.

Your task is to research and gather information about a specific topic.

# Tools
Use tools to gather information and do research. Use the `sequential-thinking` tool for complex problems requiring deep analysis and multi-step reasoning.
- Use the `sequentialthinking` tool for complex problems requiring deep analysis and multi-step reasoning.
- Use search tools
  - Use `searxng_web_search` to search the web for broad, initial keyword-based web searches to discover relevant URLs.
  - Use the `web_url_read` tool when you have a direct URL and need to quickly extract the raw text or content of a page.
  - Use the `fetch` tool as an alternative to web_url_read, potentially for more complex requests.
- Use the `playwright` tool to interact with web pages and gather information from the browser. Use to get CSS and style information.

# 1. Strategic Planning (DO THIS FIRST)
Use the sequential-thinking `sequentialthinking` tool to outline your research strategy. Identify keywords, potential information sources, and the steps you will take.

# 2. Information Gathering & Analysis (THINGS YOU MUST DO)
- When you don't understand a term or topic search the web using tools like `searxng_web_search` or `web_url_read` to gather more information.
- Use all available tools to gather information and do research.
- Continue using tools to gather information until you've fully researched the topic or problem.
- Synthesize and summarize findings at key intervals. After gathering information from multiple sources, take a moment to synthesize what you've learned before proceeding.
- When you're done use `sequentialthinking` to ask yourself if you've gathered enough information to answer the question or solve the problem.

# 3. Concluding the Research (DO THIS LAST)
- Use sequential-thinking to ask yourself: "Have I gathered sufficient, well-verified information to thoroughly address the user's request?"
- Provide a final, structured response that includes:
  - A direct answer to the core question.
  - A summary of key findings with linked sources.

# DO NOT (THINGS YOU MUST NOT DO)
- Do not write actual code!
- Do not make assumptions without verifying them through research or analysis.
- Do not skip steps in the analysis process; always think step by step.
- Do not rush to conclusions; take the time to explore different angles and gather sufficient information.
- Do not stop until you have a comprehensive understanding of the topic or problem.

Planning​

I start every project in a custom chat mode called plan that I have in my user space. The tools I want for are already selected and copilot can't edit my code even if it wanted to because I took away that tool. I find Gemini 2.5 Pro to be the best model for planning.

---
description: 'Generate comprehensive implementation plans for features, refactoring, and bug fixes without making code changes.'
tools: ['changes', 'codebase', 'editFiles', 'extensions', 'fetch', 'findTestFiles', 'githubRepo', 'problems', 'runCommands', 'search', 'searchResults', 'usages', 'vscodeAPI', 'time', 'get_current_time', 'searxng', 'sequential-thinking']
---

Activate planning mode.

Your task is to think about and generate an implementation plan for a new feature or for refactoring existing code.

# Planning mode instructions
Don't make any code edits, just generate a plan.

# Instructions
1. **Gather Context**: Use the `codebase` tool to analyze the current codebase, including existing features, architecture, and dependencies. Use the `changes` tool to identify recent changes that may impact the new feature or refactoring task.
2. **Research**: Use the `searxng_web_search` and `web_url_read` tools to gather information about best practices, design patterns, and similar implementations. This will help you understand how to approach the new feature or refactoring task effectively.
3. **Plan Structure**: Create a structured plan.
4. Repeat the process iteratively, refining your understanding and plan as you gather more information.

# Output
The plan consists of a Markdown document that describes the implementation plan, including the following sections:
* Overview: A brief description of the feature or refactoring task.
* Requirements: A list of requirements for the feature or refactoring task.
* Implementation Steps: A detailed list of steps to implement the feature or refactoring task.
* Testing: A list of tests that need to be implemented to verify the feature or refactoring task.

# What You MUST Do:
- Use tools to gather information and analyze the codebase before planning.
- Use existing context and information from previous conversations to inform your planning.
- Always gather comprehensive context before planning
- Think through edge cases and potential complications
- Plan for comprehensive testing at each phase
- Document assumptions and decision rationale
- Structure plans for easy team comprehension and execution
- Consider backward compatibility and migration paths

# What You MUST NOT Do:
- Never write actual code or implementation details
- Never modify files or make changes to the codebase
- Never provide large code snippets or complete implementations
- Never skip the analysis phase and jump directly to solutions
- Never assume requirements without clarification

# 3. Tool Usage Guidelines
Use tools to help create implementation plan. Use the `sequential-thinking` tool for complex problems requiring deep analysis and multi-step reasoning.
- Use the `sequentialthinking` tool for complex problems requiring deep analysis and multi-step reasoning.
- Use search tools
  - Use `searxng_web_search` to search the web for broad, initial keyword-based web searches to discover relevant URLs.
  - Use the `web_url_read` tool when you have a direct URL and need to quickly extract the raw text or content of a page.
  - Use the `fetch` tool as an alternative to web_url_read, potentially for more complex requests.
- Use the `playwright` tool to interact with web pages and gather information from the browser. Use to get CSS and style information.
- Use the `editFiles` tool to create prompt files in `.github/prompts` directory with the name `<name>.prompt.md` for planning and implementation. ONLY USE THIS TOOL TO CREATE PROMPT FILES.

Think step by step through each planning phase, and always prioritize thorough analysis over speed. For complex problems that require deep reasoning, evolving understanding, or exploration of multiple approaches, utilize the sequential-thinking tool to maintain context and generate well-reasoned solutions. A well-researched plan prevents costly implementation mistakes and ensures successful project outcomes.

---
mode: agent
description: "Prompt files are standalone prompts that you can run directly in chat. They describe the task to be performed (what should be done)."
---

Create a prompt file in the `.github/prompts` directory that implements all previous conversation and context.

Add as much context and information as possible.

# Information

## Prompt files
Define reusable prompts for common tasks like generating code or performing a code review. Prompt files are standalone prompts that you can run directly in chat. They describe the task to be performed (what should be done). Optionally, you can include tasks-specific guidelines about how the task should be performed, or you can reference custom instructions in the prompt file.

## Prompt file structure

A prompt file is a Markdown file with the .prompt.md file suffix. It has the following two main sections:

- (Optional) Header with metadata (Front Matter syntax)
  - mode: The chat mode to use when running the prompt: ask, edit, or agent (default).
  - description: A short description of the prompt.
- Body with the prompt content
  - Prompt files mimic the format of writing prompts in chat. This allows blending natural language instructions, additional context, and even linking to other prompt files as dependencies. You can use Markdown formatting to structure the prompt content, including headings, lists, and code blocks.

You can reference other workspace files, prompt files, or instructions files by using Markdown links. Use relative paths to reference these files, and ensure that the paths are correct based on the location of the prompt file.

Within a prompt file, you can reference variables by using the ${variableName} syntax. You can reference the following variables:

- Workspace variables - ${workspaceFolder}, ${workspaceFolderBasename}
- Selection variables - ${selection}, ${selectedText}
- File context variables - ${file}, ${fileBasename}, ${fileDirname}, ${fileBasenameNoExtension}
- Input variables - ${input:variableName}, ${input:variableName:placeholder} (pass values to the prompt from the chat input field)

# Example

```
---
mode: 'agent'
description: ''
---
<content goes here>
```

The goal of this phase is to generate a comprehensive .prompt.md file in .github/prompts/ that serves as a detailed blueprint for the implementation.

Implementation​

Once I have my planning prompt ready, I switch to regular agent mode with Claude Sonnet 4 and simply run /prompt-name. The beauty of this approach is that the AI has all the context it needs to execute the plan methodically.

The prompt file acts as a contract between the planning phase and implementation phase, ensuring consistency and reducing the need for back-and-forth clarification.

Course Correction​

If the agent is close I will sometimes pause it and ask it to look at a specific resource or document to help it understand the problem better.

When the agent deviates from the desired behavior (which occasionally happens), I have a simple recovery process:

1. Clear my git diff to reset the changes
2. Modify the prompt file based on what I learned
3. Restart the implementation from scratch

This iterative refinement of prompts means I'm constantly improving my templates for future use.

Validation​

Finally (or maybe first if we're following TDD) I want to ensure the implementation works as expected. Ideally our output is testable but sometimes this is hard.

For browser interactions, I use the playwright MCP tool to automate testing. This is really cool because the agent can use a browser just like I can! This lets it understand how the UI works and what it looks like.

Example​

Let's walk though a real-world example. I want to add comments to my blog you're viewing right now.

1. Research​

I start by in research mode using Gemini 2.5 Pro with a question:

How would I add comments to my blog posts in this Docusaurus site?

Copilot starts by using sequentialthinking think about how to perform research

{
  "nextThoughtNeeded": true,
  "thought": "I need to research how to add comments to a Docusaurus blog. I will start by searching for \"Docusaurus blog comments\" and analyze the results. I will look for official documentation and popular third-party solutions like Giscus, Disqus, or Utterances. Finally, I will synthesize the findings to provide a clear recommendation.",
  "thoughtNumber": 1,
  "totalThoughts": 2
}

Then Copilot starts searching the web using searxng_web_search and web_url_read tools.

{
  "query": "Docusaurus blog comments"
}

It comes up with the idea to use Giscus as a commenting service.

To add comments to your Docusaurus blog, you'll need to use a third-party commenting service because Docusaurus generates a static site. A highly recommended option that integrates perfectly with your existing GitHub-based project is Giscus.

Full chat export

2. Planning​

Now I switch to plan chat mode.

Create a plan based on your research

Copilot comes up with a structured plan for me.

3. Implementation​

Now I switch to regular agent mode.

We're going to reuse our prompt file from earlier to write the plan as a .prompt.md file.

/copilot-prompt

Copilot creates the .github/prompts/implement-giscus.prompt.md file.

Now I can switch to Claude Sonnet 4 and run the generated prompt file.

/implement-giscus

Full chat export

Course Correction​

I'm watching the agent work and it got hung up on how to pass front matter metadata to the Giscus component.

I paused and asked it to look at document on the topic

look at how blog posts can do front matter
https://docusaurus.io/docs/api/plugins/@docusaurus/plugin-content-blog#markdown-front-matter

Copilot looked at my resource and found even more resources to help it understand how to access blog post metadata.

I'll examine how to properly access blog post front matter in Docusaurus by checking the documentation and updating the implementation accordingly.

> Fetched https://docusaurus.io/docs/api/plugins/@docusaurus/plugin-content-blog#markdown-front-matter

Now let me check the Docusaurus documentation about how to access blog post metadata in components:

> Fetched https://docusaurus.io/docs/blog#accessing-blog-post-information

Let me search for Docusaurus documentation specifically about the useBlogPost hook:

...

Copilot figured out that the ideal solution was the reactHook useBlogPost() which I totally agree with.

4. Validation​

I want to ensure the Giscus comments are working correctly so I ask Copilot to browse to a link knowing it will use the playwright MCP tool.

check that the giscus comments are working
browse to http://localhost:3000/blog/github-copilot-agent-mcp
test functionality
#changes

This tested the comments were working but I wanted it to actually make a comment on the blog post.

Test the comments by making comments on this blog post
http://localhost:3000/blog/github-copilot-agent-mcp

Make the comment about the blog post and say that it's coming from github copilot using playwright

The comment on this blog post was actually the output of this prompt.

Real Example​

Copilot did complete my feature completely.

The full PR can be found at austenstone/portfolio/pull/36.

Benefits​

This workflow has transformed how I approach development:

1. Consistency: Custom instructions ensure all generated code follows my patterns
2. Efficiency: Pre-planned prompts eliminate repetitive explanations
3. Quality: Structured thinking leads to better architectural decisions
4. Testability: UI-aware testing tools create more comprehensive test suites
5. Reproducibility: Documented prompts make complex tasks repeatable

Ultimately I can spend more time on high-level design and less on low-level implementation details. The AI handles the grunt work, allowing me to focus on delivering value.

The Future​

This combination of Agent Mode and MCP represents a fundamental shift in how we can work with AI. Instead of treating AI as a simple code completion tool, we can create sophisticated, context-aware development partners that understand our specific needs and workflows.

The key insight is that the AI becomes more valuable when it has more context about our intentions, constraints, and environment. MCP provides that context, while custom prompts ensure consistent, high-quality outputs.

Have you experimented with Agent Mode and MCP in your development workflow? I'd love to hear about your experiences and any creative tool combinations you've discovered. Connect with me on GitHub or LinkedIn to continue the conversation.

Why Docusaurus?​

Docusaurus is built specifically for content creators who want to focus on writing rather than wrestling with complex build systems. Here's what makes it perfect for my needs:

Content-First Approach: Writing in Markdown is a game-changer. Instead of wrestling with Angular components for every blog post, I can now focus purely on content. This means more frequent updates, better documentation for my projects, and less time spent on the technical overhead of publishing.

Built for Performance: Docusaurus follows the PRPL Pattern for lightning-fast loading, generates static HTML for SEO, and provides client-side routing for a smooth single-page app experience.

Developer Experience: Hot reloading, MDX support for interactive components, and sensible defaults mean I can ship content quickly without sacrificing functionality.

GitHub Copilot's agentic mode was incredibly helpful during the migration - it handled a lot of the repetitive work and helped me understand Docusaurus patterns quickly.

What's Here​

• Projects: Detailed documentation of my GitHub Actions, DeviceWISE View, and other work
• Blog: Technical insights and experiences from my role at GitHub
• Resume: Professional experience and skills

Ready to ship more content! 🚀