agui-dotnet-feature-workflow
A management hub for implementing features in the AG-UI .NET SDK, ensuring all architecture and testing requirements are met.
Install
mkdir -p .claude/skills/agui-dotnet-feature-workflow && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/10148" && unzip -o skill.zip -d .claude/skills/agui-dotnet-feature-workflow && rm skill.zipInstalls to .claude/skills/agui-dotnet-feature-workflow
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Orchestrator/hub for implementing a feature or change in the AG-UI .NET SDK (sdks/dotnet). USE FOR: "what's the workflow", "what order do I do things in", "how do I implement a feature in the .NET SDK", starting any non-trivial AG-UI .NET SDK change, planning the end-to-end steps and definition-of-done (code + AOT serialization + client/server mapping + unit/integration/cross-language tests + docs + PublicAPI + AGENTS.md sync). DO NOT USE FOR: the deep how-to of a single step — this skill ROUTES to focused siblings: adding wire types (agui-dotnet-wire-types), transport/encoding (agui-dotnet-transport), unit tests (agui-dotnet-unit-tests), integration tests (agui-dotnet-integration-tests), cross-language tests (agui-dotnet-cross-language-tests), porting from TS/Python (agui-cross-sdk-parity), adding a GettingStarted sample Step (agui-dotnet-sample-step), SDK docs (agui-dotnet-sdk-docs), AGENTS/Architecture sync (agui-dotnet-agents-sync), the dojo (agui-dojo), review (agui-dotnet-code-review).Key capabilities
- →Plan SDK feature implementation
- →Verify definition of done
- →Sync architecture documentation
- →Route tasks to specialized skills
How it works
Acts as an orchestrator that maps feature requests to specific sibling skills while enforcing a strict definition of done.
Inputs & outputs
When to use agui-dotnet-feature-workflow
- →Plan a new feature implementation
- →Verify definition of done for an SDK change
- →Sync architecture docs for a new feature
- →Identify workflow steps for .NET SDK modifications
About this skill
AG-UI .NET SDK — Feature Workflow (Orchestrator)
This is the hub skill. Given a request to build or change a feature in the AG-UI
.NET SDK (sdks/dotnet/), it lays out the correct end-to-end order and routes the
depth of each step to a focused sibling skill. It does not duplicate their content.
The SDK has a multi-artifact definition of done. An agent working ad hoc forgets
artifacts — most often cross-language parity, docs, AGENTS.md/docs/architecture.md sync,
and PublicAPI.Unshipped.txt. Use this skill to avoid that.
Package map
sdks/dotnet/src/:
| Package | Responsibility |
|---|---|
AGUI.Abstractions | Wire types: events, messages, tools, capabilities, AGUIJsonSerializerContext |
AGUI.Formatting | JSON formatter + SSE encode/decode |
AGUI.Protobuf | Protobuf encoding of the protocol |
AGUI.Client | AGUIChatClient (IChatClient) + transport negotiation |
AGUI.Server | Hosting-agnostic agent-side conversion (ChatResponseUpdate → events) |
ASP.NET hosting glue lives in samples/AGUI.Samples.Shared (not a src/ package).
sdks/dotnet/AGENTS.md and docs/architecture.md are the canonical description of
the layout and conventions (kept current via agui-dotnet-agents-sync); AGUI.slnx
is the ground truth if you need to re-derive the package list.
Build & test commands
# from sdks/dotnet/
dotnet build sdks/dotnet/AGUI.slnx # whole solution
dotnet test tests/AGUI.Abstractions.UnitTests/ # per-project, fast feedback
Directory.Build.props treats warnings as errors, and PublicApiAnalyzers is on
for every src/ project with a PublicAPI.Shipped.txt. The build fails if you skip
the AOT serialization wiring or forget PublicAPI.Unshipped.txt — these are not
optional polish steps, they are enforced.
Definition of done (feature checklist)
- Wire contract understood (matched against TS/Python reference if wire-affecting)
- Type/behavior implemented in the right package (see map)
- AOT serialization wired (
[JsonSerializable]inAGUIJsonSerializerContext, converter case,[JsonPropertyName]) - Client/server mapping updated (
AGUI.Clientevent→update and/orAGUI.Serverupdate→event) - Unit tests (serialization round-trip + behavior)
- Integration tests (full pipeline) if it crosses the HTTP/SSE boundary
- Cross-language parity tests if wire-affecting
-
PublicAPI.Unshipped.txtupdated for every changed public member - Docs updated (docs.ag-ui.com / SDK docs) if user-facing
-
AGENTS.md/docs/architecture.mdsynced if structure/recipe changed -
dotnet build sdks/dotnet/AGUI.slnxand relevantdotnet testprojects green
Ordered workflow → route each step
Do the steps in this order. Skip a step only if it genuinely doesn't apply (e.g. a non-wire-affecting internal refactor skips cross-language parity).
-
Understand the wire contract. Read the TypeScript (and Python) reference for the type/behavior so the .NET shape matches the spec. Porting an existing feature from another SDK? →
agui-cross-sdk-parity. -
Implement the type/behavior in the right package.
- New/changed wire type (event, message, tool, capability) →
agui-dotnet-wire-types(covers theAGUI.Abstractionsrecipe: class inEvents/,AGUIEventTypesconstant, converter case, AOT registration,PublicAPI.Unshipped.txt). - New/changed transport or encoding (SSE, protobuf, formatter) →
agui-dotnet-transport(AGUI.Formatting,AGUI.Protobuf).
- New/changed wire type (event, message, tool, capability) →
-
Wire AOT serialization. Every protocol type goes through
AGUIJsonSerializerContext— no reflection.agui-dotnet-wire-typeshas the per-type recipe; the build enforces it. -
Update client/server mapping. Server-side
ChatResponseUpdate→ event lives inAGUI.Server; client-side event →ChatResponseUpdatelives inAGUI.Client(EventStreamConverter, builders). Update both directions if the wire shape changed. -
Unit tests (round-trip + behavior) →
agui-dotnet-unit-tests. -
Integration tests (HTTP + SSE pipeline,
WebApplicationFactory,AGUIChatClient) →agui-dotnet-integration-tests. Required when the change crosses the transport boundary. -
Cross-language parity tests (if wire-affecting) →
agui-dotnet-cross-language-tests(tests/AGUI.CrossLanguage.IntegrationTests,CrossLanguage.TestServer,CrossLanguage.Vitest). This is the step agents most often forget — .NET must agree with TS/Python on the bytes. -
Update
PublicAPI.Unshipped.txtfor every changed public member, in each affectedsrc/project. The PublicAPI analyzer fails the build otherwise. -
Docs (user-facing change) →
agui-dotnet-sdk-docs(docs.ag-ui.com). -
Sync
AGENTS.md/docs/architecture.mdif you changed structure, recipes, or commands →agui-dotnet-agents-sync. Fix stale package references while here. -
Build + test green.
dotnet build sdks/dotnet/AGUI.slnx, then the relevantdotnet test <project>(unit + integration + cross-language as applicable). -
Validate & review. Run/inspect in the dojo →
agui-dojo; manual UI/docs checks →agui-playwright-validate; review the change →agui-dotnet-code-review.
Routing table (quick reference)
| Step / need | Sibling skill |
|---|---|
| Add/modify a wire type | agui-dotnet-wire-types |
| Add/modify transport or encoding | agui-dotnet-transport |
| Port a feature from TS/Python | agui-cross-sdk-parity |
| Write unit tests | agui-dotnet-unit-tests |
| Write integration tests | agui-dotnet-integration-tests |
| Write cross-language tests | agui-dotnet-cross-language-tests |
| Add a GettingStarted sample Step (Server/Client pair) | agui-dotnet-sample-step |
| Update SDK docs site | agui-dotnet-sdk-docs |
| Keep AGENTS.md / docs/architecture.md current | agui-dotnet-agents-sync |
| Run/validate in the dojo | agui-dojo |
| Manual UI/docs validation | agui-playwright-validate |
| Review the change | agui-dotnet-code-review |
The depth of each step lives in the sibling skill it routes to; fall back to the recipes in
AGENTS.mdand the deep content indocs/architecture.mdfor anything a sibling doesn't cover.
❌ Anti-patterns
- Don't stop at "it compiles and unit tests pass." Wire-affecting changes are not done until cross-language parity tests and docs are updated.
- Don't put protocol or server code in a sample. It belongs in
src/; the server isAGUI.Server, hosting glue is insamples/AGUI.Samples.Shared, and nosrc/project references ASP.NET. - Don't skip
PublicAPI.Unshipped.txtor AOT registration "to fix later" — the warnings-as-errors build will block you immediately. - Don't do the deep work here. This skill routes; the depth lives in the sibling skills. Open the relevant one before implementing a step.
When not to use it
- →Deep implementation of a single step
Prerequisites
Limitations
- →Does not contain deep implementation logic
- →Strict adherence to definition of done required
How it compares
It provides a centralized hub for end-to-end SDK updates instead of requiring manual coordination of scattered tasks.
Compared to similar skills
agui-dotnet-feature-workflow side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| agui-dotnet-feature-workflow (this skill) | 0 | 1mo | Review | Advanced |
| dotnet-patterns | 0 | 2mo | No flags | Intermediate |
| deepwiki-rs | 25 | 9mo | Review | Intermediate |
| audit-spec | 0 | 6mo | No flags | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
You might also like
dotnet-patterns
tangchunwu
Idiomatic C# and .NET patterns, conventions, dependency injection, async/await, and best practices for building robust, maintainable .NET applications.
deepwiki-rs
sopaco
AI-powered Rust documentation generation engine for comprehensive codebase analysis, C4 architecture diagrams, and automated technical documentation. Use when Claude needs to analyze source code, understand software architecture, generate technical specs, or create professional documentation from any programming language.
audit-spec
LongbowXXX
Audit specification documents for ambiguity, consistency, and architectural compliance.
architecture-refactor
SourceLin
用于执行 Sourcelin 跨端架构重构、目录整理、页面拆分、模块边界治理、规则和文档同步。
specification-architect
adrianpuiu
A rigorous, traceability-first system that generates five interconnected architectural documents (blueprint.md, requirements.md, design.md, tasks.md, and validation.md) with complete requirements-to-implementation traceability. Use this skill when users need to architect systems, create technical specifications, or develop structured project documentation with guaranteed traceability.
codebase-documenter
mhattingpete
Generates comprehensive documentation explaining how a codebase works, including architecture, key components, data flow, and development guidelines. Use when user wants to understand unfamiliar code, create onboarding docs, document architecture, or explain how the system works.