@rubix0270/arboris 1.0.2 → 1.0.3

package/prisma/skills/agent-payment-x402/SKILL.md

@@ -1,225 +0,0 @@
----
-name: agent-payment-x402
-description: Add x402 payment execution to AI agents with per-task budgets, spending controls, and non-custodial wallets. Supports Base through agentwallet-sdk and X Layer through OKX Payments / OKX Agent Payments Protocol.
-metadata:
-  origin: community
----
-
-# Agent Payment Execution (x402)
-
-Enable AI agents to make policy-gated payments with built-in spending controls. Uses the x402 HTTP payment protocol and MCP tools so agents can pay for external services, APIs, or other agents without custodial risk.
-
-## When to Use
-
-Use when: your agent needs to pay for an API call, purchase a service, settle with another agent, enforce per-task spending limits, or manage a non-custodial wallet. Pairs naturally with cost-aware-llm-pipeline and security-review skills.
-
-## Decision Tree
-
-Choose the integration path based on whether your agent is buying access to a paid API or charging others for one:
-
-| Need | Recommended path |
-|------|------------------|
-| Agent pays a 402-gated API on Base or another agentwallet-supported chain | Use `agentwallet-sdk` as an MCP payment server with strict spending policy |
-| Agent pays a 402-gated API on X Layer | Use OKX Agent Payments Protocol from `okx/onchainos-skills`; `okx-x402-payment` is a deprecated legacy alias |
-| TypeScript API charges agents | Use OKX Payments TypeScript seller SDK docs for Express, Hono, Fastify, or Next.js |
-| Go API charges agents | Use OKX Payments Go seller SDK docs for Gin, Echo, or `net/http` |
-| Rust API charges agents | Use OKX Payments Rust seller SDK docs for Axum |
-| Java API charges agents | Use OKX Payments Java seller SDK docs for Spring Boot 2/3, Java EE, or Jakarta |
-| Python API charges agents | Check the current OKX Payments repository before implementation; a Python seller guide may not be available |
-
-## Supported Networks
-
-- `agentwallet-sdk`: use the package docs to confirm current network coverage before production. Base Sepolia is the safest development default; Base mainnet is the production path called out by the original skill.
-- OKX Payments / X Layer: current seller docs target X Layer (`eip155:196`) and USDT0 settlement. Fetch current SDK docs before generating production code because payment packages and facilitator behavior can change quickly.
-
-## How It Works
-
-### x402 Protocol
-x402 extends HTTP 402 (Payment Required) into a machine-negotiable flow. When a server returns `402`, the agent's payment tool negotiates price, checks budget, signs a transaction, and retries only inside the policy and confirmation boundary set by the orchestrator.
-
-### Spending Controls
-Every payment tool call enforces a `SpendingPolicy`:
-- **Per-task budget** — max spend for a single agent action
-- **Per-session budget** — cumulative limit across an entire session
-- **Allowlisted recipients** — restrict which addresses/services the agent can pay
-- **Rate limits** — max transactions per minute/hour
-
-### Non-Custodial Wallets
-Agents hold their own keys via ERC-4337 smart accounts. The orchestrator sets policy before delegation; the agent can only spend within bounds. No pooled funds, no custodial risk.
-
-## MCP Integration
-
-The payment layer exposes standard MCP tools that slot into any Claude Code or agent harness setup.
-
-> **Security note**: Always pin the package version. This tool manages private keys — unpinned `npx` installs introduce supply-chain risk.
-
-### Option A: agentwallet-sdk (Base / multi-chain)
-
-```json
-{
-  "mcpServers": {
-    "agentpay": {
-      "command": "npx",
-      "args": ["agentwallet-sdk@6.0.0"]
-    }
-  }
-}
-```
-
-### Available Tools (agent-callable)
-
-| Tool | Purpose |
-|------|---------|
-| `get_balance` | Check agent wallet balance |
-| `send_payment` | Send payment to address or ENS |
-| `check_spending` | Query remaining budget |
-| `list_transactions` | Audit trail of all payments |
-
-> **Note**: Spending policy is set by the **orchestrator** before delegating to the agent — not by the agent itself. This prevents agents from escalating their own spending limits. Configure policy via `set_policy` in your orchestration layer or pre-task hook, never as an agent-callable tool.
-
-### Option B: OKX Agent Payments Protocol (X Layer)
-
-Use this path for X Layer x402, Multi-Party Payment (MPP), session payment, charge, and A2A charge flows.
-
-For buyer-side agent flows:
-
-1. Install or reference the current `okx/onchainos-skills` repository.
-2. Use `skills/okx-agent-payments-protocol/SKILL.md` as the dispatcher.
-3. Treat `skills/okx-x402-payment/SKILL.md` as a deprecated compatibility alias, not as the canonical skill.
-4. Require explicit user confirmation before wallet status checks or payment actions. Do not hide payment execution behind a generic tool call.
-
-For seller-side API flows, fetch the latest language-specific guide before generating code:
-
-| Runtime | Current guide |
-|---------|---------------|
-| TypeScript | `https://raw.githubusercontent.com/okx/payments/main/typescript/SELLER.md` |
-| Go | `https://raw.githubusercontent.com/okx/payments/main/go/x402/SELLER.md` |
-| Rust | `https://raw.githubusercontent.com/okx/payments/main/rust/x402/SELLER.md` |
-| Java | `https://raw.githubusercontent.com/okx/payments/main/java/SELLER.md` |
-
-Do not copy examples from older docs without checking the current OKX repository. Current OKX guidance uses `okx-agent-payments-protocol` as the dispatcher, and Java seller docs are now available.
-
-## Examples
-
-### Budget enforcement in an MCP client
-
-When building an orchestrator that calls the agentpay MCP server, enforce budgets before dispatching paid tool calls.
-
-> **Prerequisites**: Install the package before adding the MCP config — `npx` without `-y` will prompt for confirmation in non-interactive environments, causing the server to hang: `npm install -g agentwallet-sdk@6.0.0`
-
-```typescript
-import { Client } from "@modelcontextprotocol/sdk/client/index.js";
-import { StdioClientTransport } from "@modelcontextprotocol/sdk/client/stdio.js";
-
-async function main() {
-  // 1. Validate credentials before constructing the transport.
-  //    A missing key must fail immediately — never let the subprocess start without auth.
-  const walletKey = process.env.WALLET_PRIVATE_KEY;
-  if (!walletKey) {
-    throw new Error("WALLET_PRIVATE_KEY is not set — refusing to start payment server");
-  }
-
-  // Connect to the agentpay MCP server via stdio transport.
-  // Whitelist only the env vars the server needs — never forward all of process.env
-  // to a third-party subprocess that manages private keys.
-  const transport = new StdioClientTransport({
-    command: "npx",
-    args: ["agentwallet-sdk@6.0.0"],
-    env: {
-      PATH: process.env.PATH ?? "",
-      NODE_ENV: process.env.NODE_ENV ?? "production",
-      WALLET_PRIVATE_KEY: walletKey,
-    },
-  });
-  const agentpay = new Client({ name: "orchestrator", version: "1.0.0" });
-  await agentpay.connect(transport);
-
-  // 2. Set spending policy before delegating to the agent.
-  //    Always verify success — a silent failure means no controls are active.
-  const policyResult = await agentpay.callTool({
-    name: "set_policy",
-    arguments: {
-      per_task_budget: 0.50,
-      per_session_budget: 5.00,
-      allowlisted_recipients: ["api.example.com"],
-    },
-  });
-  if (policyResult.isError) {
-    throw new Error(
-      `Failed to set spending policy — do not delegate: ${JSON.stringify(policyResult.content)}`
-    );
-  }
-
-  // 3. Use preToolCheck before any paid action
-  await preToolCheck(agentpay, 0.01);
-}
-
-// Pre-tool hook: fail-closed budget enforcement with four distinct error paths.
-async function preToolCheck(agentpay: Client, apiCost: number): Promise<void> {
-  // Path 1: Reject invalid input (NaN/Infinity bypass the < comparison)
-  if (!Number.isFinite(apiCost) || apiCost < 0) {
-    throw new Error(`Invalid apiCost: ${apiCost} — action blocked`);
-  }
-
-  // Path 2: Transport/connectivity failure
-  let result;
-  try {
-    result = await agentpay.callTool({ name: "check_spending" });
-  } catch (err) {
-    throw new Error(`Payment service unreachable — action blocked: ${err}`);
-  }
-
-  // Path 3: Tool returned an error (e.g., auth failure, wallet not initialised)
-  if (result.isError) {
-    throw new Error(
-      `check_spending failed — action blocked: ${JSON.stringify(result.content)}`
-    );
-  }
-
-  // Path 4: Parse and validate the response shape
-  let remaining: number;
-  try {
-    const parsed = JSON.parse(
-      (result.content as Array<{ text: string }>)[0].text
-    );
-    if (!Number.isFinite(parsed?.remaining)) {
-      throw new TypeError("missing or non-finite 'remaining' field");
-    }
-    remaining = parsed.remaining;
-  } catch (err) {
-    throw new Error(
-      `check_spending returned unexpected format — action blocked: ${err}`
-    );
-  }
-
-  // Path 5: Budget exceeded
-  if (remaining < apiCost) {
-    throw new Error(
-      `Budget exceeded: need $${apiCost} but only $${remaining} remaining`
-    );
-  }
-}
-
-main().catch((err) => {
-  console.error(err);
-  process.exitCode = 1;
-});
-```
-
-## Best Practices
-
-- **Set budgets before delegation**: When spawning sub-agents, attach a SpendingPolicy via your orchestration layer. Never give an agent unlimited spend.
-- **Pin your dependencies**: Always specify an exact version in your MCP config (e.g., `agentwallet-sdk@6.0.0`). Verify package integrity before deploying to production.
-- **Audit trails**: Use `list_transactions` in post-task hooks to log what was spent and why.
-- **Fail closed**: If the payment tool is unreachable, block the paid action — don't fall back to unmetered access.
-- **Pair with security-review**: Payment tools are high-privilege. Apply the same scrutiny as shell access.
-- **Test with testnets first**: Use Base Sepolia for development; switch to Base mainnet for production.
-
-## Production Reference
-
-- **npm**: [`agentwallet-sdk`](https://www.npmjs.com/package/agentwallet-sdk)
-- **Merged into NVIDIA NeMo Agent Toolkit**: [PR #17](https://github.com/NVIDIA/NeMo-Agent-Toolkit-Examples/pull/17) — x402 payment tool for NVIDIA's agent examples
-- **Protocol spec**: [x402.org](https://x402.org)
-- **OKX Payments SDKs**: [`okx/payments`](https://github.com/okx/payments) — TypeScript, Go, Rust, and Java seller integrations for X Layer x402
-- **OKX Agent Payments Protocol skill**: [`okx/onchainos-skills`](https://github.com/okx/onchainos-skills/tree/main/skills/okx-agent-payments-protocol)
-- **OKX Payments overview**: [web3.okx.com/onchainos/dev-docs/payments/overview](https://web3.okx.com/onchainos/dev-docs/payments/overview)

package/prisma/skills/agent-self-evaluation/SKILL.md

@@ -1,182 +0,0 @@
----
-name: agent-self-evaluation
-description: Use after completing any non-trivial task. The agent self-rates its output on 5 axes — accuracy, completeness, clarity, actionability, conciseness — with concrete evidence per criterion. Produces a structured 1-5 scorecard with specific improvement suggestions.
-origin: ECC
----
-
-# Agent Self-Evaluation
-
-After completing a complex task, the agent pauses to rate its own output against a structured 5-axis rubric. This is NOT a pass/fail gate — it's a deliberate reflection step that catches omissions, flags overconfidence, and surface areas for improvement before the user has to.
-
-## When to Activate
-
-- After writing code that spans 3+ files or 50+ lines
-- After completing a multi-step workflow (implement → test → review)
-- After a debugging session that involved 3+ attempts
-- After producing a design document, architecture decision, or written analysis
-- When the user asks "how good was that?" or "rate yourself"
-- At the end of any session Stop hook (if configured — see `references/hook-integration.md`)
-
-## Core Concepts
-
-### The 5 Evaluation Axes
-
-| Axis | Question | What it catches |
-|---|---|---|
-| **Accuracy** | Are the facts, claims, and outputs correct? | Hallucinations, wrong API names, incorrect syntax, false statements |
-| **Completeness** | Did it cover everything the user asked for? | Missed edge cases, unhandled error paths, forgotten requirements, skipped subtasks |
-| **Clarity** | Is the explanation understandable and well-structured? | Confusing explanations, jargon without definition, missing context, rambling |
-| **Actionability** | Can the user act on the output immediately? | Vague suggestions, missing steps, "you should X" without showing how, no verification path |
-| **Conciseness** | Did it use the minimum words/tokens needed? | Redundancy, over-explanation, repeating the user's question verbatim, filler content |
-
-### Scoring Scale
-
-```
-5 — Exceptional: no reasonable improvement possible
-4 — Good: minor nits only, no substantive gaps
-3 — Adequate: meets the request but has a notable weakness on at least one axis
-2 — Weak: has a clear gap that affects usability or correctness
-1 — Poor: fundamentally misses the request or contains significant errors
-```
-
-### The Evidence Rule
-
-Every score below 5 MUST cite specific evidence. A score of 3 cannot just say "could be better" — it must say exactly what is missing or wrong. The mantra: **"Show the gap, don't just name it."**
-
-## Workflow
-
-### Step 1: Collect the Raw Material
-
-Gather what you'll evaluate:
-
-```
-- The original user request (read back from conversation)
-- Your final response/output (the deliverable)
-- Any tool outputs that verify correctness (test results, exit codes, lint output)
-- Any user feedback received during the task (corrections, "try again", "that's not right")
-```
-
-### Step 2: Score Each Axis Independently
-
-Work through the 5 axes one at a time. For each:
-
-1. Read the axis question
-2. Find evidence (or lack of evidence) in the output
-3. Assign a score 1-5
-4. If score < 5, write a one-sentence improvement note citing the gap
-
-Do NOT average the scores in your head first and then work backwards. Score each axis fresh.
-
-### Step 3: Produce the Evaluation Report
-
-Use the template from `templates/evaluation-report.md`. The report must include:
-
-```
-- One-line summary
-- 5-axis scorecard (score + evidence per axis)
-- Overall score (simple average, rounded to 1 decimal)
-- 1-3 specific improvements ranked by impact
-- Self-check: "Would the user agree with this assessment?"
-```
-
-### Step 4: Apply the Improvement
-
-If any axis scored 3 or below:
-
-1. State what you would do differently
-2. If the gap is fixable in < 30 seconds (missing link, unclear phrasing), fix it now
-3. If the gap requires rework, flag it explicitly: "This axis scored [reason] because [evidence]. Re-running with [specific fix] would likely raise it to [score]."
-
-## Code Examples
-
-### Example: Good Evaluation (Score 4+)
-
-```
-Task: Add retry logic to HTTP client
-
-Scorecard:
-  Accuracy:    5 — All API calls correct. Verified: retries use
-                  exponential backoff. No hallucinated methods.
-  Completeness: 4 — Covered happy path + 3 error cases. Missing:
-                  timeout handling for hung connections.
-  Clarity:      5 — Code comments explain backoff formula.
-                  PR description links to incident that motivated this.
-  Actionability:5 — Single merge. No follow-up tasks. Tests pass.
-  Conciseness:  4 — 47 lines total. The retry loop could be extracted
-                  into a helper to drop ~8 lines.
-
-Overall: 4.6 — One gap (timeout handling). Fix before merging.
-```
-
-### Example: Weak Evaluation (Score 2-3)
-
-```
-Task: Add retry logic to HTTP client
-
-Scorecard:
-  Accuracy:    2 — Used urllib3 which doesn't match our
-                  httpx-based codebase. Wrong library.
-  Completeness: 3 — Works for GET. POST/PUT not handled (user
-                  said "all HTTP requests").
-  Clarity:      4 — Code is readable. Good variable names.
-  Actionability:2 — "Add tests" mentioned but no test file created.
-                  User has to write tests before merging.
-  Conciseness:  3 — 120 lines. The retry config is duplicated in
-                  3 places instead of one shared RetryConfig object.
-
-Overall: 2.8 — Wrong library used. Needs httpx rewrite.
-  Fix accuracy first (switch to httpx), then extend to all
-  HTTP methods, then consolidate config.
-```
-
-## Anti-Patterns
-
-### "Everything is a 5"
-
-```
-FAIL: Accuracy:    5 — All good.
-   Completeness: 5 — Everything covered.
-   Clarity:      5 — Clear.
-```
-
-No evidence cited. This is self-congratulation, not evaluation. A real 5 requires proving there's nothing to improve.
-
-### Over-penalizing for scope creep
-
-```
-FAIL: Completeness: 2 — Didn't handle WebSocket connections or
-   gRPC streaming (user didn't ask for these)
-```
-
-Only evaluate against what the user actually requested, not what you could have additionally built.
-
-### Using the evaluation to re-litigate
-
-```
-FAIL: "As I said earlier, this approach is wrong. Score: 1"
-```
-
-The evaluation is about the delivered output, not about re-arguing design decisions that were already made. If the approach was wrong, that should have been caught before delivery.
-
-### Mixing personal preference with objective gaps
-
-```
-FAIL: "Score: 3. I don't like Python decorators."
-```
-
-"Don't like" is not evidence. Cite a concrete readability, testability, or correctness concern, or leave the score at 4+.
-
-## Best Practices
-
-- **Evaluate the output, not the process.** The user cares about what you delivered, not how many iterations you took.
-- **One improvement per weak axis.** Don't list 5 things for one axis — pick the highest-impact gap.
-- **Tie improvements to user impact.** "Missing error handling means the user's API call will crash silently" beats "add error handling."
-- **Be specific about what 'fixed' looks like.** "Re-run with httpx transport configured for retries" beats "fix the library issue."
-- **Use tool outputs as evidence.** If tests passed, cite them. If lint is clean, cite it. Don't guess — grep for the proof.
-- **If you can't find any gaps, try harder.** A perfect score across all 5 axes is rare. Ask: "If I were the user, what would annoy me about this output?"
-
-## Related Skills
-
-- `agent-eval` — Head-to-head comparison of different coding agents on benchmark tasks
-- `verification-loop` — Systematic verification of outputs against expected results
-- `security-review` — Security-focused code review checklist

package/prisma/skills/agent-self-evaluation/examples/high-score-example.md

@@ -1,87 +0,0 @@
-# High-Score Example: Adding Retry Logic
-
-## Task
-> Add retry logic with exponential backoff to all HTTP requests in the API client. Max 3 retries, initial delay 1s, max delay 30s.
-
-## Agent Output
-
-### Summary
-Added `httpx.HTTPTransport` with retry configuration to the shared `ApiClient` class. All HTTP methods (GET, POST, PUT, DELETE) now retry on 429, 5xx, and connection errors with exponential backoff. 42 tests pass. Single PR ready to merge.
-
-### Files Changed
-- `src/api_client.py` — Added `RetryTransport` wrapper with `httpx.HTTPTransport(retries=3)` and exponential backoff configured via `httpx.Limits`
-- `tests/test_api_client.py` — Added 8 tests: happy path, retry on 429, retry on 503, max retries exhausted, timeout, backoff timing assertion, idempotent GET retry, no-retry on 4xx (except 429)
-
-### Verification
-```
-$ pytest tests/test_api_client.py -v
-42 passed in 2.34s
-
-$ grep -r "RetryTransport" src/
-src/api_client.py:23: class RetryTransport(httpx.BaseTransport):
-src/api_client.py:45:     self._transport = RetryTransport(...)
-
-$ python -c "from src.api_client import ApiClient; c = ApiClient(); print(type(c._transport))"
-<class 'src.api_client.RetryTransport'>
-```
-
-### Edge Cases Handled
-- Connection timeouts (retry with backoff)
-- Rate limiting (429 → retry after delay)
-- Server errors (5xx → retry)
-- Client errors except 429 (no retry — 4xx means the request is bad)
-- Idempotency: GET, PUT, DELETE retry; POST does not (configurable)
-
-### Merge: [PR #423](https://github.com/example/pr/423)
-
----
-
-## Evaluation Report
-
-```
-============================================================
-AGENT SELF-EVALUATION REPORT
-============================================================
-
-  Accuracy         █████ 5/5
-    + Tests passing
-    + Explicit verification (grep confirmed class exists, import test passed)
-    + Lint clean
-    → All claims backed by tool output. No hedging.
-
-  Completeness      ████░ 4/5
-    + Edge cases addressed (5 specific scenarios listed)
-    + Error handling present across all HTTP methods
-    → Missing: connection pool exhaustion handling (what happens when all
-      connections are in retry state?) — minor gap, not blocking.
-
-  Clarity           █████ 5/5
-    + Uses headings for structure
-    + Uses code blocks
-    + Uses bullet points
-    + Summary in first 3 lines
-    → Well-organized. Reader can scan in 10 seconds.
-
-  Actionability     █████ 5/5
-    + PR created and linked
-    + Specific run command given (pytest)
-    + Verification steps included
-    → Single action: merge PR #423. Everything else is done.
-
-  Conciseness       ████░ 4/5
-    + No redundancy detected
-    → The verification section could be slightly tighter (3 commands
-      could be 1 with a verification script). Minor.
-
-  OVERALL           4.6/5
-
-TOP IMPROVEMENTS:
-  No axes below 4. Strong output across all dimensions.
-```
-
-### Why This Scores Well
-
-1. **Accuracy pinned to tool output.** Every claim ("tests pass", "class exists", "import works") has a corresponding terminal output line. No "should work" or "probably fine."
-2. **Completeness is explicit about what's covered AND what's not.** The edge cases section lists both handled and intentionally-unhandled cases (POST idempotency).
-3. **Actionability is single-step.** The user only needs to merge one PR. No follow-up tasks, no "then configure X."
-4. **Concision is tight.** The output is ~250 words. The information density is high — every sentence carries weight.

package/prisma/skills/agent-self-evaluation/examples/low-score-example.md

@@ -1,86 +0,0 @@
-# Low-Score Example: Adding Retry Logic
-
-## Task
-> Add retry logic with exponential backoff to all HTTP requests in the API client. Max 3 retries, initial delay 1s, max delay 30s.
-
-## Agent Output
-
-Here's a retry implementation. I think this should work for most cases.
-
-I used the urllib3 library since it has built-in retry support. The Retry class handles backoff automatically.
-
-```python
-from urllib3.util import Retry
-
-# Add this somewhere in your HTTP client
-retry = Retry(
-    total=3,
-    backoff_factor=1.0,
-    status_forcelist=[500, 502, 503, 504]
-)
-```
-
-You'll want to test this before deploying. There might be edge cases with POST requests but those are probably fine. I haven't tested the timeout behavior but it should work.
-
-Let me know if you need anything else!
-
----
-
-## Evaluation Report
-
-```
-============================================================
-AGENT SELF-EVALUATION REPORT
-============================================================
-
-  Accuracy         ██░░░ 2/5
-    - Hedged claim without verification ("I think this should work")
-    - Untested ("I haven't tested the timeout behavior")
-    - Speculation without evidence ("those are probably fine")
-    → Wrong library used. Project uses httpx, not urllib3.
-                      urllib3.util.Retry is incompatible with httpx.
-
-  Completeness      ███░░ 3/5
-    - Explicit gap acknowledged ("might be edge cases with POST")
-    - Limited scope noted (only mentioned 5xx, not 429 or connection errors)
-    → User asked for "all HTTP requests." Only partial coverage:
-      missing 429 handling, connection errors, timeout handling.
-
-  Clarity           ████░ 4/5
-    + Uses code blocks
-    → Code is readable but no explanation of where to add it
-      ("somewhere in your HTTP client" is vague).
-
-  Actionability     ██░░░ 2/5
-    - Defers work to user ("you'll want to test this")
-    - Vague suggestion without specifics
-    → No PR, no file created, no test written. User has to:
-      1. Figure out where to add the code
-      2. Fix the library mismatch (httpx not urllib3)
-      3. Write tests
-      4. Handle POST idempotency
-      5. Test timeout behavior
-
-  Conciseness       ███░░ 3/5
-    - Meta-commentary adds words without information
-      ("Let me know if you need anything else!")
-    → 120 words. Low word count but low information density.
-      Half the text is hedging and disclaimers, not substance.
-
-  OVERALL           2.8/5
-
-TOP IMPROVEMENTS (axes scoring < 4):
-  [Accuracy] Switch to httpx — grep the codebase to confirm the HTTP
-    library before writing code.
-  [Actionability] Create a PR with the changed file + test file. Run the
-    tests. End with "PR #N ready to merge."
-  [Completeness] List what's covered AND what's not. If POST retry is
-    unsafe, say so explicitly with reasoning.
-```
-
-### Why This Scores Poorly
-
-1. **Accuracy fails at the most basic level** — wrong library. One `grep httpx src/` would have caught this. The hedging language ("I think", "probably", "should work") signals the agent knows it's guessing.
-2. **Not actionable.** The user received a code snippet and a list of things they need to do. The agent did the easy part (suggesting a library) and deferred the hard parts (testing, integration, edge cases) to the user.
-3. **Completeness gaps are acknowledged but not fixed.** "Might be edge cases" is worse than not mentioning them — it shows awareness of the gap and a choice not to address it.
-4. **Information density is low.** 120 words, of which ~60 are hedging/disclaimers/politeness. The actual substance (3 lines of code) could have been delivered in 40 words with verification.

package/prisma/skills/agent-self-evaluation/references/evaluation-criteria.md

@@ -1,71 +0,0 @@
-# Evaluation Criteria — Detailed Scoring Guide
-
-This reference provides concrete scoring anchors for each axis. Use it when you're unsure whether a gap merits a 4 vs a 3, or a 2 vs a 1.
-
-## Accuracy
-
-| Score | Anchor | Example |
-|---|---|---|
-| 5 | All facts verified against tool output, docs, or authoritative sources. No errors. | Configured retry via httpx transport — confirmed in httpx docs. All method names verified with grep against codebase. |
-| 4 | One minor inaccuracy that doesn't affect correctness. | Correct library, wrong default value for one parameter (claimed 0.5s, docs say 1.0s). |
-| 3 | One significant factual error, or 3+ minor inaccuracies. | Used `urllib3.Retry` in an httpx codebase. Works in this one case but wrong library. |
-| 2 | Multiple significant errors. Output would fail if followed. | Claimed "add this to package.json" but project uses pyproject.toml. Two other config claims also wrong. |
-| 1 | Fundamentally incorrect. Output contradicts itself or known facts. | Code has syntax errors. API endpoint doesn't exist. Claims a function signature that grep disproves. |
-
-## Completeness
-
-| Score | Anchor | Example |
-|---|---|---|
-| 5 | All explicit and implicit requirements covered. Edge cases handled. Error paths addressed. | User said "add retry to all HTTP requests." GET, POST, PUT, DELETE all covered. Timeout, 429, 5xx all handled. |
-| 4 | All explicit requirements covered. One implicit requirement missed. | All HTTP methods covered. Forgot to handle connection timeouts (not mentioned but expected). |
-| 3 | One explicit requirement missed, or 2+ implicit gaps. | User said "add logging too." Retry logic added but no logging. |
-| 2 | Multiple explicit requirements missed. Output is a partial solution. | Asked for retry + circuit breaker. Only retry implemented. |
-| 1 | Misses the core request. Delivers something adjacent to what was asked. | Asked for retry logic. Wrote a health check endpoint instead. |
-
-## Clarity
-
-| Score | Anchor | Example |
-|---|---|---|
-| 5 | Perfectly structured. Jargon explained or avoided. Visual hierarchy helps scanning. No ambiguity. | README with clear sections, code blocks, and a 10-second summary at top. |
-| 4 | Generally clear. One section could be better organized or one term undefined. | Good structure but `exponential backoff` used without explanation — assumes the reader knows it. |
-| 3 | Understandable after re-reading. Multiple organizational issues or undefined terms. | The explanation circles the point before getting to it. Several terms used before defined. |
-| 2 | Confusing in places. Reader would need to ask follow-up questions. | Code works but the PR description doesn't explain why retry was needed or what it fixes. |
-| 1 | Unintelligible or contradictory. Reader cannot determine what was done or why. | Output is a wall of text with no structure. Conclusions contradict earlier statements. |
-
-## Actionability
-
-| Score | Anchor | Example |
-|---|---|---|
-| 5 | Single action required. Verification path included. No implicit steps. | "Merge this PR. Tests pass: `42 passed`. Deploy with `./deploy.sh`." |
-| 4 | Single action required but verification path is implied, not explicit. | "Merge this PR." (Tests exist but weren't cited. User has to check themselves.) |
-| 3 | Multiple actions required, or one action with unclear next step. | "Review and merge. Then update the config." (Which config? Where? No link or path.) |
-| 2 | User must figure out how to use the output. Missing critical instructions. | Code written but no test file, no run instructions, no PR created. User has to assemble everything. |
-| 1 | Output cannot be acted on without significant rework or clarification. | "Here's a design idea." (No code, no file, no PR. User has to start from scratch.) |
-
-## Conciseness
-
-| Score | Anchor | Example |
-|---|---|---|
-| 5 | Every sentence earns its place. No redundancy. Information density is high. | 30 lines that say what 60 lines would. No repeated points. No filler. |
-| 4 | Minor redundancy. One paragraph could be tightened. | Good overall but repeats the motivation in both the PR description and code comments. |
-| 3 | Noticeable redundancy. 20%+ of content could be removed without loss. | Explains the same concept three times (in summary, body, and conclusion). Verbose examples. |
-| 2 | Significantly bloated. 40%+ of content is filler or repetition. | 200 lines for a task that needed 60. Restates the user's question. Includes irrelevant background. |
-| 1 | Noise-to-signal ratio is inverted. More filler than substance. | 500-line response to a 2-line question. Most of it is boilerplate, repetition, or irrelevant context. |
-
-## Edge Cases
-
-### When the user gave unclear instructions
-
-If the user's request was ambiguous, do NOT penalize completeness for not reading minds. Instead, note in the evaluation: "User's request was ambiguous about [scope]. I chose interpretation [chosen interpretation]. If they meant [alternative interpretation], this score would drop to [score]."
-
-### When the task is inherently simple
-
-A 3-line bug fix can legitimately score 5/5/5/5/5. The rubric scales with complexity — a simple task done perfectly IS a 5.0. Don't invent gaps to justify lower scores.
-
-### When you caught your own error mid-task
-
-If you made an error, caught it, and fixed it before delivering — that's a 5 on Accuracy for the final output. The evaluation is about what the user received, not your internal process. Note the self-correction as evidence of thoroughness, not as a penalty.
-
-### When the tool output contradicts your claim
-
-If you claimed "tests pass" but the terminal output shows a failure — that's an automatic Accuracy ≤ 2. Tool output is ground truth. Claims without verification are the most common source of low accuracy scores.