agentskills.codes
AP

api-docs

by monoWritingSource

Writes and maintains XML documentation comments for SkiaSharp APIs. Ensures code remains compliant with .NET documentation standards.

Documentation.NETC#

Install

mkdir -p .claude/skills/api-docs && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/2986" && unzip -o skill.zip -d .claude/skills/api-docs && rm skill.zip

Installs to .claude/skills/api-docs

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.

Write AND review XML API documentation for SkiaSharp (ECMA/mdoc XML in the docs submodule). Two modes: (1) ADD docs for new APIs with "To be added." placeholders; (2) REVIEW existing docs by scope for accuracy, freshness, examples, and hygiene. Triggers: "document class", "add XML docs", "write XML documentation", "fill in missing docs", "remove To be added placeholders", "review documentation", "check docs for errors", "fix doc issues", "audit the docs", "review the font docs", "are the examples correct", "update out-of-date docs", any request to add, validate, correct, or expand SkiaSharp API documentation.
616 charsno explicit “when” triggerlonger than Claude Code's old 250-char listing cap (fine on current versions)
Intermediate

Key capabilities

  • →Add XML documentation to SkiaSharp classes
  • →Review existing documentation for accuracy
  • →Apply .NET XML comment conventions
  • →Validate documentation format and hygiene

How it works

The skill routes documentation tasks to specific procedures that edit ECMA/mdoc XML files, ensuring compliance with .NET standards and SkiaSharp patterns.

Inputs & outputs

You give it
API type or namespace
You get back
Formatted XML documentation files

When to use api-docs

  • →Add XML documentation to classes and methods
  • →Review existing documentation for errors
  • →Apply standard .NET XML comment conventions
  • →Document API class structures

About this skill

API Documentation

Write and review the public API prose that mono/SkiaSharp owns. C# /// comments on public declarations are authoritative. Managed builds generate compiler XML from those comments and package it beside the managed assemblies.

This repository has no API-reference ECMA/mdoc source, mdoc engine, docs submodule, XML-editing workflow, or placeholder-writing workflow. mono/SkiaSharp-API-docs independently consumes package/compiler XML and _DocsMedia, produces ECMA/mdoc, preserves deferred Uno output, validates, and publishes Learn. Do not edit that repository or generated output here.

Scope and procedure

  1. Resolve the consumer-visible public types and members in scope. Read their declarations and implementations in binding/ or source/ before writing any prose. Implementation-assembly XML does not make an API public.
  2. Add or correct accurate /// comments immediately above public declarations. Work from the source declaration, never from compiler XML.
  3. Generated bindings are source-controlled. Edit only their /// comment trivia directly, then run pwsh -NoLogo -NoProfile -File ./utils/generate.ps1 and verify it preserves the intended comments. Never manually change generated declarations, interop code, or implementation.
  4. Follow references/adding.md for source-first authoring or references/reviewing.md for a source-first review. Apply the detailed syntax and prose rules in references/patterns.md.
  5. Refresh documentation-convention knowledge from the first-party sources listed in references/patterns.md before a broad authoring or review pass. Reconcile a changed official convention with existing source forms and external rendering before applying it; do not mechanically rewrite source comments merely to match a style rule.
  6. Verify SkiaSharp and HarfBuzzSharp facts in references/skia-patterns.md, and ensure examples avoid error-obsolete APIs with references/obsolete-api-map.md.
  7. Classify findings with references/checklist.md and perform the build, compiler-XML, and package checks in references/validation.md.

API-documentation contract

  • The compiler XML generated from public /// comments is packaged beside the corresponding managed assemblies in both lib/<tfm> and ref/<tfm>.
  • The XML beside the reference assembly is the consumer-visible documentation contract. The copy beside lib is intentional but implementation-only XML entries do not expand the public API surface.
  • _DocsMedia is versioned source in this repository and a nonshipping transport artifact. The external API-docs repository retrieves matching package and media inputs and owns downstream ECMA/mdoc generation, validation, and publication.

References

NeedRead
Adding or updating source commentsreferences/adding.md
Reviewing documentation and examplesreferences/reviewing.md
C# XML-comment syntax and conventionsreferences/patterns.md
Severity bar and reportingreferences/checklist.md
Build, compiler-XML, and package validationreferences/validation.md
SkiaSharp/HarfBuzzSharp factual sourcesreferences/skia-patterns.md
Error-obsolete API replacementsreferences/obsolete-api-map.md

Boundaries

  • Do not manually edit compiler-generated XML or ECMA/mdoc files. In generated bindings, edit only source-controlled /// comment trivia and verify a generator round trip preserves it.
  • Do not remove valid public source comments to defer documentation elsewhere. Missing or inaccurate public documentation blocks API review.
  • Do not claim defaults, validation, ownership, threading, native layout, or standards behavior without verifying the relevant source.

When not to use it

  • →For non-SkiaSharp API documentation
  • →When editing generated index files

Prerequisites

SkiaSharp source repositorymdoc tooling

Limitations

  • →Only supports SkiaSharp/HarfBuzzSharp components
  • →Requires manual submodule initialization

How it compares

It enforces a structured, machine-validated documentation workflow compared to manual, ad-hoc comment writing.

Compared to similar skills

api-docs side by side with the closest alternatives in the catalog.

SkillInstallsUpdatedSafetyDifficulty
api-docs (this skill)13moNo flagsIntermediate
csharp-developer434moNo flagsAdvanced
csharp-pro95moNo flagsIntermediate
performance-benchmark36moNo flagsIntermediate

Try saying

Example prompts that trigger this skill in your AI assistant.

More by mono

View all by mono →

add-api

mono

Add new C# APIs to SkiaSharp by wrapping Skia C++ functionality. Structured 6-phase workflow: C++ analysis → C API creation → submodule commits → binding generation → C# wrapper → testing. Triggers: - Issue classified as "New API" (after fetching and classification) - Direct request: "add DrawFoo method", "expose SkSurface::draw", "wrap sk_foo_bar" - Keywords: "add API", "expose function", "wrap method", "create binding for"

68

bug-fix

mono

Fix bugs in SkiaSharp C# bindings. Structured workflow for investigating, fixing, and testing bug reports. Triggers: Crash, exception, AccessViolationException, incorrect output, wrong behavior, memory leak, disposal issues, "fails", "broken", "doesn't work", "investigate issue", "fix issue", "look at #NNNN", any GitHub issue number referencing a bug. For adding new APIs, use `add-api` skill instead.

426

native-dependency-update

mono

Update native dependencies (libpng, libexpat, zlib, libwebp, harfbuzz, freetype, libjpeg-turbo, etc.) in SkiaSharp's Skia fork. Handles security CVE fixes, bug fixes, and version bumps. Use when user asks to: - Bump/update a native dependency (libpng, zlib, expat, webp, etc.) - Fix a CVE or security vulnerability in a native library - Update Skia's DEPS file - Check what version of a dependency is currently used - Analyze breaking changes between dependency versions Triggers: "bump libpng", "update zlib", "fix CVE in expat", "update native deps", "what version of libpng", "check for breaking changes". For security audits (finding CVEs, checking PR coverage), use the `security-audit` skill instead.

11

release-branch

mono

Create a release branch for SkiaSharp. Use when user says "release X", "start release X", "create release branch for X", "I want to release", or "release now". This is the FIRST step of releasing - creates branch and pushes to trigger CI. Can auto-detect next preview version from main branch.

12

release-publish

mono

Publish SkiaSharp packages and finalize the release. Use when user says "publish X", "finalize X", "tag X", or "finish release X". This is the FINAL step - after release-testing passes. Publishes to NuGet.org, creates tag, GitHub release, and closes milestone. Triggers: "publish the release", "push to nuget", "create github release", "tag the release", "close the milestone", "annotate release notes", "testing passed what's next", "finalize 3.119.2", "release is ready".

19

release-testing

mono

Run integration tests to verify SkiaSharp NuGet packages work correctly before publishing. Use when user asks to: - Test/verify packages before release - Run integration tests - Test on specific device (iPad, iPhone, Android emulator, Mac, Windows) - Verify SkiaSharp rendering works - Check if packages are ready for publishing - Run smoke/console/blazor/maui tests - Continue with release - Test version X Triggers: "test the release", "verify packages", "run tests on iPad", "check ios tests", "test mac catalyst", "run android tests", "continue", "test 3.119.2-preview.2".

14

You might also like

csharp-developer

zenobi-us

Expert C# developer specializing in modern .NET development, ASP.NET Core, and cloud-native applications. Masters C# 12 features, Blazor, and cross-platform development with emphasis on performance and clean architecture.

43151

csharp-pro

sickn33

Write modern C# code with advanced features like records, pattern matching, and async/await. Optimizes .NET applications, implements enterprise patterns, and ensures comprehensive testing. Use PROACTIVELY for C# refactoring, performance optimization, or complex .NET solutions.

953

performance-benchmark

dotnet

Generate and run ad hoc performance benchmarks to validate code changes. Use this when asked to benchmark, profile, or validate the performance impact of a code change in dotnet/runtime.

328

dotnet-backend-patterns

wshobson

Master C#/.NET backend development patterns for building robust APIs, MCP servers, and enterprise applications. Covers async/await, dependency injection, Entity Framework Core, Dapper, configuration, caching, and testing with xUnit. Use when developing .NET backends, reviewing C# code, or designing API architectures.

722

azure-servicebus-dotnet

microsoft

Azure Service Bus SDK for .NET. Enterprise messaging with queues, topics, subscriptions, and sessions. Use for reliable message delivery, pub/sub patterns, dead letter handling, and background processing. Triggers: "Service Bus", "ServiceBusClient", "ServiceBusSender", "ServiceBusReceiver", "ServiceBusProcessor", "message queue", "pub/sub .NET", "dead letter queue".

316

backend-testing

exceptionless

Backend testing with xUnit, Foundatio.Xunit, integration tests with AppWebHostFactory, FluentClient, ProxyTimeProvider for time manipulation, and test data builders. Keywords: xUnit, Fact, Theory, integration tests, AppWebHostFactory, FluentClient, ProxyTimeProvider, TimeProvider, Foundatio.Xunit, TestWithLoggingBase, test data builders

316

Search skills

Search the agent skills registry