Automation & AI
SkiaSharp is a large native binding that tracks Google's Skia engine along Chrome's release train. A small team keeps it current because agentic workflows handle the repetitive work and deterministic scripts handle the mechanics. Humans spend their time on API design and correctness.
AI does not write the graphics engine. It does the toil: syncing upstream, diffing APIs, scaffolding docs, triaging issues, and auditing for CVEs. The mechanical steps run as plain scripts, the agent does the judgement work, and every change lands as a normal pull request that a maintainer reviews.
How it fits together
The Skia update lifecycle runs in two phases. First the upstream sync lands in the library. Then, once a release is on main, two independent flows publish in parallel: one writes the website release notes, the other writes the API reference. Automation does the mechanical work, the AI agent does the parts that need judgement, and a maintainer reviews before anything ships.
Phase 1 · Sync to merge
Engine & bindings → nuget.org
Merge new commits from Google's Skia, resolve conflicts, and regenerate the bindings.
AI agentBuild the native and managed libraries and run the full test suite on the pull requests.
AutomationA maintainer reviews the two pull requests and merges them into main.
Human reviewPhase 2 · Publish, in parallel
Release notes & API diffs → website
Compute the public API diff across every published NuGet of both families.
AutomationTurn the raw diffs and data into readable, human release notes.
AI agentA maintainer merges the docs PR and the website rebuilds.
Human reviewAPI docs → Microsoft Learn
Rebuild the XML reference stubs from the latest published packages.
AutomationFill the missing entries and review the existing reference docs.
AI agentThe Microsoft Learn build gates the PR; it auto-merges, then a maintainer takes it live.
AutomationWhere we use AI
Four workflows run an AI agent. Each one is wired so the agent can only emit a small set of constrained outputs, listed as "allowed outputs" below. Everything else is read-only.
Merges new commits from Google's upstream Skia, resolves the conflicts, regenerates the bindings, and opens the two paired pull requests: one in mono/skia for the submodule and one in mono/SkiaSharp. The hardest reasoning in the whole pipeline, which is why it runs on the strongest model.
Reads new and untriaged issues, classifies them by type, area, platform, and backend, applies the right labels, and fills the triage fields on the project board. It writes a triage report as an artifact rather than posting noise on the issue.
A deterministic prepare job computes the public API diff over every NuGet and generates the raw release-note data. The agent then turns that data into readable notes and opens one pull request, only when the prepare step actually found changes.
A deterministic job regenerates the XML doc stubs from the latest CI NuGets. The agent then runs a two-pass pipeline: it fills the "To be added." placeholders, then runs three correctness review passes over a scope of existing docs, editing the mdoc XML directly, and opens a pull request.
How we automate the rest
A lot of the pipeline is plain GitHub Actions with no AI at all. These run before the agent to prepare its inputs, or after it to publish the result. The agent handles one part, the deterministic step handles the other, so we need both.
Before any agent runs, scripts do the mechanical work: a Cake task computes the API diff across NuGets, mdoc regenerates the XML doc stubs, and generators produce the raw release-note data. The agent starts from a clean, factual baseline rather than gathering it by hand.
When an agentic run finishes, this workflow downloads its uploaded artifacts and
commits them to the aw-data branch under a key derived from the workflow
name, for example triage reports under ai-triage. It keeps a durable,
inspectable record of what the agents did.
Watches the docs writer's pull request branch and waits for the
OpenPublishing.Build and PoliCheck Scan checks to pass with
no new warnings. When they do, it squash-merges the PR. The AI proposes the
documentation, and deterministic gates verify it builds and passes policy before it
ships.
The final, deliberate publish step, triggered manually by a maintainer. It opens (or
reuses) a pull request from main into the live branch;
merging that PR ships the latest API reference to Microsoft Learn.
More plain automation keeps the project moving: the website deploy and staging cleanup, the samples build, the docs submodule sync, PR backport and rebase commands, and a build artifacts comment for fork PRs. None of these use AI; they are the connective tissue the agents plug into.
Reusable instructions
A skill is a folder under .agents/skills/ with a SKILL.md file
that captures how to do one job well: the steps, the rules, and the checks. The agentic
workflows load a skill and let it drive, and maintainers invoke the same skills by hand
as slash commands. One source of truth, used by both the automation and the humans.
Want the full text? Each skill is a plain Markdown file you can read in the repository. Browse the skills folder →
How we keep it safe
The trust story is deliberate. The agents are boxed in by design, and a human signs off on everything that lands.
The mechanical work runs as plain scripts before the agent starts. The agent only does the part that needs judgement, so its surface area is small.
Each workflow declares an allow-list of safe outputs: open a pull request, add labels, set project fields. The agent cannot make arbitrary writes to the repository.
Every agentic change arrives as an ordinary pull request. A maintainer reads it, asks for changes, and merges it. Nothing the agent produces ships unreviewed.
The docs writer runs three correctness review passes over its own output, and the resulting PR only auto-merges after the Microsoft Learn build passes.
Transparency. Everything here runs as public GitHub Actions you can
open and inspect, and every agentic run persists its artifacts to the
aw-data
branch. The machinery is not a black box; it is in the open, in the same repositories as
the code.
Go deeper
All of it is open. Read the workflows and skills, or open a pull request to make them better.
