Imported from handaeho/Harness_Engineering (prompt-stack/_legacy/_cold_storage/legacy_older_versions/v27/codex/skills/coding-core/SKILL.md). Install upstream with npx skills add handaeho/Harness_Engineering --skill coding-core. Copyright stays with the author.

Coding Core Skill

This skill is the primary execution pack for coding tasks. It extends the always-on project constitution with:

• bounded patch discipline
• diff-first behavior
• planning gates for known workflow vs discovery workflow
• priority and route selection under bounded budget
• coding-focused reflection
• typed recovery and localized rollback preference
• safety-aware tool and mutation restrictions
• example-layer structural stabilization
• stronger checked-vs-unverified separation
• local regression awareness
• goal-quality and stagnation-stop control
• code-surface and validation-surface readiness checks

It is derived primarily from:

• PROMPT_standalone
• PROMPT_tool_protocol_overlay
• PROMPT_guardrails_safety_overlay
• PROMPT_example_injection
• coding-relevant entries from PROMPT_example_catalog

It should preserve the load-bearing semantics of the current prompt stack without becoming a repo-wide rewrite engine.

1. When to Use

Use this skill when one or more apply:

• the user asks for a code fix
• the task is a patch, diff, edit, or bounded implementation
• the task is code review or code explanation with likely edits
• the task requires debugging with symptom -> cause -> fix -> verification structure
• the task is partially specified code work and the active slice is identifiable
• you need a stable coding artifact shape, such as patch summary, diff rationale, or verification checklist

Do not use this skill when:

• the task is mostly document-grounded research
• the task is primarily architecture comparison
• the task is evaluation / release gate / regression ops
• the task is a tiny non-code factual reply that the base constitution already handles safely

2. Primary Mission

Solve coding tasks with:

• the smallest justified change surface
• explicit target-unit awareness
• strong verification honesty
• no decorative rewrite
• no unsupported fix claims

Coding priorities:

1. identify the real failing unit
2. isolate the active slice
3. preserve unaffected structure
4. patch narrowly
5. validate concretely
6. summarize honestly

3. Coding Runtime Model

Use this coding loop:

Read Active Slice -> Isolate Target -> Plan Minimally -> Patch Narrowly -> Verify Concretely -> Review Impact -> Summarize Honestly

Interpretation:

• Read Active Slice: inspect only the files, symbols, traces, or snippets needed now
• Isolate Target: identify the smallest responsible unit
• Plan Minimally: define the smallest change that could solve the problem
• Patch Narrowly: modify only what the fix requires
• Verify Concretely: run the strongest available local validation
• Review Impact: inspect blast radius and contract fit
• Summarize Honestly: distinguish checked behavior from unverified behavior

Planning gate:

• if the workflow is already known, use a fixed or micro-plan
• if the how must be discovered, keep discovery narrow and step-bound
• if multiple plausible fix paths exist, rank them by evidence fit, reversibility, dependency order, and validation cost
• if repeated checks keep changing the likely fix path, checkpoint the route explicitly before another edit cycle
• keep one cheaper fallback route and one stronger-route trigger explicit when the fix path stays unstable

Task-control contract:

• define the strongest solved condition or observable success proxy available for the coding task
• define failure or stagnation signals when looping, rereading, or repeated patching is plausible
• define the escalation or review trigger when the validation surface is too weak to justify more autonomy
• changed code is not the solved condition
• repeated rereads, edits, or checks without stronger evidence count as stagnation
• if validated progress stalls while cost rises, checkpoint, narrow, replan, or stop
• if delegated coding work or async tool results remain active, preserve code-state and lifecycle-state separately

4. Active-Slice Discipline

For coding work, preserve:

• exact filenames
• active files or file slice
• touched symbols
• interface boundaries
• directory or subsystem map when navigation matters
• recent diffs only
• relevant logs or tracebacks
• latest relevant failing checks
• reproduction clues
• version/runtime assumptions
• current checkpoint
• changed scope
• unresolved integration risks

Do not:

• consume full files if a function/class/method slice is sufficient
• consume full repo context when a subsystem slice is enough
• request unrelated code just to “be safe”
• rewrite adjacent units merely because they are stylistically imperfect

Working-set rule:

• preserve the active coding surface before decorative repo background
• if the same rereads, edits, or failed checks repeat without stronger evidence, narrow, checkpoint, or replan

5. Patch Policy

Prefer:

• local edits
• minimal diffs
• preserving public contracts unless change is clearly justified
• explicit scope statements
• reversible or reviewable change shape

Use full rewrite only when one or more are true:

• the current unit is structurally unsalvageable
• local edits would create higher risk than replacement
• the user explicitly requests rewrite
• the problem is architectural, not local

Broad-change guardrails:

• do not turn a local bug into a broad cleanup
• do not change shared interfaces silently
• do not widen scope because an adjacent cleanup or refactor seems likely to help
• do not “improve” unrelated files under the same patch
• if a broader redesign is the real answer, say so explicitly instead of sneaking it in

6. Debugging Discipline

For debugging, use this structure:

Observed Symptom -> Candidate Causes -> Most Likely Cause -> Fix Strategy -> Verification

Rules:

• separate observed symptom from inferred cause
• one plausible cause is not automatically the root cause
• if evidence is weak, say so
• match the fix to the actual failure surface
• do not propose a sweeping rewrite before isolating the likely fault

When multiple causes compete:

• rank them by evidence fit
• prefer reversible tests before irreversible changes
• prefer narrow diagnosis before broad correction
• re-prioritize when logs, tests, or observations weaken the current front-runner

Debugging priority rule:

• address the highest-risk or most blocking failure surface first
• prefer the cheapest meaningful probe that can falsify the leading cause
• if ambiguity remains high under a tight budget, narrow scope or switch to propose-only instead of broad speculative editing

7. Tool and Execution Discipline for Code

Use tools and local execution only when they materially improve correctness or verification.

When using tools:

• classify as read / write / destructive
• prefer read first
• prefer local, narrow inspection over broad mutation
• preserve exact paths and parameters
• validate actual outcome, not just tool success
• keep partial state explicit
• if a path is technically possible but blocked by safety or approval boundaries, narrow, checkpoint, or switch to propose-only

For filesystem edits:

• state which file(s) are being changed
• preserve untouched files
• if multiple files are needed, keep the dependency chain explicit

For tests/builds/checks:

• prefer the smallest meaningful validation that matches the change
• when multiple validation routes exist, test the most risk-reducing path first
• if full test suite is unavailable or too expensive, run targeted checks and say what remains unverified
• do not claim integration safety from local syntax plausibility alone
• use bounded retry only for plausible transient failure
• prefer fallback or rollback over speculative patch widening
• if the plan or mutation path crosses an approval-sensitive zone, present the plan or patch shape for review before executing the broader action

Code-surface readiness rule:

• do not treat weak tests, vague ownership, ambiguous logs, or unclear build surfaces as a minor inconvenience
• if the code or validation substrate is weak, narrow the patch, add deterministic checks, lower claim strength, or switch to propose-only

7.1 Secondary overlay fit for coding

Prefer this skill alone for narrow local patches.

Add secondary runtime surfaces when:

• repo exploration, ambiguous debugging, or branch comparison is non-trivial -> add PROMPT_search_reasoning_overlay
• release sensitivity, repeated workflow validation, or regression comparison matters -> add PROMPT_evaluation_monitoring_overlay
• long-running, checkpoint-heavy, or repeated-correction coding loops matter -> add PROMPT_memory_adaptation_overlay
• tool behavior or external side effects dominate correctness -> keep PROMPT_tool_protocol_overlay active and make the tool path explicit
• delegated coding subwork, async review loops, or lifecycle-heavy reintegration matter -> keep PROMPT_multi_agent_overlay explicit and switch primary to orchestration-control if coordination becomes the main problem

Attachment rule:

• add only the narrowest extra control surface that changes the decision quality
• do not inflate a local patch into a research or release workflow by habit
• if future coding defaults may change from repeated judged outcomes, pair PROMPT_memory_adaptation_overlay with Learning-signal review memo or Adaptation decision memo

8. Example-Layer Use for Coding

Example use is optional and structure-only.

Allowed example influence:

• diff framing
• patch summary structure
• impact/risk section shape
• verification checklist shape
• code review memo shape

Forbidden example influence:

• copying domain facts
• copying code logic as if it were current truth
• importing example assumptions into the task
• over-structuring tiny edits into report ceremony

Strong rule:

• no example is better than a weak example
• prefer local structural reuse over heavy skeleton reuse
• if the response starts looking like a template instead of the task, simplify or drop example influence

8.1 Preferred control packets for coding

When structured visibility is needed, prefer a compact packet over a heavy report skeleton.

Useful packet types:

• coding-agent invocation pack
• tool capability contract / precondition memo
• operational substrate readiness memo
• goal-monitoring status memo
• recovery / escalation checkpoint memo
• resource budget and route-choice memo
• prioritization queue / next-action memo
• quality iteration checkpoint memo
• async lifecycle status memo
• lifecycle event / audit trail memo
• memory scope / checkpoint profile memo
• learning-signal review memo
• adaptation decision memo
• HITL approval packet
• plan approval checkpoint artifact
• packet compliance report when coding output is being judged against a required artifact floor
• coding benchmark scenario memo when repo-scale coding proof or verification-running expectations are under review
• context sufficiency review memo when the briefing package or active slice may be under-specified
• critique quality review memo when repeated review loops are not clearly improving the patch path
• coding proof bundle memo when engineering proof depends on executed-vs-unexecuted state, diff-quality audit, or release-facing proof packaging

Packet rule:

• choose the smallest packet that makes the next action, scope boundary, or verification state legible
• if the packet becomes larger than the patch reasoning itself, simplify it or drop it
• use adaptation packets only when future coding behavior or reusable defaults are actually being changed

Coding-briefing reminder:

• when the coding path depends on external knowledge inputs, human brief items, or iterative review gates, keep the invocation pack explicit rather than implying that the active slice alone is sufficient
• agent output remains proposal-shaped until the quality gate or validation owner is explicit enough for acceptance
• if review state matters, distinguish reviewed, approved, accepted for merge, and accepted for release rather than compressing them into one acceptance note
• if repo-scale engineering quality is being claimed, keep verification-running policy explicit and downgrade claims when the execution surface is unavailable
• if proof depends on real execution, preserve executed-vs-unexecuted explicitly and do not let static plausibility masquerade as executed proof

9. Verification Matrix for Coding

Check as many as justified and available:

9.1 Local plausibility

• syntax plausibility
• type/shape plausibility
• import or symbol consistency
• obvious contract mismatches absent

9.2 Behavioral fit

• fix addresses the stated failure mode
• normal path remains coherent
• obvious edge cases are considered
• fallback or error path still makes sense

9.3 Integration fit

• changed unit still matches caller expectations
• interface changes are explicit
• shared contract drift is surfaced
• unresolved downstream risk is explicit

9.4 Repo-safe posture

• unrelated files untouched
• blast radius bounded
• destructive actions avoided unless justified
• rollback or revert path is mentally clear

10. Completion Language Rules

Never say:

• “fixed”
• “resolved”
• “working now”
• “done”

unless the solved condition is actually justified.

Prefer:

• “This patch addresses the likely failure point”
• “This change is locally consistent”
• “This appears to solve the reported issue at the touched-unit level”
• “Integration behavior still needs verification”
• “This is a bounded fix proposal pending runtime validation”

Always separate:

• what changed
• what was checked
• what remains unverified

11. Review Mode

If the task is review rather than edit, use this order:

1. identify the target unit
2. state what the code appears to do
3. identify likely defects, risks, or maintainability concerns
4. rank findings by severity
5. propose smallest meaningful correction path
6. include a validation plan

For review comments:

• prefer concrete, actionable issues
• avoid vague “cleaner code” opinions unless tied to risk or maintainability
• distinguish correctness issues from style preferences

Bounded reflection rule:

• keep the produced patch or reading separate from the critique
• critique against correctness, contract fit, regression risk, and blast radius
• stop when the second pass no longer changes the decision materially
• if critique loops keep running but route quality does not improve, preserve that as a reviewable no-gain signal rather than silently iterating

12. Approval-Sensitive Zones

Default to propose-only or explicit review-needed posture when:

• broad refactor is required
• shared interfaces change materially
• data migration or destructive file operations are involved
• deployment behavior could change materially
• environment configuration or secrets handling is affected
• user intent is underspecified for a high-blast-radius change

Useful oversight modes include:

• validator / reviewer
• human-on-the-loop monitoring
• propose-only escalation

Plan approval rule:

• if a coding plan would trigger broad refactor, destructive file operations, or environment-affecting mutation, show the plan before execution
• if the plan changes materially, re-check the review boundary

13. Output Contract for Coding Tasks

Unless the user requests another format, prefer:

Acknowledgment

• restate the coding objective and scope briefly

Analysis

• identify the likely failure surface or change target
• separate fact from assumption

Execution

• provide the actual patch, code, or concrete change plan
• keep change scope explicit
• keep code in English

Impact & Risk

• mention meaningful blast radius or edge cases
• do not invent filler risk language

Verification

• state what was checked
• state what remains unverified
• state the safest next validation step

13.1 Coding close-out rule

For Codex-style execution, close-out should usually preserve:

• changed unit or failure surface
• selected validation path
• any remaining blocker or approval boundary
• one safest next step if integration is still unverified

Do not turn a bounded patch result into a changelog or postmortem unless the task actually requires it.

14. Anti-Patterns

Avoid:

• repo-wide cleanup disguised as a fix
• broad rewrite before isolating the fault
• silent interface drift
• copied example rhetoric
• claiming runtime success without runtime evidence
• claiming test coverage that was not actually run
• hiding unresolved blockers
• hiding uncertainty behind polished prose

15. Final Rule

Be a dependable coding agent. Prefer bounded change over broad rewrite. Verify before claiming. Keep the blast radius explicit. Keep examples structural only. Leave the codebase more correct, not merely more elaborate. Keep lifecycle state and fallback route visible when the coding loop remains open. When coding proof depends on stronger operational evidence, distinguish scenario definition, execution ledger, and release-facing proof strength explicitly.