メニュー
Build the Spice compiler (`spice`) and/or the test runner (`spicetest`) with CMake/Ninja. Use when the user wants to compile/rebuild the project, build a specific target, produce a release/debug build, or set up the CMake build directory before running or testing.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Guidelines for contributing changes to the Spice GitHub repository — branch naming conventions, commit message format, PR workflow, no-push-to-main rule, and quality gates. Use when preparing a branch for review, writing a commit, opening a PR, or checking that a contribution is ready to merge.
Profile and benchmark the Spice compiler (the host C++ `spice` program) and the native binaries it emits from `.spice` files — using the built-in per-stage timers, the dedicated CMake profiling build options, and external tools (perf, valgrind/callgrind, flamegraph, hyperfine). Covers the preferred build/compile settings for representative profiling of each layer. Use when the user wants to find where compile time or runtime is spent, benchmark a change, or chase a performance regression.
Find, diagnose, and fix bugs in the Spice compiler or in a compiled Spice program using GDB, objdump, sanitizers (for both the host C++ compiler and the emitted Spice program via the built-in `--sanitizer` flag), the compiler dump flags, and valgrind. Use when investigating a crash, miscompilation, memory error, or undefined behavior, or when triaging a failing test. Whenever a bug is fixed, this skill also requires extending or adding a test that covers the problematic code path and any related uncovered paths.
Add a reference/integration test case under test/test-files for the Spice compiler. Covers the directory layout (flat vs grouped suites), the exact reference filenames the runner compares against, control/skip marker files, platform-specific variants, and the --update-refs workflow to generate expected output. Use when adding or modifying compiler test cases.
Orientation map of the Spice compiler codebase — the compilation pipeline (lexer → parser → CST → AST → import collector → symbol table → type checker → IR generator → optimizer → object emitter → linker), the key class/file for each stage, and the SourceFile orchestration sequence. Use when navigating the compiler, deciding where a change belongs, or understanding how a stage feeds the next.
Locate or add a Spice compiler diagnostic — errors (semantic, parser, lexer, compiler-internal, linker, CLI) and warnings. Covers the exception classes in src/exception, the message tables, how to throw a diagnostic from a pass, the warning mechanism, and the matching test convention (exception.out / warning.out). Use when adding a new error/warning or tracking down where a message comes from.
| name | spice-build |
| description | Build the Spice compiler (`spice`) and/or the test runner (`spicetest`) with CMake/Ninja. Use when the user wants to compile/rebuild the project, build a specific target, produce a release/debug build, or set up the CMake build directory before running or testing. |
The Spice repo is a CMake project (top-level CMakeLists.txt) that produces two
main artifacts:
spice — the compiler CLI (src/, output at <build-dir>/src/spice)spicetest — the GoogleTest runner (test/, output at <build-dir>/test/spicetest)Reuse one of these directories so artifacts stay organized (per AGENTS.md):
cmake-build-debug/ — day-to-day development and testingcmake-build-release/ — optimized builds for benchmarkingThe python build.py helper instead builds into build/ with Release + Ninja and
moves the binaries to the repo root; prefer the directories above for agent work
unless the user explicitly wants build.py.
A configured LLVM build must be reachable. find_package(LLVM) locates it via
LLVM_DIR (the local dev setup builds LLVM into ./llvm/build-release):
export LLVM_DIR=$PWD/llvm/build-release/lib/cmake/llvm
If LLVM and third-party libs are missing, run python dev-setup.py once (slow: it
clones and builds LLVM). python setup-deps.py alone fetches just the header-only
deps (json, CLI11) into lib/.
cmake -S . -B cmake-build-debug -G Ninja -DCMAKE_BUILD_TYPE=Debug
# release:
cmake -S . -B cmake-build-release -G Ninja -DCMAKE_BUILD_TYPE=Release
Run from inside the build dir, or pass --build <dir>:
# Everything (compiler + tests)
cmake --build cmake-build-debug
# Just the compiler
cmake --build cmake-build-debug --target spice
# Just the test runner
cmake --build cmake-build-debug --target spicetest
# Both, parallel
cmake --build cmake-build-debug --target spice spicetest -j
# Optional leak-check target (needs valgrind)
cmake --build cmake-build-debug --target spicetest_leakcheck
cmake --build <dir> --target <t>; Ninja
only recompiles what changed. No need to reconfigure unless CMake files change.cmake-build-debug/src/spice — see the
spice-dump skill for inspecting its IR/assembly output and spice-test for
running the suite.Options.cmake / Conditionals.cmake /
LLVMOptions.cmake if the user needs non-default flags.