메뉴
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.