harness-observability

name	harness-observability
description	Use when checking harness health, setting up observability cadences, understanding snapshot formats, configuring telemetry export, or verifying that the harness's own observability is working — covers all four layers of harness observability

Harness Observability

Harness observability is the measurement layer that makes context engineering, architectural constraints, and garbage collection evidence-based rather than intuition-based. Without it, a harness is infrastructure you hope works. With it, you know.

This skill covers four layers of observability, each answering a different question at a different timescale.

This skill does not cover CI workflow configuration (middle loop), individual constraint design, or garbage collection rule authoring — those belong to their respective skills. It covers how to observe whether those mechanisms are operating effectively.

For the snapshot schema and field definitions, consult references/snapshot-format.md. The snapshot includes a Diaboli panel (after Session Quality, before Operational Cadence) that surfaces advocatus-diaboli activity as descriptive stats across all objection records.

The Four Layers

Layer	Question	Timescale	Consumer
Operational Cadence	"Is the harness running?"	Session / weekly / quarterly	Developer in session
Trend Visibility	"How has the harness changed?"	Weekly / quarterly	Team over time
Telemetry Export	"Can I visualise this externally?"	Continuous	External dashboards
Meta-Observability	"Is the observability itself working?"	Quarterly	Agents + team

Layer 1: Operational Cadence

The harness has mechanisms — audit, GC, reflection, mutation testing — but mechanisms only work if they run. Operational cadence ensures they actually fire on schedule.

The primary tool is /harness-health. Running it:

1. Produces a structured snapshot of the harness's current state
2. Surfaces deltas from the previous snapshot
3. Flags overdue cadences (e.g. "last audit was 45 days ago")
4. Updates the README health badge

Recommended cadences:

Mechanism	Cadence	Command
Health snapshot	Monthly	/harness-health
Full audit	Quarterly	/harness-audit
Assessment	Quarterly	/assess
Reflection review	Quarterly	Review REFLECTION_LOG.md
Mutation trend check	Monthly	Download CI artifacts

A Stop hook nudges the developer when the last snapshot is older than 30 days. This turns a declared cadence into an actual practice.

Layer 2: Trend Visibility

Snapshots are point-in-time. Trends are the delta between snapshots. No external tooling required — trends are computed by diffing markdown files.

When /harness-health runs and a previous snapshot exists, it:

1. Computes deltas for every tracked metric
2. Appends a Trends section to the new snapshot
3. Prints a delta summary to the session

For quarterly reviews, /harness-health --trends reads all snapshots and produces a multi-period trend view.

What agents do with trends: The orchestrator reads the latest snapshot's Trends section before planning work. Declining mutation scores might trigger test quality prioritisation. A stalled learning flow might prompt a /reflect nudge.

Layer 3: Telemetry Export

For teams that want Grafana, Langfuse, or other external dashboards, the snapshot data can be exported as OpenTelemetry metrics.

This is optional. The file-based approach (Layers 1-2) works without any external tooling. Telemetry export adds continuous visibility for teams operating at scale.

For OTel metric names, semantic conventions, and a reference export script, consult references/telemetry-export.md.

Layer 4: Meta-Observability

The self-referential layer: the harness checking whether its own observability is working.

"A harness that cannot verify its own operation is a harness you hope works."

The harness-auditor agent runs five meta-checks:

Check	Signal
Snapshot currency	Stale = outer loop not running
Cadence compliance	Overdue = practice not followed
Learning flow	Stalled = compound learning broken
GC effectiveness	Silent = rules may be misconfigured
Trend direction	Unacknowledged decline = drift unnoticed

For thresholds and detailed check definitions, consult references/meta-observability-checks.md.

When to Use This Skill

Situation	Action
Starting a new quarter	Run /harness-health to baseline
After a major feature lands	Run /harness-health to check impact
Harness feels stale	Run /harness-health --deep for authoritative check
Quarterly review	Run /harness-health --trends for multi-period view
Setting up a new project	Configure cadences in CLAUDE.md
Want external dashboards	Follow references/telemetry-export.md

README Health Indicator

/harness-health maintains two README elements:

Health badge — shields.io, colour-coded:

Status	Condition	Colour
Healthy	All layers operating, no overdue cadences	Green
Attention	One layer degraded or outer loop overdue	Amber
Degraded	Multiple layers degraded or no snapshot in 30+ days	Red

Health icon — a custom SVG linked to the latest snapshot.

The badge colour factors in meta-health. Stale snapshots or overdue cadence trigger amber even if enforcement ratios look fine.