microsoft-extensions-ai

Name: microsoft-extensions-ai
Author: managedcode

461stars35forks

How to install microsoft-extensions-ai?

managedcode/dotnet-skills/microsoft-extensions-ai

$npx -y skills add managedcode/dotnet-skills --skill microsoft-extensions-ai

Installs into the current project.

Summary

Build provider-agnostic .NET AI integrations with Microsoft.Extensions.AI, IChatClient, embeddings, middleware, structured output, vector search, and evaluation. USE FOR: building or reviewing .NET code that uses Microsoft.Extensions.AI, Microsoft.Extensions.AI.Abstractions,

Files · 1

View on GitHub

SKILL.md

1	# Microsoft.Extensions.AI
2
3	## Trigger On
4
5	- building or reviewing `.NET` code that uses `Microsoft.Extensions.AI`, `Microsoft.Extensions.AI.Abstractions`, `IChatClient`, `IEmbeddingGenerator`, `ChatOptions`, or `AIFunction`
6	- adding `IImageGenerator`, local-model chat via Ollama, AI app templates, or the `.NET AI` quickstarts for assistants and MCP
7	- choosing between low-level AI abstractions, provider SDKs, vector-search composition, evaluation libraries, and a fuller agent framework
8	- adding streaming chat, structured output, embeddings, tool calling, telemetry, caching, or DI-based AI middleware
9	- wiring `Microsoft.Extensions.VectorData`, `Microsoft.Extensions.DataIngestion`, MCP tooling, or evaluation packages around a provider-agnostic AI app
10
11	## Workflow
12
13	1. Classify the request first: plain model access, tool calling, embeddings/vector search, evaluation, image generation, local-model prototyping, MCP bootstrap, or true agent orchestration.
14	2. Default to `Microsoft.Extensions.AI` for application and service code that needs provider-agnostic chat, embeddings, middleware, structured output, and testability.
15	3. Reference `Microsoft.Extensions.AI.Abstractions` directly only when authoring provider libraries or lower-level reusable integration packages.
16	4. Model `IChatClient` and `IEmbeddingGenerator` composition explicitly in DI. Keep options, caching, telemetry, logging, and tool invocation inspectable in the pipeline.
17	5. Treat chat state deliberately. For stateless providers, resend history. For stateful providers, propagate `ConversationId` rather than assuming all providers behave the same way.
18	6. Use `Microsoft.Extensions.VectorData` and `Microsoft.Extensions.DataIngestion` as adjacent building blocks for RAG instead of hand-rolling store abstractions prematurely. Treat the embedding model, vector dimensions, and collection schema as one owned contract: changing any of them means reindexing rather than reusing old vector data. Keep vector API source-breaking notes version-aware; in the 10.5+ line, named-argument usage of `VectorStoreVectorAttribute` uses `dimensions:`.
19	7. Treat the `.NET AI` quickstarts as bootstrap paths, not finished architecture. They now cover minimal assistants, MCP client/server flows, local models, app templates, and image generation. Start there for a vertical slice, then harden the DI, telemetry, and evaluation story here.
20	8. Escalate to `microsoft-agent-framework` when the requirement becomes agent threads, multi-agent orchestration, higher-order workflows, durable execution, or remote agent hosting.
21	9. Validate with real providers, realistic prompts, and evaluation gates so the abstraction layer actually buys portability and reliability.
22
23	## Architecture
24
25	```mermaid
26	flowchart LR
27	A["Task"] --> B{"Need agent threads, multi-agent orchestration, or remote agent hosting?"}
28	B -->\|Yes\| C["Use Microsoft Agent Framework on top of `Microsoft.Extensions.AI.Abstractions`"]
29	B -->\|No\| D{"Need provider-agnostic chat, embeddings, tools, typed output, or evaluation?"}
30	D -->\|Yes\| E["Use `Microsoft.Extensions.AI`"]
31	E --> F["Compose `IChatClient` / `IEmbeddingGenerator` in DI"]
32	F --> G["Add caching, telemetry, tools, vector data, and evaluation deliberately"]
33	D -->\|No\| H["Use plain provider SDKs or deterministic .NET code"]
34	```
35
36	## Core Knowledge
37
38	- `Microsoft.Extensions.AI.Abstractions` contains the core exchange contracts such as `IChatClient`, `IEmbeddingGenerator<TInput, TEmbedding>`, message/content types, and tool abstractions.
39	- `Microsoft.Extensions.AI` adds the higher-level application surface: middleware builders, automatic function invocation, caching, logging, and OpenTelemetry integration.
40	- Most apps and services should reference `Microsoft.Extensions.AI`; provider and connector libraries usually reference only the abstractions package.
41	- `IChatClient` centers on `GetResponseAsync` and `GetStreamingResponseAsync`. The returned `ChatResponse` or `ChatResponseUpdate` objects carry messages, tool-related content, metadata, and optional conversation identifiers.
42	- Local-model quickstarts still route through the same `IChatClient` abstraction. Ollama-backed clients are usefu

People who liked this also viewed

6 picks

Type

microsoft-extensions-ai

461stars35forks

View on GitHub

How to install microsoft-extensions-ai?

managedcode/dotnet-skills/microsoft-extensions-ai

$npx -y skills add managedcode/dotnet-skills --skill microsoft-extensions-ai

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Microsoft.Extensions.AI
2
3	## Trigger On
4
5	- building or reviewing `.NET` code that uses `Microsoft.Extensions.AI`, `Microsoft.Extensions.AI.Abstractions`, `IChatClient`, `IEmbeddingGenerator`, `ChatOptions`, or `AIFunction`
6	- adding `IImageGenerator`, local-model chat via Ollama, AI app templates, or the `.NET AI` quickstarts for assistants and MCP
7	- choosing between low-level AI abstractions, provider SDKs, vector-search composition, evaluation libraries, and a fuller agent framework
8	- adding streaming chat, structured output, embeddings, tool calling, telemetry, caching, or DI-based AI middleware
9	- wiring `Microsoft.Extensions.VectorData`, `Microsoft.Extensions.DataIngestion`, MCP tooling, or evaluation packages around a provider-agnostic AI app
10
11	## Workflow
12
13	1. Classify the request first: plain model access, tool calling, embeddings/vector search, evaluation, image generation, local-model prototyping, MCP bootstrap, or true agent orchestration.
14	2. Default to `Microsoft.Extensions.AI` for application and service code that needs provider-agnostic chat, embeddings, middleware, structured output, and testability.
15	3. Reference `Microsoft.Extensions.AI.Abstractions` directly only when authoring provider libraries or lower-level reusable integration packages.
16	4. Model `IChatClient` and `IEmbeddingGenerator` composition explicitly in DI. Keep options, caching, telemetry, logging, and tool invocation inspectable in the pipeline.
17	5. Treat chat state deliberately. For stateless providers, resend history. For stateful providers, propagate `ConversationId` rather than assuming all providers behave the same way.
18	6. Use `Microsoft.Extensions.VectorData` and `Microsoft.Extensions.DataIngestion` as adjacent building blocks for RAG instead of hand-rolling store abstractions prematurely. Treat the embedding model, vector dimensions, and collection schema as one owned contract: changing any of them means reindexing rather than reusing old vector data. Keep vector API source-breaking notes version-aware; in the 10.5+ line, named-argument usage of `VectorStoreVectorAttribute` uses `dimensions:`.
19	7. Treat the `.NET AI` quickstarts as bootstrap paths, not finished architecture. They now cover minimal assistants, MCP client/server flows, local models, app templates, and image generation. Start there for a vertical slice, then harden the DI, telemetry, and evaluation story here.
20	8. Escalate to `microsoft-agent-framework` when the requirement becomes agent threads, multi-agent orchestration, higher-order workflows, durable execution, or remote agent hosting.
21	9. Validate with real providers, realistic prompts, and evaluation gates so the abstraction layer actually buys portability and reliability.
22
23	## Architecture
24
25	```mermaid
26	flowchart LR
27	A["Task"] --> B{"Need agent threads, multi-agent orchestration, or remote agent hosting?"}
28	B -->\|Yes\| C["Use Microsoft Agent Framework on top of `Microsoft.Extensions.AI.Abstractions`"]
29	B -->\|No\| D{"Need provider-agnostic chat, embeddings, tools, typed output, or evaluation?"}
30	D -->\|Yes\| E["Use `Microsoft.Extensions.AI`"]
31	E --> F["Compose `IChatClient` / `IEmbeddingGenerator` in DI"]
32	F --> G["Add caching, telemetry, tools, vector data, and evaluation deliberately"]
33	D -->\|No\| H["Use plain provider SDKs or deterministic .NET code"]
34	```
35
36	## Core Knowledge
37
38	- `Microsoft.Extensions.AI.Abstractions` contains the core exchange contracts such as `IChatClient`, `IEmbeddingGenerator<TInput, TEmbedding>`, message/content types, and tool abstractions.
39	- `Microsoft.Extensions.AI` adds the higher-level application surface: middleware builders, automatic function invocation, caching, logging, and OpenTelemetry integration.
40	- Most apps and services should reference `Microsoft.Extensions.AI`; provider and connector libraries usually reference only the abstractions package.
41	- `IChatClient` centers on `GetResponseAsync` and `GetStreamingResponseAsync`. The returned `ChatResponse` or `ChatResponseUpdate` objects carry messages, tool-related content, metadata, and optional conversation identifiers.
42	- Local-model quickstarts still route through the same `IChatClient` abstraction. Ollama-backed clients are usefu

People who liked this also viewed

6 picks

Type