agentleFS
GoogleKnown publishergoogle/skia/_agents/skills/skia-gn-workflow/SKILL.md

skia-gn-workflow

Skill11k starsChanged 4 days agoBSD-3-ClauseView on GitHub

MANDATORY: Use this skill for ANY and ALL tasks involving building Skia with GN, Ninja, or compiling any Skia tool. It is the authoritative source for Skia's build workflows and MUST be used whenever compilation is required.

We split this skill into the rules it gives an agent

11 rules. About 0 are common, 2 are distinctive, and 9 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈2

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 9

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Hermeticity: Always use ./bin/gn for configuration and ./bin/fetch-ninja to ensure the correct version of Ninja is available.

    line 14
  2. Distinctive:

    Verification: Always build and run tests/benchmarks before documenting or finalizing changes.

    line 15
  3. Very specific:

    Filtering: Use the --match flag (aliased as -m) to target specific tests and reduce execution time.

    line 16
  4. Very specific:

    Toolchain Paths: When a build requires specific toolchain paths (e.g.

    line 18
  5. Very specific:

    If you encounter compilation errors in third_party or missing headers, run:

    line 23
  6. Very specific:

    If the ninja command is not found or you want to ensure a hermetic version:

    line 29
  7. Distinctive:

    If the build system gets into a broken state, clean the directory:

    line 41
  8. Very specific:

    If a build requires Rust dependencies (in third_party), use bazelisk to manage the toolchain:

    line 53
  9. Very specific:

    Windows: Use clang_win="<path_to_llvm>" to build with clang-cl (highly recommended).

    line 75
  10. Very specific:

    Unit Tests: Use DEF_TEST(Name, reporter) in tests/.

    line 126
  11. Very specific:

    GMs: Use DEF_GM(return new MyGM;) in gm/.

    line 127

≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

skia-gn-workflow

This skill provides expert guidance for building and testing Skia using the GN build system and Ninja. It covers common workflows for correctness testing (dm), performance benchmarking (nanobench), and interactive visualization (viewer).

Core Principles

  • Hermeticity: Always use ./bin/gn for configuration and ./bin/fetch-ninja to ensure the correct version of Ninja is available.
  • Verification: Always build and run tests/benchmarks before documenting or finalizing changes.
  • Filtering: Use the --match flag (aliased as -m) to target specific tests and reduce execution time.
  • Build Directories: NEVER override a user's existing build directory settings (e.g. out/Debug). If you need a different configuration, create a new directory (e.g. out/Debug2, out/ASAN). Only modify settings in an existing directory if explicitly asked by the user.
  • Toolchain Paths: When a build requires specific toolchain paths (e.g. cc, cxx, or clang_win for Clang/LLVM), ALWAYS ask the user where these are extracted on their machine. Different developers have these in different locations.

Setup & Troubleshooting

1. Syncing Dependencies

If you encounter compilation errors in third_party or missing headers, run:

python3 tools/git-sync-deps

2. Fetching Ninja

If the ninja command is not found or you want to ensure a hermetic version:

./bin/fetch-ninja

3. Formatting Code

Near the end of your workflow, before uploading a CL or finalizing changes, format your code using:

git clang-format origin/main

4. Cleaning Builds

If the build system gets into a broken state, clean the directory:

./bin/gn -q clean out/Dir

5. Inspecting the Build

To understand how a target is being built or to find available targets:

  • List all targets: ./bin/gn ls out/Dir or ninja -C out/Dir -t targets
  • Inspect a target: ./bin/gn desc out/Dir //:dm (shows flags, defines, sources, etc.)
  • Check why a file is included: ./bin/gn path out/Dir //:dm //src/core/SkPath.cpp

6. Rust Dependencies (Bazel)

If a build requires Rust dependencies (in third_party), use bazelisk to manage the toolchain:

Build Workflows

1. Common Build Arguments

  • is_debug=false: Create an optimized Release build.
  • is_official_build=true: Optimized build, links against system libraries. Suitable for shipping.
  • is_component_build=true: Build Skia as a shared library.
  • sanitize="ASAN"|"MSAN"|"TSAN"|"UBSAN": Enable memory, address, thread, or undefined behavior sanitizers.
  • extra_cflags=["..."], extra_ldflags=["..."]: Add custom compiler/linker flags.
  • cc="clang" cxx="clang++": Specify the compiler (highly recommended for performance).

2. Sanitizer Builds (xsan)

  • ASAN: ./bin/gn gen -q out/ASAN --args='sanitize="ASAN" cc="<path_to_clang>" cxx="<path_to_clang++>"'
  • MSAN: ./bin/gn gen -q out/MSAN --args='sanitize="MSAN" cc="<path_to_clang>" cxx="<path_to_clang++>" skia_use_fontconfig=false'
    • Note: Run dm with --nogpu under MSAN to avoid driver noise.
  • TSAN: ./bin/gn gen -q out/TSAN --args='sanitize="TSAN" is_debug=false cc="<path_to_clang>" cxx="<path_to_clang++>"'

3. Platform Specifics

  • Android: ./bin/gn gen -q out/android --args='ndk="~/ndk" target_cpu="arm64"'
  • iOS: ./bin/gn gen -q out/ios --args='target_os="ios" target_cpu="arm64"'
  • Windows: Use clang_win="<path_to_llvm>" to build with clang-cl (highly recommended).

4. Other Build Notes

  • Unless otherwise instructed, build with: ninja --quiet -C {OUT_DIR} {TARGET}. If given an ninja command that is missing --quiet, you must add --quiet.

Tool Reference

dm (Correctness Testing)

dm runs GMs (graphics tests), unit tests, and compares images.

  • Common Flags:
    • --src <types>: e.g., --src tests gm skp image.
    • --config <configs>: e.g., --config 8888 gl.
    • --match / -m: Case-sensitive substring filter. Supports ~ (exclude), ^ (start), $ (end).
    • --skip <config> <src> <srcOptions> <name>: Skip specific test cases. Use _ for wildcards.
    • --writePath / -w: Write result bitmaps as PNGs.
    • --readPath / -r: Read reference bitmaps for comparison.
    • --threads / -j: Number of threads (default: one per core).
    • --verbose / -v: Detailed output.
  • Extended Help: For detailed documentation on specific flags, use --help <flag_name>.
    • Example: out/Debug/dm --help config.

nanobench (Performance Benchmarking)

Always use a Release build for benchmarking.

  • Common Flags:
    • --samples <N>: Number of samples per benchmark (default 10).
    • --ms <time>: Run each benchmark for at least <time> milliseconds.
    • --cpuprofile <file>: Write pprof CPU profile (requires skia_use_pprof=true).
    • --match / -m: Filter benchmarks.
  • Baseline Preservation: It is recommended to copy a stable baseline binary to nanobench_control (outside the out/ directory) to compare against a new build.

viewer (Interactive Visualization)

  • Common Flags:
    • --backend / -b: sw, gl, vulkan, metal, d3d.
    • --slide <name>: Jump to a specific GM or SKP.
    • --match / -m: Filter slides.
  • Hotkeys: i (HUD), z (zoom), [/] (navigation).

Advanced: "Via" Configs

dm supports "via" configs in the format [via-]*backend. These wrap a rendering sink to test additional logic.

  • Examples:
    • serialize-8888: Serialize and then deserialize the canvas before drawing.
    • srgb-8888: Run the 8888 sink in the sRGB color space.
  • Common Vias:
    • serialize: Serializes/Deserializes drawing.
    • pic: Records to SkPicture and plays back.
    • rtblend: Uses a runtime blend mode.
    • matrix: Applies a 2x2 matrix (requires --matrix "s0 s1 s2 s3").
    • upright: Applies a matrix and then uprights it.
  • Color Space Vias: srgb, linear, p3, rec2020, narrow.

Writing Tests

  • Unit Tests: Use DEF_TEST(Name, reporter) in tests/.
  • GMs: Use DEF_GM(return new MyGM;) in gm/.

6. Debugging Fuzz Cases & Writing Reproduction Tests

To build and run a fuzzer (like Clusterfuzz or oss-fuzz) to reproduce a crash:

ninja --quiet -C out/Debug fuzz
out/Debug/fuzz --bytes <path_to_testcase>

For the full workflow (including writing reproduction unit tests), see Fuzz Debugging.

Available Resources

  • Build Arguments
  • dm Usage
  • nanobench Usage
  • viewer Usage
  • Testing
  • GMs
  • Fuzz Debugging
  • Other Tools

Download now (ZIP)

Trending

Quiet since July.about the whole repository

Dec 2025: 2 mentionsJan 2026: 0 mentionsFeb 2026: 0 mentionsMar 2026: 0 mentionsApr 2026: 1 mentionMay 2026: 0 mentionsJun 2026: 1 mentionJul 2026: 4 mentionsAug 2026: 0 mentionsSep 2026: 0 mentionsOct 2026: 0 mentionsNov 2026: 0 mentions
Dec 2025Jun 2026Nov 2026
Mentions a month of the google/skia repository that our weekly crawl found. There is no adoption data for this file yet.

Who's talking about google/skia

The biggest 5 of 37 mentions linking to the repository that our crawl found. Each line is their own headline.

See all 37

Talked about on GitHub, Stack Overflow and Hacker News (37 times).

On GitHub · 30

25 more on GitHub

On Hacker News · 1

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.