Context.Net 1.0.0

<p align="center"> <img src="docs/context.png" alt="context banner" width="960" /> </p>

context is a .NET global CLI tool that allows you to fetch the source code snapshots of NuGet packages you are using in your project.

It was built primarily for code agents. When an agent needs implementation detail from a dependency, it can use context to fetch the exact source snapshot your project is already using instead of relying on online docs, decompiled package contents, or repeated remote lookups.

This project was inspired by opensrc from Vercel.

Install

dotnet tool install --global Context.Net

Upgrade:

dotnet tool update --global Context.Net

Uninstall:

dotnet tool uninstall --global Context.Net

Local development install from a packed artifact:

dotnet pack src/Context.Cli/Context.Cli.csproj -c Release -o artifacts
dotnet tool install --tool-path .tool-smoke --add-source artifacts Context.Net
./.tool-smoke/context --help

Release

This repo uses an explicit manual-first release flow.

Create a local secrets file:

cp .env.local.example .env.local

Then set your NuGet API key in .env.local:

NUGET_API_KEY=your-nuget-api-key
NUGET_SOURCE=https://api.nuget.org/v3/index.json

Typical release flow:

scripts/release-version.sh 1.0.0
git commit -am "chore: release 1.0.0"

scripts/release-pack.sh
scripts/release-publish.sh
scripts/release-github.sh

What the scripts do:

• scripts/release-version.sh <version> Updates the shared package version in Directory.Build.props.
• scripts/release-pack.sh Runs tests and produces the NuGet package in artifacts/.
• scripts/release-publish.sh Pushes the current package version to NuGet using NUGET_API_KEY.
• scripts/release-github.sh Creates and pushes a v<version> tag and opens a GitHub release with generated notes.

Basic Usage

Fetch one or more packages already resolved by the selected project:

context Newtonsoft.Json
context Polly Serilog

List fetched sources:

context list
context list --json

Remove specific package entries:

context remove Newtonsoft.Json

Clear all fetched sources for the workspace:

context clean

Common Options

Use a specific workspace root for .context/, .gitignore, and AGENTS.md:

context Newtonsoft.Json --cwd "$PWD"

Choose a project explicitly:

context Newtonsoft.Json --project src/MyApp/MyApp.csproj

Disambiguate multi-target restores:

context NodaTime --framework net10.0

Allow or skip managed file updates without prompting:

context Newtonsoft.Json --allow-file-updates
context Newtonsoft.Json --no-file-updates

Example Workflow

Create a sample app and fetch a dependency source snapshot:

dotnet new console --framework net10.0
dotnet add package Newtonsoft.Json --version 13.0.3

context Newtonsoft.Json --cwd "$PWD" --no-file-updates
context list --cwd "$PWD" --json

You will then find the exact checkout path in .context/sources.json.

Why This Exists

When a code agent or developer needs to understand dependency behavior, the most useful thing is usually the exact source for the exact package version the project already restored.

context exists to make that local and explicit:

• exact version from project.assets.json
• exact commit metadata first
• exact tag fallback
• local files under .context/repos/...

That makes implementation inspection more reliable and easier to automate.

What Gets Written

The tool writes fetched sources under:

.context/

Important files:

• .context/sources.json The source index with package ID, resolved version, repository URL, commit or tag, and local path.
• .context/repos/... The fetched working copies.

If you allow file updates, context also updates:

• .gitignore
• a managed section in AGENTS.md

Those writes are relative to the workspace root, not automatically the project directory.

Supported Currently

• .NET 10
• SDK-style projects
• PackageReference
• Central Package Management
• direct and transitive packages already resolved by restore
• public GitHub repositories
• exact commit metadata, then exact tag fallback

Not Supported Yet

• private feeds
• private Git hosts
• GitHub Enterprise
• packages.config
• branch fallback
• monorepo subdirectory detection
• arbitrary package fetches outside the current restore graph

That last point is intentional for v1: today context fetches packages already resolved by the selected project. Fetching packages that are not part of the project graph is a reasonable future feature, but it is not part of the current contract.

Gotchas

macOS PATH setup

If the tool installs successfully but context is still not found in zsh, your shell probably does not have the .NET global tools path on PATH.

Global tools are typically installed to:

$HOME/.dotnet/tools

Add that to your shell profile:

echo 'export PATH="$HOME/.dotnet/tools:$PATH"' >> ~/.zprofile
source ~/.zprofile

If your terminal session uses ~/.zshrc instead, put it there instead:

echo 'export PATH="$HOME/.dotnet/tools:$PATH"' >> ~/.zshrc
source ~/.zshrc

Workspace root vs project directory

The selected project may be inside the workspace, but .context/, .gitignore, and AGENTS.md are written relative to the workspace root, which is --cwd or the current directory.

A Git repository is not required

context can fetch sources into .context/ in a plain directory. The workspace itself does not need to be a Git repo.

FAQ

Why did I build this

Because code agents need better context for the specific SDK version you'll be using.

If an agent can read the exact dependency source your project is already using, it has a much better chance of making the right change or explaining the real behavior.

Why is this useful over something like Context7

context is local-first and source-first.

It fetches the exact source snapshot into your workspace, which means the agent can inspect local files directly instead of chaining repeated external calls to retrieve docs or repository details.

That gives you:

• exact source code, not just docs
• fewer remote dependencies in the workflow
• local paths agents can inspect directly
• less risk of outdated or mismatched documentation

Why not just use decompiled source from ~/.nuget/packages

Decompiled package contents are often useful for a rough look, but they are still a reconstruction.

context prefers exact repository source snapshots tied to the package metadata, which is a better fit when you want implementation confidence.

Won't cloning repositories locally waste tokens

Usually the opposite.

Once the exact source is local, an agent can read the relevant files directly instead of repeatedly calling external tools to discover docs or repository details. That is often faster and more token efficient overall.

Is this token efficient

Usually yes.

For code agents, repeated tool calls to remote documentation services, MCP servers, package pages, and web search are often more token expensive than reading a local source tree once it has already been fetched.

context reduces that overhead by putting the exact dependency source in a local path under .context/repos/..., where an agent can inspect the real implementation directly.

That usually means:

• fewer chained remote calls
• more accurate retrieval for the exact API or interface you care about
• less risk of landing on outdated or mismatched documentation
• faster iteration once the source snapshot is local

What is this useful for beyond debugging

It is useful any time you need implementation detail:

• understanding SDK behavior
• verifying whether a bug is in your code or in dependency behavior
• comparing versions
• borrowing a small implementation pattern from an external dependency when appropriate

Is this only for agents

No, but agents were the primary design target.

It is still useful for any developer who wants exact local dependency source without manually tracking down the matching repository and revision.

Validation

Useful local validation commands for this repository:

dotnet test Context.Net.sln
dotnet pack src/Context.Cli/Context.Cli.csproj -c Release -o artifacts
dotnet tool install --tool-path .tool-smoke --add-source artifacts Context.Net