How do I install the API Add Review skill?

Run npx skillmds@latest add mono/api-add-review in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is API Add Review safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with API Add Review?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is API Add Review free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published API Add Review?

mono (@mono) published this skill. Their other Agent Skills are listed on their SkillMD profile.

API Add Review by mono — Agent Skill

Name: API Add Review
Author: mono

API Add Review

Add new C# APIs to SkiaSharp by wrapping Skia C++ functionality, or review existing API PRs for correctness and style. Two workflows: (1) Add: C++ analysis → C API → bindings → C# wrapper → tests → review (2) Review: check naming, Span overloads, properties, tests, interop safety. Triggers: - "add DrawFoo method", "expose SkSurface::draw", "wrap sk_foo_bar" - "add API", "expose function", "wrap method", "create binding for" - "review this API", "check the API surface", "review PR #NNN for API design" - Issue classified as "New API" (after fetching and classification)

mono 1b70bca 5 files · 22.6 KB Updated Sep 17, 2026

File contents

Add / Review API Skill

This skill has two modes:

Add mode — implement a new API from scratch, then review it
Review mode — review an existing PR/diff for API design correctness

Both modes share the same design rules and quality bar.

Detecting Mode

User says	Mode
"add", "expose", "wrap", "create binding"	Add
"review", "check API", "look at PR"	Review
Issue classified as "New API"	Add
Self-review after adding	Review (automatic)

⚠️ Branch Protection (COMPLIANCE REQUIRED)

🛑 NEVER commit directly to protected branches. This is a policy violation.

Repository	Protected Branches	Required Action
SkiaSharp (parent)	`main`	Create feature branch first
externals/skia (submodule)	`main`, `skiasharp`	Create feature branch first

❌ NEVER Do These

Shortcut	Consequence
Commit directly to `main` or `skiasharp`	Policy violation
Edit `*.generated.cs` manually	Overwritten on regenerate
Skip native build after C API change	`EntryPointNotFoundException`
Skip tests	Unacceptable
Skip tests because they fail	Unacceptable — fix the issue
Use default parameters in public APIs	ABI breaking change
Invent type names not in upstream Skia	Confusing, wrong naming
Add XML doc comments	Inserted by separate process
Fabricate test fonts	Use real fonts from known sources

References

All three references work together:

File	Purpose	When to read
references/api-design-rules.md	Naming, properties vs methods, Span patterns, type wrapping, test and sample requirements	Always — before writing or reviewing any API
references/add-workflow.md	Step-by-step add workflow with C API patterns, struct conversion, JSON config, gallery samples	Add mode
references/review-workflow.md	Structured review checklist, test coverage analysis, sample review, auto-fix mode	Review mode, and as final phase of add mode
references/troubleshooting.md	Common errors and fixes	When something goes wrong

Add Mode

Read api-design-rules.md
Follow add-workflow.md phases 1-10
Run review-workflow.md on your own changes
Fix any issues identified by the review
Re-run tests to confirm

Review Mode

Read api-design-rules.md
Follow review-workflow.md
In fix-first mode: auto-fix high-confidence issues, re-run tests
In review-only mode: produce structured feedback report

---name: api-add-reviewdescription: Add new C# APIs to SkiaSharp by wrapping Skia C++ functionality, or review existing API PRs for correctness and style. Two workflows: (1) Add: C++ analysis → C API → bindings → C# wrapper → tests → review (2) Review: check naming, Span overloads, properties, tests, interop safety. Triggers: - "add DrawFoo method", "expose SkSurface::draw", "wrap sk_foo_bar" - "add API", "expose function", "wrap method", "create binding for" - "review this API", "check the API surface", "review PR #NNN for API design" - Issue classified as "New API" (after fetching and classification)---# Add / Review API SkillThis skill has two modes:1. **Add mode** — implement a new API from scratch, then review it2. **Review mode** — review an existing PR/diff for API design correctnessBoth modes share the same design rules and quality bar.## Detecting Mode| User says | Mode ||-----------|------|| "add", "expose", "wrap", "create binding" | Add || "review", "check API", "look at PR" | Review || Issue classified as "New API" | Add || Self-review after adding | Review (automatic) |## ⚠️ Branch Protection (COMPLIANCE REQUIRED)> **🛑 NEVER commit directly to protected branches. This is a policy violation.**| Repository | Protected Branches | Required Action ||------------|-------------------|-----------------|| SkiaSharp (parent) | `main` | Create feature branch first || externals/skia (submodule) | `main`, `skiasharp` | Create feature branch first |## ❌ NEVER Do These| Shortcut | Consequence ||----------|-------------|| Commit directly to `main` or `skiasharp` | Policy violation || Edit `*.generated.cs` manually | Overwritten on regenerate || Skip native build after C API change | `EntryPointNotFoundException` || Skip tests | Unacceptable || Skip tests because they fail | Unacceptable — fix the issue || Use default parameters in public APIs | ABI breaking change || Invent type names not in upstream Skia | Confusing, wrong naming || Add XML doc comments | Inserted by separate process || Fabricate test fonts | Use real fonts from known sources |## ReferencesAll three references work together:| File | Purpose | When to read ||------|---------|-------------|| [references/api-design-rules.md](references/api-design-rules.md) | Naming, properties vs methods, Span patterns, type wrapping, test and sample requirements | Always — before writing or reviewing any API || [references/add-workflow.md](references/add-workflow.md) | Step-by-step add workflow with C API patterns, struct conversion, JSON config, gallery samples | Add mode || [references/review-workflow.md](references/review-workflow.md) | Structured review checklist, test coverage analysis, sample review, auto-fix mode | Review mode, and as final phase of add mode || [references/troubleshooting.md](references/troubleshooting.md) | Common errors and fixes | When something goes wrong |## Add Mode1. Read [api-design-rules.md](references/api-design-rules.md)2. Follow [add-workflow.md](references/add-workflow.md) phases 1-103. Run [review-workflow.md](references/review-workflow.md) on your own changes4. Fix any issues identified by the review5. Re-run tests to confirm## Review Mode1. Read [api-design-rules.md](references/api-design-rules.md)2. Follow [review-workflow.md](references/review-workflow.md)3. In fix-first mode: auto-fix high-confidence issues, re-run tests4. In review-only mode: produce structured feedback report

Frequently asked questions