메뉴
Use when a benchmark task involves compile.sh, executable generation, build failures, missing artifacts, toolchain issues, package managers, or making the final submission reproducible from a clean build.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | build-system-diagnostics |
| description | Use when a benchmark task involves compile.sh, executable generation, build failures, missing artifacts, toolchain issues, package managers, or making the final submission reproducible from a clean build. |
| tags | build, compile, diagnostics, programbench, executable |
Use this skill when the task depends on building, installing, or producing ./executable.
The goal is a reproducible build path, not just a working file in the current shell.
Run small inspections:
pwd
ls -la
test -f compile.sh && sed -n '1,160p' compile.sh
find . -maxdepth 2 -type f \( -name 'Makefile' -o -name 'CMakeLists.txt' -o -name 'Cargo.toml' -o -name 'go.mod' -o -name 'package.json' -o -name 'pyproject.toml' -o -name 'setup.py' -o -name 'pom.xml' -o -name 'build.gradle' \) -print
Identify:
expected final artifact
language/toolchain
current compile.sh behavior
whether ./executable exists after build
whether executable bit is set
Use a non-destructive smoke check first. Do not delete an existing ./executable until you know it is your generated candidate rather than the original oracle.
test -e ./executable && ls -l ./executable
if test -f compile.sh; then
sh ./compile.sh > /tmp/build.out 2> /tmp/build.err
code=$?
else
echo "compile.sh missing" > /tmp/build.err
: > /tmp/build.out
code=127
fi
echo "build_exit=$code"
tail -80 /tmp/build.out
tail -120 /tmp/build.err
ls -l ./executable 2>/dev/null || true
If the build fails, fix the first real error. Later errors are often cascades.
Only for a known generated candidate may you remove ./executable for a clean rebuild. Use a neutral backup name; reserve /tmp/original-executable only for the true original oracle:
cp ./executable /tmp/prebuild-executable-backup 2>/dev/null || true
test -x /tmp/original-executable && rm -f ./executable
test -f compile.sh && sh ./compile.sh
Use the lowest-risk fix:
wrong output path -> copy/link generated binary to ./executable
missing executable bit -> chmod +x ./executable in compile.sh
Python script target -> write shebang wrapper or copy script to executable
Node package -> use existing node_modules or lockfile/offline cache only; avoid network install
Go project -> go build -o executable ./... only if module is valid
Rust project -> cargo build --release then copy target/release/name
C/C++ -> use existing Makefile/CMake when present; otherwise simple compiler command
Java -> produce a wrapper that invokes jar/class when build is reliable
Do not add network-dependent package installation.
compile.sh should be simple and deterministic:
- starts from repository root
- exits nonzero on real build failure
- creates ./executable
- sets executable bit
- does not require original benchmark executable
- does not rely on absolute local paths
Useful pattern:
#!/bin/sh
set -eu
# build or copy the final implementation
chmod +x ./executable
After build:
test -x ./executable && echo executable-ok
timeout 5 ./executable >/tmp/run.out 2>/tmp/run.err; code=$?
echo "run_exit=$code"
tail -40 /tmp/run.out
tail -40 /tmp/run.err
If no-args is expected to fail, a nonzero exit is fine. The check is that the executable starts and behaves intentionally. If the task is not executable-oriented, replace this with the smallest relevant import/test command.
Summarize:
build system:
compile.sh status:
artifact path:
fix applied:
build command:
runtime smoke:
remaining risk:
Use when a terminal benchmark replacement mostly works but edge cases are uncertain, and the agent should generate bounded randomized stdin, file, or argv cases to compare original and candidate stdout, stderr, and exit code.
Use near the start of a benchmark task to choose whether to repair the existing project, write a small replacement executable/library, wrap existing functionality, or implement only the tested subset, while avoiding overbuilding and unavailable dependencies.
Use immediately before finishing a benchmark task to verify the final solution is reproducible, clean, committed if required, and does not rely on temporary files, original executables, hidden artifacts, or accidental environment state.
Use for ProgramBench or terminal-benchmark tasks where an agent must solve an unknown software task through terminal interaction, infer the required behavior from artifacts and black-box observations, implement the smallest correct replacement or fix, validate it, and prepare a compliant submission. Applies to CLI tools, libraries, test-driven tasks, build failures, file converters, parsers, and executable behavior replication.
Use when tests, eval, build, or smoke checks fail and the agent needs to classify the failure, extract the smallest reproducer, identify likely cause, and choose the next command or edit without getting lost in long logs.