minimal-implementation-strategy

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.