Issue Repro

Issue Reproduction

Issue pipeline: Step 2 of 3 (Repro). See documentation/dev/issue-pipeline.md.

Systematically reproduce a SkiaSharp issue and produce structured, schema-validated reproduction JSON.

⛔ MANDATORY FIRST STEPS (do not skip)

1. Read THIS entire SKILL.md before any investigation
2. Read references/schema-cheatsheet.md for required fields and enums
3. Read references/anti-patterns.md for critical rules

These 3 reads are REQUIRED. Do not proceed to Phase 1 until all three are loaded.

Quick flow:

1. Load issue + any prior triage JSON
2. Read references: schema-cheatsheet, anti-patterns
3. Create brief plan (5-10 lines: strategy, platform, expected outcome)
4. Check environment: docker info, dotnet --version, available simulators
5. Build repro project and attempt reproduction
6. Test multiple SkiaSharp versions (3A reporter's → 3B latest → 3C main)
7. Generate JSON → validate → persist

Phase 1 (Fetch) → Phase 2 (Assess) → Phase 3 (Reproduce) → Phase 4 (JSON + Output) → Phase 5 (Validate) → Phase 6 (Persist & Present)

Phase 1 — Fetch Issue

1. Read the issue (preferred):

   CACHE=".data-cache/repos/mono-SkiaSharp"
   [ -d ".data-cache" ] || git worktree add .data-cache docs-data-cache
   git -C .data-cache pull --rebase origin docs-data-cache
   cat $CACHE/github/items/{number}.json

   Fallback: gh issue view {number} --repo mono/SkiaSharp --json title,body,labels,comments,state,createdAt,closedAt,author
2. Triage boost — if $CACHE/ai-triage/{number}.json exists, extract classification.platforms[], evidence.bugSignals, analysis.nextQuestions[], and output.actionability.suggestedReproPlatform as hints (verify independently). The suggestedReproPlatform (linux|macos|windows) indicates which CI runner was selected for reproduction.

Phase 2 — Assess & Plan

1. Classify

Read references/bug-categories.md to classify the issue type and determine the reproduction strategy. That file covers bugs (Sections 1–6), enhancements (Section 7), platform parity gaps (Section 8), and documentation issues (Section 9) — including which conclusion values and layer to use for each.

2. Extract reporter's version & TFM

• {reporter_version}: exact SkiaSharp NuGet version
• {reporter_tfm}: target framework (e.g., net10.0)
• {reporter_code}: reproduction code from the issue
• Reporter's platform/OS

If not stated, use the latest stable release. .NET is forward-compatible — net8.0 libraries work on net10.0 apps. Never say "doesn't support .NET X" for newer TFMs.

3. Environment check

⚠️ Run dotnet --info in /tmp/skiasharp/repro/{timestamp}/{number}/ (NOT the SkiaSharp repo, which has global.json pinning SDK 8.0). Record SDK version, workload versions, and runtime version. {timestamp} is the current UTC time in yyyyMMdd-HHmmss format.

Also check: Docker (docker --version), Playwright MCP tools, GPU availability, .NET workloads (dotnet workload list). Install missing workloads now — don't wait.

4. Determine reproduction platform

All platform files fall back to platform-console.md for core SkiaSharp bugs.

Tie-breaking: If multiple platform signals (e.g., "WASM + WPF"), use the highest priority. If reporter says "works on X, fails on Y", reproduce on Y first, test X in Phase 3D.

Read the selected platform file. Follow its Create → Build → Run → Verify steps, substituting {reporter_version}, {reporter_tfm}, and {reporter_code}.

5. Plan

Output a brief plan before executing (5-10 lines: what platform, what version, what approach).

Key Rules (read before Phase 3)

Read references/anti-patterns.md for the full list. Critical rules:

1. Source code investigation. Stop at "did it reproduce." Root cause is the issue-fix skill's job.
2. Editorial judgment in conclusion. If the reported behavior occurred, it's reproduced — even if by-design.
3. Stopping at build success. Many bugs manifest at RUNTIME. Build ≠ runtime.
4. Stale build artifacts. Fresh project dirs or rm -rf bin/ obj/ between versions.
5. Honesty over completion. not-reproduced and needs-platform are VALID SUCCESS conclusions. Reporting inability to reproduce is correct behavior, NOT failure. NEVER invent output you did not observe from an actual command execution.
6. NEVER modify product source. Do not edit files in binding/, externals/, samples/, source/, tests/, utils/, or any other product source during reproduction. Repro creates NEW test projects in /tmp/skiasharp/repro/{timestamp}/ only ({timestamp} is the current UTC time in yyyyMMdd-HHmmss format). If you find yourself editing SkiaSharp source, you have crossed into fix territory — stop.
7. NEVER use store_memory. Reproduction produces JSON artifacts, not memories. Storing unverified observations as permanent facts pollutes all future sessions.
8. NEVER skip validation. You MUST run validate-repro.ps1 (or .py fallback) and see ✅ before persisting. Mentally checking fields is not validation. If the script isn't run, the reproduction is invalid.

Intermittent bugs: If results are inconsistent, run 3–5 times. Reproduced ≥1 time → reproduced with note "Intermittent: X/Y runs". Never reproduced after 5 → not-reproduced.

Effort budget: Phases 1–2: ~5 min. Phase 3A: ~15–20 min. Phases 3B–3D: ~10–15 min. Total: ~30–50 min. If stuck after 3+ substantially different approaches, conclude with what you have.

Pre-flight — confirm before reproducing:

• Issue data loaded (cache JSON or GitHub API)
• Prior triage JSON loaded (if exists in ai-triage/)
• Read references/schema-cheatsheet.md for required fields and enums
• Read references/anti-patterns.md — at least the critical rules
• Environment checked: docker info (if needed), dotnet --version, xcodebuild -showsdks (if iOS)
• Created a brief plan (5-10 lines: reproduction strategy, which platform, what you expect)
• Never use sudo — if a command requires it, find an alternative approach

Phase 3 — Reproduce

Overview — you will test up to 4 configurations:

• 3A: Reporter's version on primary platform (always)
• 3B: Latest stable release (always)
• 3C: Main branch source (MANDATORY if 3B still reproduced)
• 3D: Cross-platform verification (conditional — see table below)

🛑 MINIMUM 2 VERSIONS REQUIRED. You must test at least the reporter's version (3A) AND latest stable (3B). Single-version reproductions are incomplete and will fail schema validation. This applies to ALL conclusion types — bugs (reproduced/not-reproduced) AND enhancements (confirmed/not-confirmed). For enhancements: a feature may exist in one version but not another, or may have been removed. Version testing reveals this.

3A. Reproduce with reporter's version

Follow the platform file from Phase 2.4. For each step, capture:

Step result = what actually happened (technical outcome), not whether it was expected. A build that fails is result: "failure" even if that confirms the bug. See references/anti-patterns.md for details.

Note: Use layer: "investigation" for source-code analysis steps in enhancement confirmations (grep, file reading). See Phase 2.1 for the full enhancement flow.

Push hard. Don't bail early. Only conclude not-reproduced after genuinely exhausting approaches.

3B. Test on latest release

⚠️ Clean build required: Create a fresh project directory per version (/tmp/skiasharp/repro/{timestamp}/{number}-latest/) or rm -rf bin/ obj/ before building. Never just sed the version — stale native binaries produce unreliable results. See references/anti-patterns.md #7.

Use the same platform strategy from 3A with the latest stable SkiaSharp. Record in versionResults.

3C. Test on main branch (if reproduced on latest)

🛑 Do NOT skip when reproduced on latest. If the bug reproduces on the latest stable release, testing main is MANDATORY — it tells us whether a fix exists but hasn't been released.

1. Bootstrap: [ -d "output/native" ] && ls output/native/ | head -5 || dotnet cake --target=externals-download
2. Build & run the platform-appropriate sample under samples/Basic/<platform>/. Each platform file has a "Main Source Testing (Phase 3C)" section — follow it.
3. Record result. If fixed on main but not released, note the version gap.

Clean up: Revert sample file changes with git checkout -- samples/.