| 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 |
Minimal Implementation Strategy
Use this skill before making the first substantial code change.
The goal is to choose the lowest-risk implementation path for the benchmark contract.
Strategy Decision
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
Evidence to Gather
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
Choose the Path
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
Dependency Rule
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
Implementation Contract
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.
