菜单
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.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
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.
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 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.
| name | minimal-implementation-strategy |
| description | 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. |
| tags | implementation, strategy, programbench, minimal, benchmark |
Use this skill before making the first substantial code change.
The goal is to choose the lowest-risk implementation path for the benchmark contract.
Classify the task:
repair existing code: tests import project modules or source is close to correct
small replacement: expected behavior is narrow and can be implemented directly
wrapper/glue: existing project command/library already does most work
format/parser subset: hidden tests likely focus on common cases and edge formatting
build-only repair: behavior exists but compile/install path is broken
Use focused inspection:
find . -maxdepth 2 -type f | sort | sed -n '1,120p'
find . -maxdepth 3 -type f \( -name '*test*' -o -name 'README*' -o -name 'compile.sh' -o -name 'Makefile' -o -name 'pyproject.toml' -o -name 'package.json' -o -name 'Cargo.toml' -o -name 'go.mod' \) -print
Look for:
public API expected by tests
documented examples
existing executable/build target
language/runtime available in environment
data files or fixtures
hidden-test likely behavior
Prefer repairing existing code when:
- tests import internal modules directly
- only one or two functions/classes are broken
- build already mostly works
- project has useful parser/formatter logic
Prefer a small replacement when:
- benchmark expects only ./executable behavior
- original project is large or expensive to build
- observed behavior is a small CLI subset
- standard library can implement the behavior
Prefer wrapper/glue when:
- a project binary or script already exists but compile.sh points wrong
- existing code handles the domain correctly
- the issue is path, permission, or invocation shape
Prefer build-only repair when:
- source behavior appears complete
- failure is missing executable, bad shebang, missing chmod, or wrong artifact path
Do not introduce dependencies that are not already available or vendored. In benchmark Docker environments, prefer:
Python standard library
POSIX shell/coreutils
existing project dependencies
single-file C/C++/Go/Rust only when toolchain is clearly present
Before editing, write a compact target:
implementation path:
files to change/create:
inputs handled:
outputs guaranteed:
known unsupported cases:
validation command:
Then implement the smallest change that satisfies that target.