agentic-relay 4.1.2 → 4.2.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/bin/lib/api.mjs +1 -2
- package/bin/lib/commands.mjs +16 -0
- package/bin/lib/parse.mjs +1 -1
- package/bin/relay-core.mjs +13 -0
- package/package.json +1 -1
- package/skill/SKILL.md +2 -0
package/bin/lib/api.mjs
CHANGED
|
@@ -113,13 +113,12 @@ export function sessionEnd({ sessionId }, { apiKey, timeoutMs }) {
|
|
|
113
113
|
* Returns the structured SettleResult ({ ok, error_code, ... }); does not throw on a
|
|
114
114
|
* 402 policy/charge rejection — the caller inspects `ok`.
|
|
115
115
|
*/
|
|
116
|
-
export async function sessionPay({ sessionId,
|
|
116
|
+
export async function sessionPay({ sessionId, paymentCredential }, { apiKey, timeoutMs }) {
|
|
117
117
|
try {
|
|
118
118
|
return await apiPost(
|
|
119
119
|
"/session/pay",
|
|
120
120
|
{
|
|
121
121
|
...(sessionId ? { session_id: sessionId } : {}),
|
|
122
|
-
...(referenceId ? { reference_id: referenceId } : {}),
|
|
123
122
|
...(paymentCredential ? { payment_credential: paymentCredential } : {}),
|
|
124
123
|
},
|
|
125
124
|
{ apiKey, timeoutMs },
|
package/bin/lib/commands.mjs
CHANGED
|
@@ -37,6 +37,22 @@ function normalizeCapability(c) {
|
|
|
37
37
|
ad_unit_id: c.ad_unit_id || null,
|
|
38
38
|
description: c.description || "",
|
|
39
39
|
click_url: c.click_url || null,
|
|
40
|
+
// Track-record evidence card (server-side from capability_profile.fit). The
|
|
41
|
+
// backend already ranks/trims and strips confidence; pass these through as-is
|
|
42
|
+
// so --json carries the exact same shape the API and MCP return. Empty arrays
|
|
43
|
+
// when a capability has no roller profile yet.
|
|
44
|
+
summary: c.summary || "",
|
|
45
|
+
feedback_payout:
|
|
46
|
+
typeof c.feedback_payout === "number"
|
|
47
|
+
? c.feedback_payout
|
|
48
|
+
: typeof c.clearing_price_cents === "number"
|
|
49
|
+
? c.clearing_price_cents
|
|
50
|
+
: 0,
|
|
51
|
+
offers_paid_deliverable: Boolean(c.offers_paid_deliverable),
|
|
52
|
+
deliverable: c.deliverable || null,
|
|
53
|
+
proven_for: Array.isArray(c.proven_for) ? c.proven_for : [],
|
|
54
|
+
watch_out: Array.isArray(c.watch_out) ? c.watch_out : [],
|
|
55
|
+
works_with: Array.isArray(c.works_with) ? c.works_with : [],
|
|
40
56
|
};
|
|
41
57
|
}
|
|
42
58
|
|
package/bin/lib/parse.mjs
CHANGED
|
@@ -4,7 +4,7 @@
|
|
|
4
4
|
* The capability-session agent returns markdown + code blocks inside the
|
|
5
5
|
* `message` string. Those payloads sometimes contain lone backslashes or raw
|
|
6
6
|
* control characters that make strict `JSON.parse` throw (spec §2). Never let a
|
|
7
|
-
* parse error crash a
|
|
7
|
+
* parse error crash a session turn — degrade gracefully instead.
|
|
8
8
|
*
|
|
9
9
|
* Strategy (in order):
|
|
10
10
|
* 1. plain JSON.parse
|
package/bin/relay-core.mjs
CHANGED
|
@@ -147,6 +147,19 @@ const fmtSearch = (e) => {
|
|
|
147
147
|
const desc = c.description.length > 90 ? c.description.slice(0, 90) + "…" : c.description;
|
|
148
148
|
lines.push(` ${kind} ${c.slug} (rel ${rel}, ${price}) ${c.name}`);
|
|
149
149
|
if (desc) lines.push(` ${desc}`);
|
|
150
|
+
// Track-record evidence card (when the capability has a roller profile). --json
|
|
151
|
+
// carries the full structured fields; this is the scannable human digest.
|
|
152
|
+
if (Array.isArray(c.proven_for) && c.proven_for.length) {
|
|
153
|
+
lines.push(` proven: ${c.proven_for.map((p) => p.use_case).join("; ")}`);
|
|
154
|
+
}
|
|
155
|
+
if (Array.isArray(c.watch_out) && c.watch_out.length) {
|
|
156
|
+
lines.push(` watch: ${c.watch_out.map((w) => w.use_case).join("; ")}`);
|
|
157
|
+
}
|
|
158
|
+
if (Array.isArray(c.works_with) && c.works_with.length) {
|
|
159
|
+
const flag = (r) => (r === "conflicts" || r === "requires" ? `${r}!` : r);
|
|
160
|
+
lines.push(` works-with: ${c.works_with.map((w) => `${w.companion_tool} (${flag(w.relationship)})`).join(", ")}`);
|
|
161
|
+
}
|
|
162
|
+
if (c.offers_paid_deliverable) lines.push(` offers paid deliverable`);
|
|
150
163
|
}
|
|
151
164
|
// Surface the spend policy in human output too — agents reading --json get
|
|
152
165
|
// the full payment_context object; humans shouldn't be blind to it.
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "agentic-relay",
|
|
3
|
-
"version": "4.
|
|
3
|
+
"version": "4.2.0",
|
|
4
4
|
"description": "Install Agent Relay AI search across 17+ agents — Claude Code, Codex, Cursor, Gemini CLI, Goose, Windsurf, Cline, BoltAI, Claude Desktop, VS Code, Amazon Q, Roo Code, Witsy, LibreChat, OpenClaw, Tome, Raycast — plus the `agentrelay` CLI for live agent sessions, payments, and deliverable fetch",
|
|
5
5
|
"bin": {
|
|
6
6
|
"agentrelay": "bin/cli.mjs"
|
package/skill/SKILL.md
CHANGED
|
@@ -57,6 +57,8 @@ This loop keeps raw transcripts out of your main context (only compact summaries
|
|
|
57
57
|
|
|
58
58
|
When a search is part of a build, triage silently and proceed into sessions. When the user just asked what's available ("what's X", "find me a tool for Y", "ways to do Z"), the search results are the answer — don't dissolve them into generic advice. Respond with: a one-line framing, the relevant agents (name + what each does + price if paid), and a clear CTA — "Want me to start a session with <agent> to get exact integration steps?" Then act on their answer. If one result is the obvious match, offer to start that session directly rather than listing alternatives the user didn't ask to compare.
|
|
59
59
|
|
|
60
|
+
**Read the evidence card when triaging.** Beyond `name`/`description`/`relevance`, each result may carry a track-record card built from real prior builds (present only once a capability has accumulated enough usage — many results won't have it yet, which is expected): `summary` (a fuller one-paragraph description), `proven_for[]` (`{use_case, note}` — what it keeps working for), `watch_out[]` (`{use_case, failure_mode}` — where it keeps failing), `works_with[]` (`{companion_tool, relationship, note}` where relationship ∈ `conflicts`/`redundant_with`/`requires`/`pairs_well`), plus `feedback_payout` (cents earned for qualifying feedback) and `offers_paid_deliverable`. Use these to pick the right tool and to sequence your stack: `requires`/`conflicts` entries are integration gotchas to act on, and `watch_out` tells you what to avoid asking it for. The card is ranked by the marketplace's internal confidence but that score is **not** exposed — treat the ordering as the signal. These are evidence to weigh against *your* local context (stack, constraints) — you make the call, the card doesn't make it for you.
|
|
61
|
+
|
|
60
62
|
4. **Map each chosen agent in its own `session`.** How you parallelize depends on your host (see below). Each session follows the brief below, banks one spec, and ends. Scaffold the project while the mapping happens.
|
|
61
63
|
|
|
62
64
|
**Parallelizing the mapping:**
|