CtrlK
BlogDocsLog inGet started
Tessl Logo

agui-dotnet-feature-workflow

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).

75

Quality

92%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

SKILL.md
Quality
Evals
Security

Quality

Content

85%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A well-executed orchestrator body: ordered steps with a definition-of-done checklist, build-enforced validation, and disciplined delegation of depth to sibling skills. The only real flaws are mild redundancy (routing info restated three times) and a copy-paste inconsistency in the build/test command snippet's working-directory paths.

Suggestions

conciseness: drop or compress the 'Routing table (quick reference)' section — it duplicates the sibling-skill pointers already embedded in steps 1–12 and in the frontmatter, saving ~20 lines without losing any route.

actionability: make the build & test snippet internally consistent — either drop the 'sdks/dotnet/' prefix from the build command or change the comment from '# from sdks/dotnet/' to the repo root, so both commands are copy-paste executable from one stated directory.

conciseness: merge step 11 ('Build + test green') into the definition-of-done checklist (its last checkbox already states the same gate) to remove one repeated instruction.

DimensionReasoningScore

Conciseness

The body is dense and assumes competence (package map table, warnings-as-errors fact, no explanations of concepts Claude already knows), matching 'Efficient; minor instances of over-explanation that could be trimmed'. The routing information appears three times (frontmatter DO-NOT-USE list, the 12 ordered steps, and the routing table), so the routing table could be trimmed — but there is no real padding that would justify 3.

4 / 5

Actionability

Concrete commands and paths throughout ('dotnet build sdks/dotnet/AGUI.slnx', 'dotnet test tests/AGUI.Abstractions.UnitTests/', 'AGUIJsonSerializerContext', 'PublicAPI.Unshipped.txt', per-package responsibilities), matching 'Mostly executable guidance; concrete code or commands with minor gaps'. The gap: the snippet is annotated '# from sdks/dotnet/' yet the build command also includes the 'sdks/dotnet/' prefix, so one of the two forms is wrong if executed as written.

4 / 5

Workflow Clarity

A 12-step ordered workflow with an explicit skip rule ('Skip a step only if it genuinely doesn't apply'), a definition-of-done checklist, and an explicit validation gate in step 11 ('dotnet build sdks/dotnet/AGUI.slnx', then relevant 'dotnet test' green) followed by step 12 validate/review, with build failures framed as immediate enforcement ('will block you immediately') acting as an error-recovery loop. This matches 'Clear sequence with explicit validation steps; feedback loops for error recovery; checklists for complex processes'.

5 / 5

Progressive Disclosure

This is a pure hub skill and the body is structured exactly as one: a short overview, a package map, commands, a checklist, and one-level-deep pointers to named sibling skills and repo docs ('AGENTS.md and docs/architecture.md are the canonical description'; 'The depth of each step lives in the sibling skill'). No bundle files exist (no references/, scripts/, or assets/ directories), and all pointers are one level deep and clearly signaled — matching 'Clear overview with well-signaled one-level-deep references'.

5 / 5

Total

18

/

20

Passed

Description

100%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

An exemplary hub-skill description: third-person, dense, concrete, with quoted user trigger phrases, an explicit USE FOR / DO NOT USE FOR split, and full enumeration of the definition-of-done scope. It reads like a routing index rather than marketing copy, and every clause earns its tokens.

DimensionReasoningScore

Specificity

The description lists multiple concrete capabilities: 'Orchestrator/hub for implementing a feature or change in the AG-UI .NET SDK (sdks/dotnet)' plus a fully enumerated definition-of-done ('code + AOT serialization + client/server mapping + unit/integration/cross-language tests + docs + PublicAPI + AGENTS.md sync'). It matches the anchor 'Lists multiple specific concrete actions; comprehensive coverage'; there is no vagueness that would push it toward 4.

5 / 5

Completeness

Both halves are explicit: the 'what' is stated in third person ('Orchestrator/hub... ROUTES to focused siblings') and the 'when' is given as 'USE FOR:' with concrete trigger phrases, further sharpened by a 'DO NOT USE FOR:' clause. This is exactly the anchor-5 pattern ('Clearly and explicitly answers both what AND when with concrete trigger phrases').

5 / 5

Trigger Term Quality

Natural user phrasing is quoted verbatim — "what's the workflow", "what order do I do things in", "how do I implement a feature in the .NET SDK" — alongside domain keywords (AG-UI .NET SDK, sdks/dotnet) and sibling skill names. This matches 'Comprehensive coverage of natural terms including synonyms'; nothing a user would naturally say is missing, so 4 is too low.

5 / 5

Distinctiveness Conflict Risk

It carves out a clear niche (feature workflow for one SDK at one path) and preempts overlap by naming all 11 sibling skills in 'DO NOT USE FOR' ('the deep how-to of a single step — this skill ROUTES to focused siblings'). Minimal conflict risk, matching 'Clear niche with distinct triggers'.

5 / 5

Total

20

/

20

Passed

Validation

100%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository
ag-ui-protocol/ag-ui
Reviewed

Table of Contents

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.