Reference code engineer

reference-code-engineer

This skill extends the higher-ed-teaching-agents ecosystem.

Expected outputs

• structured artifacts
• explicit assumptions
• reproducible deliverables
• teacher-facing justification when evaluation is involved

Rules

• keep outputs auditable
• prefer concrete artifacts over generic advice
• align with shared policies in shared/

C++ profile (when mission targets C++)

• Target C++20 unless mission constraints explicitly require C++17.
• Provide reference/CMakeLists.txt with explicit standard and warnings:
  • CMAKE_CXX_STANDARD 20
  • -Wall -Wextra -Wpedantic (or compiler-equivalent flags)
• Prefer RAII and standard library facilities over manual resource management.
• Avoid undefined behavior patterns (dangling references, unchecked narrowing, raw ownership without clear lifetime policy).
• Keep the build reproducible with no network dependency.

Java profile (when mission targets Java)

• Target Java 17 unless mission constraints state a different LTS version.
• Use conventional layout (reference/src/) and deterministic entrypoint naming (e.g., Main).
• Ensure reference code compiles with javac without relying on network downloads.
• Prefer clear object modeling, explicit error handling, and immutable data where practical.
• Avoid hidden global state and non-deterministic side effects in reference solutions.

Rust profile (when mission targets Rust)

• Target Rust edition 2021 by default unless mission constraints require a newer edition.
• Use a standard Cargo project layout with reference/Cargo.toml and reference/src/main.rs.
• Prefer ownership/borrowing patterns that avoid unnecessary cloning and unsafe code.
• Avoid unsafe unless explicitly required and justified in teacher notes.
• Ensure the reference project builds and tests locally with Cargo without network dependencies.

Python profile (when mission targets Python)

• Target Python 3.10+ unless mission constraints require an older release.
• Use a flat layout (reference/main.py or reference/src/) with no unnecessary package nesting.
• Provide a reference/requirements.txt if third-party libraries are used; prefer stdlib-only solutions.
• Follow PEP 8 style; use type annotations for public functions and module-level constants.
• Avoid global mutable state; prefer pure functions and explicit argument passing in reference solutions.
• Include a reference/tests/ directory with at least one pytest-compatible test file validating the reference logic.
• Ensure the reference runs headlessly (python3 main.py) with no interactive prompts unless the mission explicitly requires terminal I/O.

C / POSIX profile (when mission targets C or POSIX system calls)

• Target C11 (-std=c11) with -Wall -Wextra -Wpedantic unless the mission constrains the standard.
• Provide reference/Makefile with an explicit CC, CFLAGS, and a clean target; avoid implicit rules that hide build commands.
• When POSIX APIs are used (fork, pipe, exec, pthread, signal, mmap, select/poll), document each syscall's expected return-value check inline.
• Always check return values of syscalls; never suppress errors with (void).
• Close all file descriptors and free all heap allocations in the reference path (valgrind-clean is the baseline).
• Provide reference/supervisor.c or reference/run_tests.sh when automated test execution is required by the mission.
• Avoid undefined behavior: no uninitialized reads, no buffer overflows, no signed integer overflow.