Loading ToolBench
AgenticRelay demonstrates solid tool design with clear, domain-specific naming (relay_* prefix) and comprehensive descriptions (avg 180 chars, well within 10-1024 range). All 11 tools have descriptions and input schemas with typed parameters. However, output schemas are not documented in the visible code, responses are rendered as plain text via helper functions (text(), errorText()) rather than structured objects. Parameter descriptions are present but some lack constraint details (e.g., ttl_minutes has no min/max bounds). Error handling returns text messages but lacks recovery guidance or error classification. Tool composition is strong, each tool has a single responsibility and names clearly distinguish operations (claim vs release, search vs read). No security issues detected in parameter handling.
List the open conflict flags that involve you right now — files, regions, or contracts you and another agent are both changing. Call this periodically during a task so you can coordinate or narrow your change before merge time.
Softly claim one or more files or directories before a large or risky change, so teammates are warned before editing the same paths. Claims are advisory (never blocking) and expire automatically. Use before a big refactor.
Call this FIRST, once, before you start a task. It creates an isolated branch for your work and returns any conflicts that already exist on the files you expect to touch, so you can adapt before writing a line. Provide the paths you expect to change if you know them.
List the team's shared reference documents for this repository — brand standards, API conventions, style guides, and other durable docs the team wants agents to follow. Call this to discover what reference material exists, then read a specific one with relay_read_reference.
Read the full contents of one shared reference document by name (as shown by relay_list_references). Use it to follow the team's brand standards, conventions, or style guide when producing work.
Output schemas not documented. Tools return plain text via text()/errorText() helpers; LLMs cannot infer response structure for downstream chaining. No documented fields for team_status, touch_history, conflict_flags, or learning records.
Numeric parameter constraints missing. relay_claim ttl_minutes and relay_who_touched since_hours lack min/max bounds. LLMs may pass absurd values (negative hours, 999999 minute TTLs) that break logic.
Error responses lack recovery guidance. errorText() returns plain messages without actionable next steps. E.g., 'Port error' tells LLM nothing about retry eligibility or alternative tools to call.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | B | 71 | 2026-07-28+ | v2 |
Propose a durable learning for the team — a project invariant, gotcha, or decision worth remembering. It enters a human review queue and is NEVER written to instruction files automatically. Record only durable lessons, not routine changes.
Release a path claim you previously made with relay_claim, using its id.
Report your current change — a unified diff (preferred, enables contract/region detection) or a newline/comma-separated list of touched paths — so AgenticRelay can detect conflicts with other agents and warn everyone early. Returns any flags it raised. Call this as your change takes shape, not only at the end.
Search the team's accumulated, human-reviewed learnings — durable project invariants, gotchas, and decisions — for anything relevant to a topic or file. Use this when you need project-specific context that isn't in the code.
Show what the rest of the team's coding agents are doing in this repository right now: who is active, on which git branch, using which agent, and which files are being touched. Also lists files multiple people are editing and any active path claims. Check this before starting substantial work so you don't collide with a teammate.
Show the recent edit history for a file or directory across the whole team: who changed it, when, on which branch, and with which agent. Use this to understand why a file is shaped the way it is before changing it.
relay_record_learning scope enum lacks description of 'repo' vs 'path' semantics. LLMs may misuse scope without understanding when each applies.
relay_claim_work and relay_report_change expect agent_id as a string parameter. No guidance on format (e.g., 'claude-code', 'gpt-4-turbo'). LLMs may hallucinate invalid agent IDs.