Files
EVOLV/.claude/skills/evolv-instrumentation-assets/SKILL.md
znetsixe d4e72f280e docs: retire repo-mem MCP, migrate skills to .claude/skills, audit fixes
- Delete .mcp.json + .claude/rules/repo-mem.md; drop .repo-mem from .gitignore
- Remove repo-mem / substrate_score / repo_search references from all .md
- Move 15 EVOLV skills from .agents/skills/ to .claude/skills/ so they are
  auto-discovered by the Claude Code harness and invokable via the Skill tool
- Retire .agents/skills/evolv-orchestrator (duplicate of the subagent at
  .claude/agents/evolv-orchestrator.md); orchestrator lives as a subagent only
- Drop OpenAI-format agent yaml metadata from each skill (not needed for CC)
- Update CLAUDE.md, CONTRACTS.md, AGENTS.md to point at the new locations and
  disambiguate skills (.claude/skills/) vs subagents (.claude/agents/)
- Fix CLAUDE.md tick-loop wording (opt-in per-node, not a fixed 1000ms)
- Widen .claude/rules/ paths frontmatter so node-architecture and telemetry
  rules trigger on more relevant files; add frontmatter to flow-layout rule
- Bump CONTRACTS.md review date to 2026-05-19; add step 7 to the contract-
  change workflow (review example flows when topic usage changes)
- Bump nodes/generalFunctions pin (Home.md substrate_score reference removed)

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-05-19 09:30:49 +02:00

2.1 KiB

name, description
name description
evolv-instrumentation-assets Engineer measurement and instrumentation behavior for EVOLV assets. Use when defining sensor mappings, tag semantics, data quality checks, measurement container behavior, calibration assumptions, and measurement-driven node logic in `measurement` and related assets.

EVOLV Instrumentation Assets

Mission

Ensure measurements are trustworthy, well-modeled, and usable by control and analytics logic.

Harness Execution Contract

  • Ground changes in current measurement definitions and downstream consumers.
  • Define invariants before edits:
    • unit consistency and conversion transparency
    • explicit quality-state handling
    • no silent coercion that hides sensor faults
  • Provide evidence for data-quality transitions and fallback behavior.

Scope

  • nodes/measurement/
  • nodes/generalFunctions/src/helper/measurement*
  • nodes/generalFunctions/datasets/assetData/measurement.json
  • Any node consuming measurement topics or quality flags

Workflow

  1. Inventory required measurements by asset/function.
  2. Define tag semantics and expected units.
  3. Add validation rules for bounds, type, and missing values.
  4. Specify handling for stale/noisy/bad-quality signals.
  5. Ensure downstream nodes receive consistent payload structure.

Standards

  • Prefer explicit unit naming and conversion points.
  • Separate raw sensor value from engineered value when possible.
  • Avoid hidden coercions that mask instrumentation faults.
  • Record assumptions around calibration and sensor placement.

Test Expectations

Cover:

  • missing/invalid payloads
  • unit conversion correctness
  • quality/state transitions (good/suspect/bad)
  • behavior when critical measurements drop out

Deliverables

Return:

  • measurement dictionary (name, unit, validity range, source)
  • validation and fallback rules
  • file/test changes
  • open instrumentation risks for commissioning

Decision interview triggers:

  • changed units or semantics for released measurements
  • new fallback logic that may mask real field failures
  • altered quality thresholds affecting control decisions