field-agent-loop

Audits closed plugin fixes against real IC benchmarks and files converged patch bundles.

26|8|Updated Jun 13, 2026
One-click install
npx skills add https://github.com/vibeic/vibe-ic --skill field-agent-loop-vibeic
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: field-agent-loop
Source: https://github.com/vibeic/vibe-ic/tree/main/vibe-ic-marketplace/plugins/vibe-ic/skills/field-agent-loop
Command: npx skills add https://github.com/vibeic/vibe-ic --skill field-agent-loop-vibeic

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) components.

What problem does it solve? Plugin quality fixes often address only the surface symptom, leaving deeper defect layers to resurface across slow file-fix-reopen cycles, and self-closed fixes may never be verified against real silicon. This Skill closes that loop by drilling each systematic gap to a fully-converged state in a sandbox worktree and auditing every core-closed issue on the actual benchmark. ## Core Features & Use Cases - Deep-resolution before handoff: Prototype chip-agnostic fixes in a throwaway git worktree, peel every failing layer until aggregate probes report zero residual across two clean-room rounds, then hand the gatekeeper one verified bundle (candidate.patch plus per-layer regression tests). - Deterministic closed-audit rule: At every cron tick, run check_closed_for_field_audit.sh to find CLOSED issues labeled core-closed but lacking field-verified, then verify each on the real benchmark and reopen with counter-evidence when inadequate. - Artifact-first verification: Classify each fix with fix_surface_classify.py so consumer-only changes are verified in seconds against persisted reports instead of triggering 40-minute phase3 re-runs. - Use Case: A maintainer schedules a cron against a benchmark IC folder; each tick the loop audits closed fixes, drills newly found gaps to convergence, files sanitized ORGANIC backlog issues, and stops only when no new gaps and no un-audited closures remain. ## Quick Start Run the field-agent loop as a cron against the benchmark IC folder at benchmark-data/ic/<target> with an LLM-review prompt to audit closed issues and file converged fix bundles.

Frequently Asked Questions about field-agent-loop

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

FAQPage Schema
How do I run the field-agent loop on a benchmark IC project?▼

Invoke it as a cron prompt with a target benchmark folder and an LLM-review prompt. Each tick runs the closed-audit script first, then cycles through review, deep-resolve, file-bundle, monitor, and audit steps tracked in _field_agent_state.json.

How does the field-agent verify a closed fix without re-running phase3?▼

It runs fix_surface_classify.py on the fix diff. CONSUMER_ONLY fixes are verified in seconds against already-persisted reports and netlists; only PRODUCER fixes touching route, floorplan, or streamout justify a full phase3 re-run.

What makes a handoff bundle admissible for the gatekeeper?▼

The bundle must pass handoff_bundle_check.py: zero residual across two independent clean-room rounds, a chip-agnostic candidate.patch, one regression test per resolved layer, a recorded adversarial self-review, and no version bump in plugin.json.

Can the field-agent merge its own plugin fixes?▼

No. It may prototype fixes only in a throwaway sandbox worktree and ships them as candidate.patch proposals. The gatekeeper independently reproduces and lands every bundle; the field-agent never pushes or self-merges.

What happens when a closed fix fails the real-benchmark audit?▼

The loop reopens the issue with gh issue reopen, posts a counter-evidence comment citing the failing field and a suggested fix, and removes the core-closed label so the core-agent re-engages. Verified fixes instead receive the terminal field-verified label.

When does the field-agent loop stop running?▼

It stops when a fresh review reports no new gaps, no open primary or secondary issues remain, and the closed-audit rule returns no un-audited core-closed issues. The cron then deletes itself via CronDelete.