aspect describe against a repository containing one file. Run it again:
The detail an agent needs
--format=json exists and that it is a permitted value — it does not have to guess, and it does not have to be told.
That is the bill coming due on a decision from section four. --format=json was introduced there as a small habit, justified only as “the other output is for everything that isn’t you.” Nothing about agents. Six steps later the habit is the integration, and there was no integration step.
Point an agent at the repository
Open your agent of choice in this directory and ask it something it cannot answer without the repo:Which tests should I run for my current change?What happens: it runs
aspect describe, finds impact, sees --format=json in the declared values, runs aspect impact --format=json, and runs what comes back.
If you have no agent configured in this directory, you have lost nothing: the two aspect describe commands above are the entire discovery path. Run them yourself and you have read exactly what it would read.
No MCP server. No authentication. No network. aspect mcp exists and serves build history, but it needs an account and a Workflows deployment — none of which this course has used. The local story needs none of it: an agent with a shell and a repository that can describe itself is sufficient.
AGENTS.md ships in the repository, written for precisely this:
# Working in this repository, in four short sections: how to enumerate the commands, why to prefer --format=json, a table of what each command here answers, and what to run before handing work back. None of it is about this course — it is the file you would write for your own repository. It can be that short because it mostly just points at aspect describe; the flags, types, defaults and allowed values are already in the tool, so the document does not have to carry them and cannot go stale against them.
The part worth noticing
Ask your agent to write a new command — something small, like listing the packages with no tests. It reads the existing tasks as examples, sees the conventions you have been reading all session (task(), typed args, ctx.std.io.stdout.write rather than print, --format=json), and writes one. Then aspect describe lists that too — which is the claim being made here, and it is about discoverability rather than about any particular agent. If you are reading this without one, the four .aspect/*.axl files are the examples it would have read.
This course never asked you to write AXL. You read it, ran it, and changed a token at a time. The last ten minutes are about who does the writing now — and about the fact that the thing it writes is discoverable to the next agent for exactly the same reason yours were.
Where this goes
Everything you built ran locally, offline, with no account:- The AXL you actually need. What you write next is for your repository, not this one. Point your agent at the Aspect docs MCP server and it can search the CLI reference, the generated AXL reference, every guide — and this course — while it writes. The anonymous endpoint covers all of that and needs no account, like everything else here. Then ask it for the thing your team keeps doing by hand.
- CI. The same tasks post status checks, PR comments and inline lint findings when you connect an account. Nothing you wrote changes; the results land where your team can see them. See reporting into CI.
- Build history.
aspect mcpserves build and test results across invocations — “how often has this test failed in the last fortnight” — which is the one question a local repo genuinely cannot answer. - Affectedness, properly.
aspect impactis advisory and says so. For gating CI, bazel-diff and target-determinator are correct and this is not. For a remote-cache-backed answer on your working tree,aspect cache diffis output-based rather than input-based — it asks the cache what actually changed.