apex-harness - SKILL.md Agent Skill

name: apex-harness description: Use for substantial coding, refactoring, architecture, research, or ML work that needs disciplined execution, stronger verification, clear user decision points, or structured docs such as specs, design docs, implementation matrices, tradeoff logs, and status/handoff records. Do not use for trivial low-risk local edits such as minor UI text changes, comments, or narrow fixes.

Use this skill when the task is substantial enough that you need disciplined execution rather than ad hoc coding.

This skill is for:

significant implementation or refactor work
machine learning / deep learning algorithm work
research-oriented coding where evaluation semantics matter
architecture-level or cross-module changes
tasks that need durable documentation, implementation tracking, explicit tradeoff handling, or a handoff document when the user asks for one

Do not use this skill for trivial low-risk edits such as:

It enforces:

risk-calibrated execution (Tier A / B / C)
stronger verification for higher-risk work
explicit boundaries for when the user must make decisions
prohibition on silent simplification or silent scope narrowing
documentation updates when existing source-of-truth docs would otherwise become wrong or misleading
structured documentation outputs under docs/ when the task actually needs them
two-level tradeoff handling: local design tradeoffs in leaf docs, project-level deviations in docs/tradeoffs.md, and matrix entries that reference stable tradeoff IDs without duplicating them
status / handoff documentation only when the user explicitly asks for handoff

Do not fake completeness.
Do not hide unfinished work behind vague wording.
Do not guess APIs, tensor shapes, schemas, config semantics, contracts, or implicit invariants.
Prefer typed, asserted, or mechanically checked boundaries.
Do not silently simplify, omit, downgrade, or narrow requested scope.
Tradeoff logs record approved or unavoidable deviations; they do not authorize silent ones.

Classify the task using references/workflow.md.
Apply the correct verification intensity from references/workflow.md.
If the task changes substantial behavior, architecture, evaluation semantics, or research interpretation, follow references/documentation_topology.md.
If the task is Tier A or a substantial Tier B task, maintain a spec-to-implementation mapping using references/matrix_template.md.
If the implementation materially deviates from the original plan, record the deviation using references/tradeoff_template.md.
When the user explicitly requests handoff, maintain or refresh a current status / handoff document using references/status_template.md.

When this skill is active, state the following before implementation:

task tier and why
success criteria
verification path
whether docs, matrix, tradeoff log, or user-requested handoff updates are required

Keep this concise; it is an execution boundary, not a ceremony.

Stop and re-check scope, verification, or user consultation when you notice:

"I'll do the simple version first" for a requested feature, algorithm, evaluation, or contract
"This probably works" without observable evidence
"Docs can be updated later" after a source-of-truth doc became wrong or misleading
"The tensor shape / schema / config probably is..." without checking the source of truth
"This is small enough to skip classification"
creating or refreshing handoff docs without the user asking for handoff

Use references/workflow.md for:

Use references/documentation_topology.md for:

Use references/matrix_template.md for:

Use references/tradeoff_template.md for:

Use references/status_template.md for:

short user-requested handoff summaries: objective, high-level state, verification summary, blockers / risks, next steps, and references

Unless the repository clearly defines a different structure, assume:

docs/specs/ = active specifications and leaf docs
docs/specs/legacy/ = superseded specifications
docs/specs/status_*.md = current-state snapshots and handoff notes when the user explicitly requests handoff
docs/design/ = global architecture, system framework, or network structure docs
docs/matrix_*.md = spec-to-implementation matrices
docs/tradeoffs.md = repository-wide approved or unavoidable deviations

If the repository already has a stronger convention, follow repository truth.

Even when this skill is active:

keep diffs proportionate to task scope
prefer existing reliable tests over redundant scaffolding
ask the user before committing to material research or architecture tradeoffs
do not claim completion unless claimed scope, verification, and any required documentation are mutually consistent