AgentRC: Microsoft reads your repository and writes the instruction files your coding agent is missing

A repository scorer that also writes the files

AgentRC is described in one line as context engineering for AI coding agents, and the GitHub description is blunter still: get your repo ready for AI. The premise underneath is that a coding agent performs badly when it does not know how your project builds, tests and lints, and worse when it does not know your architecture, your conventions or which external services the team depends on. Most repositories ship none of that context, so every agent session rediscovers it.

The tool runs with no configuration at all. A single command is the whole install step, and it runs against any repository it can read.

npx github:microsoft/agentrc

What comes back is two different things at once. The first is a score: your repository measured against nine readiness pillars and a five-level maturity model, which tells you what context is missing, from the basics of linting through to MCP server configuration. The second is generated output, produced through the Copilot SDK, which is the part that reads your actual code rather than filling in a template.

That combination is what makes the project more than a scaffold. A tool that only generates files gives you a starting point. A tool that only scores files gives you a to-do list. The interesting claim is that the second one keeps the first honest, which is the subject of the eval command below.

Measure, generate, maintain, and why the third step is the real one

The README structures the product as a cycle of three verbs, and each one has its own command.

npx github:microsoft/agentrc readiness

That scores the repository and names what is missing. Nine pillars is enough granularity to be useful without becoming a checklist nobody reads, and the five-level maturity model gives you something to compare a team against itself over time rather than against a vendor's definition of good.

npx github:microsoft/agentrc instructions

This is the generation step, and the claim made for it is that there are no templates involved, that AgentRC reads the codebase and produces context specific to the stack it found. The README is explicit that it reads your actual code, which is a stronger claim than most generators make and one worth testing on a repository with unusual structure.

npx github:microsoft/agentrc eval

The third step is the differentiator. Instructions files rot. A conventions file written in January describes a January repository, and six months later an agent is being told to follow rules your team stopped following. The eval command exists to answer whether the instructions still improve agent responses, and it is designed to run in CI so that drift fails a build rather than being discovered later as worse output.

So generation is the feature people will try, and eval is the feature that decides whether it was worth doing. If you only ever run `instructions`, you have installed a scaffolder.

What actually lands on disk

Four files come out of a normal run, and each one has a clear owner.

`.github/copilot-instructions.md` teaches agents your repository conventions. `.vscode/mcp.json` connects an agent to the tools and data your stack actually exposes, which is the file that turns a coding agent from a text generator into something that can query your issue tracker or your internal service. `.vscode/settings.json` tunes the editor for AI-assisted development. `agentrc.eval.json` holds the test cases used to measure instruction quality, and it is the only one of the four that is machine-owned.

There is a fifth option for teams running more than one agent. Passing `--output AGENTS.md` produces the multi-agent format, covering Copilot plus Claude and others, and the README links the VS Code documentation on custom instructions for the format's origins.

The dependency list tells you how the generation happens. `@github/copilot-sdk` is the generation engine, `@octokit/rest` handles GitHub, `simple-git` covers local repository operations, `fast-glob` does the file discovery that code reading requires, and `ink` with `react` means the interactive surfaces are a terminal UI rather than a series of printed lines. `@inquirer/prompts` handles the prompts. The package is published under the `@microsoft` scope with version 2.1.0, sets itself up as a workspace root over `packages/*`, builds with tsup and tests with vitest.

One asymmetry is worth flagging before you generate. Three of the four output files are editor or platform specific, so a team that does not use VS Code gets the Copilot instructions and the eval config and little else.

Five commands that scale past a single repository

The command table in the README is short enough to read at a glance, and it maps cleanly onto how large organisations actually adopt a tool like this.

| Workflow | Command | | --- | --- | | Interactive hub | `agentrc` | | One-time setup | `agentrc init` | | CI quality gate | `agentrc readiness --fail-level 3 --json` | | Batch across an org | `agentrc batch` | | Automated PR for any repo | `agentrc pr owner/repo` |

The CI gate is the one to understand first. `--fail-level 3` sets the maturity level below which the run exits non-zero, and `--json` makes the output machine readable. That combination is what turns readiness from a report into a gate: a repository that falls below the threshold stops a build.

`agentrc pr owner/repo` is the one with the widest blast radius, since it opens a pull request against a repository you name rather than the one you are standing in. Useful for a rollout across many repositories, and the command to think carefully about before pointing at a large list.

Both GitHub and Azure DevOps are supported, and the authentication paths in the troubleshooting section match that split: `gh auth login` or `GITHUB_TOKEN` or `GH_TOKEN` for GitHub, `AZURE_DEVOPS_PAT` or `AZDO_PAT` for Azure DevOps. Monorepos and multi-root VS Code workspaces are both called out as supported, along with custom policies for adjusting readiness scoring. There is documentation for each of these areas separately, which is unusual for a project at this stage and suggests the maintainers expected teams to have opinions about their own scoring.

A Node version contradiction worth resolving before you install

The README says AgentRC runs on any repository with Node.js 20 or newer, with no configuration needed. The package manifest in the same repository sets its engines field to `>=22`.

Both statements are unambiguous and they cannot both be true. The resolution is probably that the README sentence predates a decision to raise the floor, which is a common shape for drift: the marketing line is easier to update than the compatibility note, but often nobody owns the second one. Either way, treat 22 as the requirement and expect an engine warning on Node 20 rather than assuming the README was right.

The release history points at the same kind of drift. The three most recent releases are v2.0.1-91, v2.0.1-90 and v2.0.1-89, published on consecutive days in mid-June 2026, and all three have empty release bodies. Meanwhile the package version in the tree is 2.1.0, the highest build suffix in the release list is 91, and the repository was pushed to in late September. A patch-suffix scheme like this one is characteristic of a continuous delivery pipeline publishing every merge, which is a reasonable practice, but it means the releases carry no changelog information at all and you cannot tell from them what changed.

So the practical picture is a project that is moving faster than its release notes. The repository shows 1,075 stars, 94 forks and 53 open issues, and the README carries an experimental warning that says to expect breaking changes and to open an issue with feedback. Under those conditions, pinning a version is not optional.

Distribution, APM, and what the tree reveals

AgentRC is not intended to be the only tool in this space, and the README is unusually clear about the boundary. It generates the content; a separate tool distributes it. APM, the Agent Package Manager from the same organisation, handles instructions, skills and prompts across repositories, and the README describes it as npm for AI agent configs. Teams run `agentrc init` in a project and then `apm install org/standards` to pull shared packages, publish their own conventions as a dedicated APM package, and use `apm audit` plus an `apm-policy.yml` file to enforce standards across a portfolio. The useful detail is that the `.instructions.md` format is shared between both tools, so moving instructions into an APM package needs no conversion.

The file tree shows how much sits beyond the CLI. There is a `vscode-extension/` directory, a `webapp/` with its own `Dockerfile.webapp`, a `plugin/` directory for installing AgentRC as a Copilot agent plugin with built-in skills, an `infra/` directory, an `examples/` directory holding sample configs, evals and policies, and an `.azure-pipelines/` directory that explains how the Azure DevOps support is built. The root also carries a checked-in `agentrc.eval.json` alongside `eval-results.html` and `eval-results.json`, meaning the project evaluates its own instructions against itself.

For the editor experience, the README's troubleshooting entries are telling. Copilot CLI not found means the GitHub Copilot Chat extension is not installed, since the CLI ships bundled with it, and not logged in means running `copilot` in a terminal and using `/login`. Those are the failure modes you will hit first if you try the generation path on a fresh machine, and they are the reason `readiness` is the safer command to start with.

Editorial conclusion

The interesting part of AgentRC is not the scoring, it is the eval loop. Generation alone would be a scaffolding tool, and there are already many of those. The step where the tool runs test cases against its own instructions and lets the result fail a build is what turns context engineering into something measurable. The obstacles are real rather than subtle: the README promises Node 20 while package.json asks for 22 or newer, the newest release predates the current source state by three months, and every generated file is a starting point that your team has to argue with. Run the readiness command first on a repository you know well, look at which pillars it scored low and why, and only then decide whether generating the files is worth it. If the scoring is wrong for your stack, the generation will be wrong in the same direction.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. microsoft/agentrc on GitHub
4. README
5. Releases