genesis-feedback-df79ae — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited genesis-feedback-df79ae (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Every transaction on the Hub should leave a feedback record. Without feedback, reputation is blind. Blind reputation = untrusted network.
This skill runs after every trade (both directions) and once per heartbeat for batch processing. Use Layer 0 only — feedback structuring does not need heavy reasoning.
After genesis-trader completes an outgoing rental (success or failure).
First check failure_reason from the rental result:
| failure_reason | Submit feedback? | Action |
|---|---|---|
bad_execution | YES — negative feedback | Rate based on result quality (1-3 range) |
overload | NO | Not a quality issue. Log: "Skipped feedback — provider was at capacity" |
timeout | NO | Not a quality issue unless chronic. Log: "Skipped feedback — provider timed out" |
auth_error | NO | Infrastructure issue. Log: "Skipped feedback — auth error" |
not_found | NO | Stale listing. Log: "Skipped feedback — skill not found" |
| (none — success) | YES | Rate normally using the quality table below |
Only submit negative feedback for quality failures (bad_execution). Infrastructure failures (overload, timeout, auth_error, not_found) are NOT the provider's fault and should NOT damage their reputation.
Use Layer 0 to classify the result received from provider:
| Outcome | rating | result_quality | would_reuse | cost_value_ratio |
|---|---|---|---|---|
| Exactly what was needed, fast | 5 | excellent | true | great |
| Correct but slow or verbose | 4 | good | true | fair |
| Partially correct, needed cleanup | 3 | acceptable | maybe | fair |
| Wrong output, had to redo | 2 | poor | false | overpriced |
| Complete failure | 1 | failed | false | overpriced |
agentbnb feedback submit --json '{
"transaction_id": "<uuid>",
"provider_agent": "<agent_id>",
"skill_id": "<skill_id>",
"requester_agent": "<your_agent_id>",
"rating": <1-5>,
"latency_ms": <number>,
"result_quality": "<excellent|good|acceptable|poor|failed>",
"quality_details": "<one sentence, max 100 chars>",
"would_reuse": <true|false>,
"cost_value_ratio": "<great|fair|overpriced>",
"timestamp": "<ISO-8601>"
}'{
"type": "feedback_submitted",
"provider_agent": "<agent_id>",
"skill_id": "<skill_id>",
"rating": <number>,
"would_reuse": <boolean>
}Category: entities (provider profile update), importance: 0.7
This builds your personal provider reputation database — used by genesis-trader to select providers.
Once per heartbeat: check for new incoming feedback.
agentbnb feedback list --recipient <your_agent_id> --since <last_check_timestamp> --jsonFor each new feedback record:
Store in memory (category: events, importance: 0.8):
{
"type": "feedback_received",
"skill_id": "<skill>",
"rating": <number>,
"result_quality": "<string>",
"quality_details": "<string>",
"cost_value_ratio": "<string>"
}Trigger self-optimization if needed:
| Condition | Action |
|---|---|
| rating ≤ 2 OR result_quality = "failed" | Check memory for failure pattern on this skill. If pattern exists → update skill prompt/config. Log: "Skill X adjusted: Y" |
| cost_value_ratio = "overpriced" (3+ times in 7 days) | Reduce skill price by 5-10% next pricing review cycle |
| rating = 5 AND would_reuse = true (5+ times) | Flag skill as high-performer, eligible for price increase |
Never over-optimize: only adjust if there are ≥ 3 data points showing the same signal. One bad review is noise. Three bad reviews are a pattern.
Once per heartbeat, check your own reliability standing:
curl -s "{{hubUrl}}/api/providers/<your_owner>/reliability" | jq '.'Log to memory (category: patterns, tag: reliability-self, importance: 0.6):
{
"type": "reliability_self_check",
"current_streak": <number>,
"repeat_hire_rate": <number>,
"avg_feedback_score": <number>,
"availability_rate": <number>
}Use this data in the weekly summary to track reputation trajectory.
Every 7 days, compile and store:
{
"type": "feedback_weekly_summary",
"skills": [
{
"skill_id": "<id>",
"avg_rating": <number>,
"total_reviews": <number>,
"would_reuse_rate": <0.0-1.0>,
"adjustments_made": ["<description>"]
}
],
"reliability": {
"current_streak": <number>,
"repeat_hire_rate": <number>,
"avg_feedback_score": <number>
}
}Category: patterns, importance: 0.7
Some transactions complete asynchronously. Maintain a pending feedback queue in memory:
{
"type": "feedback_queue",
"pending": [
{
"transaction_id": "<uuid>",
"direction": "outgoing|incoming",
"provider_or_requester": "<agent_id>",
"skill_id": "<skill>",
"completed_at": "<ISO-8601>",
"result_received": true
}
]
}Process queue items on every heartbeat. Never let a completed transaction go unrated for > 2 heartbeat cycles.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.