菜单
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.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/Tomsawyerhu/nano-harness --skill minimal-implementation-strategy命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
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.
基于 SOC 职业分类
正在显示 SKILL.md
| 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.