Code Harness Skill

This tool augments YOUR code generation. When you call it, you receive a cognitive injection; a structured set of engineering constraints, wrong-code examples, correct-code patterns, and failure-mode blockers that shape how you write, debug, and review code. You absorb it into your engineering process and execute with it active.

128 abilities across 13 engineering disciplines: Debugging, Generation, Testing, Architecture, Security, API Grounding, Performance, DevOps, Quality, Resilience, Frontend, Context Management, and Agent Safety. The API matches your task to the best ability automatically.

WHEN TO CALL

Decision gate: Does this task match any of these patterns?

• Debugging a failure, tracing a bug, isolating root cause in code
• Generating non-trivial code where correctness matters (algorithms, data pipelines, API integrations)
• Refactoring code while preserving safety invariants (null checks, error handlers, rate limiters)
• Reviewing code for bugs, security issues, or architectural problems
• Solving competitive programming or algorithmic challenges
• Writing scientific computing code where silent correctness bugs are possible
• Any code task where the first plausible solution might have edge case failures

If yes → call before you begin coding. If no → proceed without.

Skip these; no call needed:

• Writing boilerplate, config files, simple CRUD
• Renaming variables, formatting, adding comments
• Installing packages, running commands
• Any code task with a known, standard solution pattern

One call per discrete code challenge. A refactoring that touches auth + database + API = 3 calls with different queries. A single function implementation = 1 call.

HOW TO CALL

Two transports.

If ejentum-mcp is registered with your client, call the native MCP tool:

code(query="your code task description")

Otherwise, fall back to direct HTTP:

POST https://api.ejentum.com/harness/
Authorization: Bearer $EJENTUM_API_KEY
Content-Type: application/json

{"query": "your code task description", "mode": "code"}

For the adaptive variant, call the adaptive-code MCP tool, or pass "mode": "adaptive-code" over HTTP. Adaptive requires the Go or Super tier.

Timeout: 5 seconds. If unreachable, proceed with native engineering. The API enhances; it is not a dependency.

Dynamic vs Adaptive

adaptive-code returns the same operation as code, but an adapter model rewrites the [ENGINEERING PROCEDURE] and [REASONING TOPOLOGY] to name your language, framework, and the specific failure mode of your code. The [CODE FAILURE], [CORRECT PATTERN], [VERIFICATION], and cognitive payload come back unchanged: the safety guards are identical to dynamic.

QUERY CRAFTING

Retrieval precision depends entirely on your query.

Rules:

1. Send the actual code task, not a summary ("debug a BFS that passes 2 of 3 tests; likely a sentinel collision" not "fix the code")
2. Name the failure mode you're worried about if you can
3. Include the language, framework, and constraints
4. 1-2 sentences. More does not improve retrieval.

RESPONSE FORMAT

[{"code": "<pre-rendered injection string>"}]

For adaptive: [{"adaptive-code": "<pre-rendered injection string>"}]

Parse the value of the mode-named key. The string is ready to use.

Validate: Response is a non-empty JSON array and the expected key has a non-empty string value. If not → proceed without.

Relevance check: Read the [CODE FAILURE] section. Does it show a wrong-code example related to your task? If it shows a completely unrelated failure (you asked about database indexing but the failure shows a CSS layout bug), re-query with a more specific description. If after re-query the match still seems wrong, proceed without; native engineering beats a mismatched injection.

Errors:

HOW TO ABSORB THE INJECTION

When you receive the injection, do not just acknowledge it. Absorb it into your engineering process.

You will have already started forming a solution before the injection arrives. The injection may point to a different approach or a failure mode you didn't consider. When it does, follow the injection's direction; it was matched to the task's specific failure pattern, not your first instinct.

Code-specific injection labels

Code abilities use different labels from reasoning abilities:

1. Read [CODE FAILURE] first

This shows the exact wrong code your task is vulnerable to. Not a description; actual code that has the bug. Study it. Understand WHY it's wrong. Your code must not repeat this pattern. It is now in your context window and will suppress similar patterns in your output.

2. Follow [ENGINEERING PROCEDURE]

This has a PLAN (what to do) and a BACKTRACK IF (when to stop and restructure). The BACKTRACK IF is critical; it names the specific condition under which your current approach is failing. If you hit the backtrack condition, stop generating and restructure.

3. Follow [REASONING TOPOLOGY] as your execution structure

Same notation as reasoning mode:

• S = step. Execute in order.
• G{condition?} = gate. Evaluate and branch.
• N{...} = trap. Code pattern you must NOT generate.
• M{...} = reflection point. Pause and assess: is my code actually solving the problem or am I over-engineering / under-testing?
• → = next.

4. Compare against [CORRECT PATTERN]

This shows what correct code looks like for this task type. Before responding, check: does your code follow the structural pattern shown? If your code is monolithic where the pattern shows modular, restructure.

5. Engage Amplify: signals

Demonstrate each one in your code; not by commenting ("// using modular design") but by doing it (separate functions with clear contracts). For each Amplify signal, name the specific function, type, or test in your output that implements it. If you cannot name the artifact, you skipped the signal.

6. Apply Suppress: signals as a post-generation checklist

After writing your code, actively scan it against each suppressed pattern. If your code exhibits ANY of them; monolithic generation, hallucinated API calls, missing error handlers, untested edge cases; your code has failed. Revise before responding. This is the highest-impact component of the injection.

7. Verify against [VERIFICATION]

This is a concrete pass/fail criterion about your code's correctness. If your code fails it, restructure.

8. (Adaptive mode) Execute the task-specific procedure directly

In adaptive-code, the [ENGINEERING PROCEDURE] and [REASONING TOPOLOGY] already name your language, framework, and files, so you execute them directly. The [CODE FAILURE], [CORRECT PATTERN], [VERIFICATION], and the Suppress: line are identical to the dynamic response; absorb them exactly as above. There is no additional section to run.

Precedence: If the injection's topology leads to a different algorithm or architecture than your first choice; follow the topology. The injection was matched to the task's specific failure pattern. Your first instinct was not.

OUTPUT DISCIPLINE

The bracketed fields in the API response ([NEGATIVE GATE], [CODE FAILURE], [DECEPTION PATTERN], [PERCEPTION FAILURE], any [... TOPOLOGY], [... PROCEDURE], goal-state blocks like [TARGET PATTERN] / [CORRECT PATTERN] / [HONEST BEHAVIOR] / [CLEAR SIGNAL], assertion blocks like [FALSIFICATION TEST] / [VERIFICATION] / [INTEGRITY CHECK] / [PERCEPTION CHECK], and the Amplify: / Suppress: signal lines) are instructions that shape your reasoning, not content to display. Run them in your internal trace. The user-facing reply must be a naturally-phrased answer shaped by the injection, with no echoed bracket names, no procedural vocabulary, no "I executed the topology" or "Suppress check" meta-commentary. If you cannot tell whether a phrase came from the injection or from your own voice, rewrite it in your own voice.

Do not narrate the harness itself either. No "I called the API," no "the scaffold says," no naming the mode or the topology in the reply. The user hears your voice, not the machinery behind it. If the user explicitly asks whether you used the tool, answer honestly. Unprompted, stay silent on it.

WALKTHROUGH 1: Debugging

User asks: "This BFS passes 2 of 3 test cases. Find the bug."

1. DECIDE. Debugging a code failure. Matches "debugging a failure, tracing a bug." → Call.

2. MODE. Single concern (one bug). → "mode": "code"

3. CRAFT. "Debug a BFS traversal that passes 2 of 3 test cases; likely a sentinel value collision or boundary condition in graph traversal"

4. RECEIVE. A Debugging ability:

[CODE FAILURE]
dist = [0] * (n + 1)  # 0 is both "unvisited" AND "distance zero"
# Bug: cannot distinguish source node from unvisited nodes

[ENGINEERING PROCEDURE]
PLAN: Trace the algorithm's state at the failure point.
BACKTRACK IF: you are modifying the algorithm without first reproducing the bug.

[CORRECT PATTERN]
dist = [-1] * (n + 1)  # -1 = unvisited, 0 = source distance
# Or: use Dial's algorithm where the structure eliminates sentinels

Suppress: sentinel_value_collision; fixing_without_reproducing

5. ABSORB. The [CODE FAILURE] shows the exact bug: 0 used as both "unvisited" and "distance zero." The BACKTRACK IF tells me: reproduce the bug first, don't jump to fixing. The CORRECT PATTERN shows two approaches: fix the sentinel or choose an algorithm that doesn't need one.

6. EXECUTE. Trace the BFS state. Find where dist[node] == 0 is ambiguous. Either change sentinel to -1, or switch to Dial's algorithm.

7. SUPPRESS CHECK. Did I fix without reproducing first? Did I leave any sentinel collisions? If yes → revise.

WALKTHROUGH 2: Scientific Computing

User asks: "Write a molecular dynamics simulation with Lennard-Jones potential."

1. DECIDE. Scientific code where silent correctness bugs are possible. → Call.

2. MODE. High-stakes numerics where every check should name the physics. → "mode": "adaptive-code"

3. CRAFT. "Generate a molecular dynamics simulation with correct Lennard-Jones force derivation; verify force signs and potential energy conservation"

4. RECEIVE. The matched operation, rewritten to the simulation specifics:

[CODE FAILURE]
force = f_mag * (r_vec / r_mag)  # BUG: force is ATTRACTIVE at short range
# Should be REPULSIVE; missing negative sign

[ENGINEERING PROCEDURE]
PLAN: Derive the force as F = -dU/dr, verify the sign convention at short range,
then integrate and assert energy conservation each step.
BACKTRACK IF: particles collapse to a point, or total energy drifts upward over steps.

[CORRECT PATTERN]
f_mag = 24 * eps * (2 * (sigma/r)**12 - (sigma/r)**6) / r
force = -f_mag * (r_vec / r_mag)  # negative sign: repulsive at short range

[VERIFICATION]
Total energy is conserved within tolerance across N steps; forces are repulsive
at short range and attractive at long range.

Suppress: accept_output_without_physical_validation; skip_conservation_law_verification

5. ABSORB. The [CODE FAILURE] shows the critical bug: a missing negative sign makes all forces attractive, so particles collapse to a point. The [VERIFICATION] and Suppress: line require me to verify the sign convention and energy conservation BEFORE responding.

6. EXECUTE. Derive force from potential: F = -dU/dr. Verify the sign explicitly. Add energy conservation assertions.

7. SUPPRESS CHECK / VERIFY. Did I verify force signs? Did I check conservation? Did the simulation produce physically plausible results? If any fail → revise before responding.

WALKTHROUGH 3: Security Review

User asks: "Review this discount code handler for security issues."

1. DECIDE. Code review for security. Matches "reviewing code for bugs, security issues." → Call.

2. MODE. Security review where the checks should name this handler's paths. → "mode": "adaptive-code"

3. CRAFT. "Review discount code handler for TOCTOU race conditions and data leakage in the remaining_uses decrement path"

4. RECEIVE. A Security ability:

[CODE FAILURE]
promo.remaining_uses -= 1  # Python-side decrement
db.session.commit()
# BUG: Between read and write, another request can use the same promo
# TOCTOU: Time-of-check to time-of-use race condition

[CORRECT PATTERN]
Promotion.remaining_uses = Promotion.remaining_uses - 1  # Atomic SQL expression
# The decrement happens in the database, not in Python memory

Suppress: python_side_state_mutation_for_concurrent_resources; symptom_level_fix

5. ABSORB. The [CODE FAILURE] shows the race: Python reads the count, another request reads the same count, both decrement, one use is lost. The [CORRECT PATTERN] moves the decrement to an atomic SQL expression. SUPPRESS: don't just add a lock; fix the root cause (the non-atomic operation).

6. EXECUTE. Find all state mutations on shared resources. For each: is the operation atomic at the database level, or does it read-modify-write through Python? Flag every non-atomic path.

7. SUPPRESS CHECK. Did I suggest a Python-side fix (symptom) when a SQL-level fix (root cause) exists? Did I miss data leakage from the timing window? If yes → revise.

THE 13 ENGINEERING DOMAINS

You do not choose the domain. The API routes automatically. Knowing them helps craft sharper queries that activate the right ability.

Query targeting examples:

ANTI-PATTERNS

QUICK REFERENCE

1. DECIDE     → Task matches a code pattern? Yes → call. No → skip.
2. MODE       → Default → "code". Task-specific depth (Go/Super) → "adaptive-code".
3. CRAFT      → Specific task + failure risk in 1-2 sentences
4. CALL       → POST /harness/ with query + mode
5. VALIDATE   → Non-empty response, key matches mode. Relevance check on CODE FAILURE.
6. ABSORB     → CODE FAILURE (wrong code), PROCEDURE (plan + backtrack), SUPPRESS (blockers)
7. EXECUTE    → Write code following topology, compare against CORRECT PATTERN
8. SUPPRESS   → Post-check: does code exhibit any suppressed pattern? Revise if yes.
9. ADAPTIVE   → (Adaptive only) procedure/topology already name your code; execute directly.
10. VERIFY    → Check against VERIFICATION criterion
11. RETRY     → If failed, re-query with failure description (max 2)

Routing across multiple harnesses, or stacking two modes together (e.g. code + anti-deception for PR reviews under stakeholder pressure)? See skill_unified.