Installing

Precept ships as a set of NuGet packages. Pick the one for what you are testing; each brings in Precept.Core and everything else it needs.

Package	Install it to
`Precept.TestPlatform`	Run Precept tests. This is the runner — a test project starts here.
`Precept.Reqnroll`	Write scenarios in `.feature` files. Carries both Reqnroll plugins, so nothing else is needed for Gherkin.
`Precept.Api`	Call HTTP APIs.
`Precept.Web`	Drive a browser through Playwright.
`Precept.Screenplay`	Write the suite as actors performing interactions. Brings `Precept.Web` with it.
`Precept.Data`	Talk to a database over ADO.NET.
`Precept.TestData`	Manage the users, clients, vehicles and other records the tests need.
`Precept.Files`	Write and read Excel, CSV, JSON and XML files.
`Precept.Grpc`	Call gRPC services.
`Precept.Containers`	Start Docker dependencies for the run.
`Precept.Reporting.ReportPortal`	Report runs to ReportPortal.
`Precept.Reporting.Teams`	Post a run summary to a Teams channel.
`Precept.Reporting.AzureDevOps`	File results against Azure DevOps test cases.

Precept.Core is published too, but referencing it directly is only useful for a library of shared step definitions or helpers that must not drag in the runner — or for a reporter of your own, which needs nothing else.

Precept.Mcp is published as a dotnet tool, not a library — it is a server a coding agent talks to, so nothing in a test project references it:

dotnet tool install --global Precept.Mcp

Point an MCP client at the precept-mcp command, or at dnx Precept.Mcp to run it without installing anything. See docs/packages/Precept.Mcp.md, and Working with a coding agent for the skills and the Copilot agent that go with it.

The tool package bundles its own Precept.Core, so the server answers out of its version rather than the project's — which is why a global install, being one version for the whole machine, can answer a second repository with the first one's rules. It reports the difference rather than hiding it: every answer names the version behind it, and precept_diagnose_project raises PMCP008 when the two could disagree. dnx Precept.Mcp@<version> pins it per project.

A complete test project:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>net10.0</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Precept.TestPlatform" Version="0.10.0" />
    <PackageReference Include="Precept.Reqnroll" Version="0.10.0" />
    <PackageReference Include="Precept.Api" Version="0.10.0" />
  </ItemGroup>

</Project>

That is the whole file. Precept.TestPlatform makes the project an executable and generates the entry point, so there is no Main and no OutputType to write; Precept.Reqnroll brings the code-behind generator, so .feature files compile on their own. The first build leaves a commented precept.json in the project — see Configuration.

One thing a NuGet package cannot do for you: dotnet test on the .NET 10 SDK has to be told to use Microsoft.Testing.Platform, and that setting lives in global.json. The SDK reads that file from the directory dotnet test is run in and the directories above it — not from the project's — so put it at the repository root, beside the solution, and merge the section into the global.json already there if the repository pins an SDK version. A copy inside the project directory works only when the command is run from inside that directory, and it replaces the root's SDK pin for that subtree.

{
  "test": {
    "runner": "Microsoft.Testing.Platform"
  }
}

Without it dotnet test fails with "Testing with VSTest target is no longer supported". Running the test binary directly — dotnet run -- --list-tests — works either way. precept_diagnose_project reports a missing declaration as PMCP003, and one that sits inside a project under a repository root as PMCP010.