forge-subagent-eval

Evaluates subagent outputs to decide whether to accept, retry, or reject them.

Updated Aug 23, 2026
One-click install
npx skills add https://github.com/f4rkh4d/forge-skill --skill forge-subagent-eval
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: forge-subagent-eval
Source: https://github.com/f4rkh4d/forge-skill/tree/main/skills/agents/forge-subagent-eval
Command: npx skills add https://github.com/f4rkh4d/forge-skill --skill forge-subagent-eval

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Prevent silent multi-agent failures by ensuring a parent/orchestrator does not treat a subagent’s claims as ground truth without verification, especially for irreversible actions.

Core Features & Use Cases

  • Shape and budget validation: Reject malformed or out-of-scope returns (e.g., non-JSON or schema mismatches) before reading content.
  • Hallucination defenses: Cross-check high-impact claims like filenames, URLs, quotes, and numerical statements against real artifacts.
  • Refusal handling and bounded retry: Treat refusals as signals, refine the brief once, cap retries, and decide fallback/escalation after failures.
  • Partial-result recovery: Use successful fan-out outputs while separately surfacing failures, then deduplicate/aggregate before judging.
  • Decision audit trail: Log the parent’s accept/retry/reject decisions with reasons per subagent call for debugging and accountability.

Quick Start

Use the forge-subagent-eval skill when your orchestrator receives a subagent response and you must verify whether to accept, retry with a sharper brief, or fall back instead of acting irreversibly.

Frequently Asked Questions about forge-subagent-eval

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

FAQPage Schema
How do I verify subagent outputs in a multi-agent system before taking action?

You can prevent orchestrators from acting on unverifiable claims by applying shape and budget validation, internal consistency checks, and spot-verification of external claims like URLs, filenames, and quotes before accepting the subagent output.

What is the best way to handle refusals from subagents during fan-out aggregation?

Handle subagent refusals by treating them as signals, refining the task brief once, capping retries, and then deciding whether to fall back or escalate after the bounded retry fails.

How do I prevent hallucinated claims from causing irreversible file edits or deploys?

Prevent irreversible actions by cross-checking high-impact claims like filenames and numerical statements against real artifacts, then logging the parent orchestrator's accept, retry, or reject decision per call.

Why does my orchestrator fail silently when processing malformed JSON returns?

Orchestrators fail silently on malformed JSON when they lack shape and budget validation to reject non-JSON or schema mismatches before reading the content and acting on unverifiable claims.

Can I use partial-result recovery for multi-agent fan-out tasks?

Yes, you can use partial-result recovery in fan-out tasks by aggregating successful outputs while separately surfacing failures, then deduplicating the results before judging the final output.

Do I need audit logging for multi-agent decision making?

You need audit logging for multi-agent decision making to log the parent orchestrator's accept, retry, or reject decisions with reasons per subagent call for debugging and accountability.