| name | api-add-review |
| description | 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 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
