harness-runtime-feedback

Builds a runtime evidence plan covering logs, health checks, error signals, and observability for task validation.

Updated Jul 29, 2026
One-click install
npx skills add https://github.com/MaiconGambini/opencode-harness-guide --skill harness-runtime-feedback-maicongambini
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: harness-runtime-feedback
Source: https://github.com/MaiconGambini/opencode-harness-guide/tree/main/skills/harness-runtime-feedback
Command: npx skills add https://github.com/MaiconGambini/opencode-harness-guide --skill harness-runtime-feedback-maicongambini

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Static checks and tests alone cannot prove that a system behaves correctly at runtime. This Skill audits a project for observable runtime surfaces and produces a concrete evidence plan so validation is grounded in real logs, health checks, and error signals rather than assumptions. ## Core Features & Use Cases - Runtime Surface Audit: Inspects the project for logging, health/readiness endpoints, error handlers, retry and timeout policies, and browser console or network evidence. - Structured Evidence Plan: Outputs a Markdown plan listing exact files, commands, endpoints, and expected failure signals, marking anything missing as unknown instead of inventing observability. - Use Case: Before validating a new API feature, run this Skill to identify which log files to tail, which health endpoint to poll, and which error message confirms a failure, so reviewers can verify behavior with concrete evidence. ## Quick Start Ask the agent to build a runtime evidence plan for the current task, covering logs, health checks, and expected error signals.

Frequently Asked Questions about harness-runtime-feedback

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I create a runtime evidence plan for validating a task?

Audit the project for logs, health endpoints, error handlers, and retry policies, then record concrete files, commands, and endpoints in a structured plan. Mark anything not present as unknown rather than inventing observability.

What runtime evidence should I collect for frontend or browser work?

For UI work, include browser console output and network request evidence alongside any application logs. The plan should name the exact console signals and network calls that confirm the expected behavior.

Does runtime evidence replace automated tests?

No. Runtime evidence complements tests by proving actual behavior through logs, health checks, and error signals. Tests remain the primary correctness gate; runtime evidence adds observability on top.

How do I validate async jobs and background workers?

Include queue and job status checks in the evidence plan, such as inspecting job state, worker logs, and retry or timeout behavior. Record the exact command or endpoint used to observe each signal.

What if the project has no logging or health checks?

The plan explicitly marks missing observability as unknown instead of fabricating it. This surfaces gaps honestly so teams can decide whether to add instrumentation before relying on runtime validation.