CodingWithEase.AiCapabilities.Tool 1.1.1

CodingWithEase AI Capabilities (dotnet-ai) — Capability Providers for AI Coding Agents

An opinionated way to give AI coding agents better context: let your libraries teach the agent, instead of hoping the agent already knows them.

Your .NET libraries expose AI capabilities — canonical templates, component references, code generators — by implementing one small interface. The dotnet-ai tool discovers them and makes them available to any AI coding agent (Claude Code, GitHub Copilot, Codex, Cursor, …) two ways: a plain CLI, and a built-in MCP server.

Traditional:      User → AI agent → (training data + docs) → improvised code
With dotnet-ai:   User → AI agent → capability → the library generates its own canonical output

The library becomes the domain expert. Capability output is the correct pattern for the exact version you have installed — not a guess reconstructed from whatever the model saw during training.

Who this is for

This shines when your code is something AI models were not trained on:

• In-house frameworks with their own component models, naming rules, and architectural invariants. An agent knows Bootstrap and EF Core from the internet; it cannot know your AcmeGrid binds to your IAcmeOperations contract — that knowledge exists only in your repo.
• Non-standard or opinionated codebases — strict conventions, generated-code contracts, unusual patterns that agents constantly "correct" back toward the mainstream style you deliberately avoided.
• Fast-moving internal libraries where hand-written agent instructions (AGENTS.md, CLAUDE.md, rules files) drift out of date. A capability ships inside the package, so guidance is versioned with the code and can never lag behind it.
• Teams using multiple agents — the same capabilities serve Claude, Copilot, Codex, and anything else that can run a CLI or speak MCP. Write the knowledge once, not once per agent.

If your stack is 100% mainstream, agents already do fine. The less your code looks like the training data, the more this helps.

How it works

1. A library implements IAiCapabilityProvider (from the tiny, dependency-free CodingWithEase.AiCapabilities package) and describes its capabilities: name, description, category, tags, JSON input schema.
2. dotnet-ai init scans your workspace, finds every provider, and writes:
   • .dotnet-ai.json — a machine-readable manifest of everything available,
   • AGENTS.NuGet.md — instructions telling AI agents to check the manifest before writing code by hand.
3. The agent discovers what exists (dotnet-ai list) and executes capabilities (dotnet-ai execute, or as MCP tools via dotnet-ai mcp). Output is returned as structured data — the host never writes your project files; the agent stays in control.

Quick start

# Install the tool
dotnet tool install -g CodingWithEase.AiCapabilities.Tool

# In your solution root: discover providers, generate manifest + agent guidance
dotnet-ai init

# See what's available
dotnet-ai list

# Execute a capability (agent-friendly: args from a file, raw output to a file)
dotnet-ai execute CreateGrid --args-file args.json --raw > ProductGrid.razor

Expose capabilities from your own library

dotnet add package CodingWithEase.AiCapabilities

public class MyLibraryAiProvider : IAiCapabilityProvider
{
    public string Name => "MyLibraryAiProvider";
    public string Description => "Canonical usage patterns for MyLibrary.";

    public IEnumerable<AiCapability> GetCapabilities()
    {
        yield return new AiCapability
        {
            Name = "CreateMyGridPage",
            Description = "Returns the canonical MyLibrary grid page for an entity.",
            Category = "Template",
            Tags = ["grid", "crud", "razor"],
            InputSchema = JsonDocument.Parse(
                """{"type":"object","properties":{"entity":{"type":"string"}}}""").RootElement.Clone(),
            OutputType = "RazorMarkup"
        };
    }

    public Task<AiCapabilityResult> ExecuteAsync(string capabilityName, JsonElement arguments, CancellationToken ct = default)
    {
        // Substitute the caller's identifiers into YOUR canonical template and return it.
        return Task.FromResult(AiCapabilityResult.Ok("...generated output..."));
    }
}

Build, run dotnet-ai init, and every AI agent working in that workspace can now discover and use it. Full authoring guidance (capability kinds, naming conventions, schema rules) is below.

MCP server mode

MCP-native agents get the capabilities as first-class, schema'd tools — no shell round-trips, no JSON quoting:

dotnet-ai mcp        # serves the manifest's capabilities as MCP tools over stdio

Example registration (Claude Code .mcp.json; other MCP clients are analogous):

{
  "mcpServers": {
    "dotnet-ai": {
      "command": "dotnet-ai",
      "args": ["mcp", "-p", "/path/to/your/solution"]
    }
  }
}

Commands

Writing good capabilities (the opinionated part)

Three kinds, in order of preference:

1. Template — return the canonical usage shape with the caller's identifiers substituted in ("the grid page for entity X"). Highest value: this is exactly the knowledge that lives in your team's heads and rules files today, but version-locked to the shipped library.
2. Reference — return parameter/API documentation as structured text ("every parameter of MyGrid with type and meaning"). Must work with empty {} input.
3. Codegen — return complete finished files. Use sparingly; agents still need to adapt code to context, and templates transfer the shape better than finished artifacts.

Conventions that keep a capability catalog usable at scale:

• Names: PascalCase, verb-first for generators (CreateX), GetXReference for lookups. Prefix with your library's short name if a cross-package clash is plausible.
• Schemas: always provide a JSON Schema; give every parameter a default in the implementation so execute X '{}' never throws — agents probe with empty args.
• Output: only the artifact — no prose around it. Report failures via AiCapabilityResult.Fail(...), don't throw.
• Treat the provider as part of the library's public surface: when a component's canonical usage changes, updating the capability is part of the same change.

Security model

Discovery (dotnet-ai init)  ──►  Developer Inspection  ──►  Explicit Execution
   (filtered provider load)       (.dotnet-ai.json)        (execute / MCP call)

• Filtered discovery: assemblies are first checked via PE metadata (no code loaded) for a reference to CodingWithEase.AiCapabilities; only assemblies that opted in are then loaded, in an isolated collectible AssemblyLoadContext, to read capability metadata. Reading metadata instantiates the provider class — run init only against source trees you trust (your own solution).
• Inspectable manifest: everything an agent can do is listed in .dotnet-ai.json before anything runs.
• Explicit execution: one capability per call, structured results, and the host never writes project files — file placement stays under the caller's control.
• Staleness detection: the manifest records each provider assembly's path and timestamp; the tool warns when an assembly was rebuilt after init.

Repository layout

Building from source

dotnet build CodingWithEase.AiCapabilities.slnx
dotnet test CodingWithEase.AiCapabilities.slnx
dotnet pack src/CodingWithEase.AiCapabilities.Tool/CodingWithEase.AiCapabilities.Tool.csproj -c Release     # → artifacts/packages
dotnet tool update -g codingwithease.aicapabilities.tool --add-source artifacts/packages

Roadmap

• Build-time capability manifests (source generator → embedded resource) so discovery never instantiates provider code.
• Semantic capability search across large catalogs.
• Capability versioning/negotiation and signing for third-party package trust.

License

MIT