Writes, reviews, fixes, validates, and prepares portable Relatr Elo plugins across the full lifecycle from source design to kind 765 publication. Use when the task involves Relatr plugins, Elo plugin authoring, capability-based scoring logic, plugin manifests, `relo` checks/builds/publishing, or explaining how Relatr plugin programs use `plan`, `then`, and `do`.
Writes, reviews, fixes, validates, and prepares portable Relatr Elo plugins across the full lifecycle from source design to kind 765 publication. Use when the task involves Relatr plugins, Elo plugin authoring, capability-based scoring logic, plugin manifests, `relo` checks/builds/publishing, or explaining how Relatr plugin programs use `plan`, `then`, and `do`.
Relatr Elo Plugin Author
Overview
This skill helps an agent produce correct, portable Elo plugins for relatr and guide users through the full plugin lifecycle. The core principle is to treat Relatr plugins as bounded, capability-driven scoring programs: collect data safely, then score it clearly.
When to use
When a user wants to write a new portable Relatr plugin in Elo.
When a user needs help fixing or reviewing an existing Elo plugin.
When a user asks how Relatr-specific plugin programs use plan, then, and do.
When a user needs capability-aware plugin guidance for nostr.query, graph capabilities, or http.nip05_resolve.
When a user wants to validate, build, or publish a plugin using relo or package it as a Nostr kind 765 event.
When an LLM needs project-specific reference material for Elo operators, common functions, nullable handling, and Relatr plugin packaging.
Do NOT use when:
The task is about general Nostr application development unrelated to Relatr plugin authoring.
The task is about changing Relatr runtime internals rather than authoring or reviewing plugin artifacts.
The user only needs generic Elo language education with no Relatr plugin context.
Workflow
1. Classify the request
Identify which of these workflows is needed before producing output:
Author — create a new plugin from a desired scoring signal.
Review — inspect a plugin for correctness, safety, and compatibility.
Debug — fix broken syntax, misuse of do, bad fallbacks, or wrong capability args.
3. Build or assess the plugin with Relatr rules, not generic assumptions
Always enforce these non-negotiable constraints:
A plugin returns a numeric score intended for [0.0, 1.0].
External requests happen only through do.
do may appear only as the full right-hand side of a binding in plan or then rounds.
Capability args must evaluate to strict JSON-shaped values.
Capability results must be treated as nullable and given safe fallbacks.
Relay queries should be narrow and include explicit limit values.
Graph capability argument shapes must match the documented object fields exactly.
If a plugin needs one capability result to compute the next request, split it into another then round instead of nesting requests.
4. Produce lifecycle-aware outputs
Match the output to the user’s likely next step.
For authoring, provide the plugin source plus a brief explanation of the scoring logic.
For review, report concrete issues, why they matter, and a corrected version when possible.
For debugging, explain the failing pattern first, then show the fixed plugin.
For packaging, provide the required tags, event structure, and the relevant relo check, build, or publish commands.
For teaching, explain the minimum relevant Elo and Relatr concepts, then ground them in one plugin example.
5. Finish with verification guidance
Unless the user only asked for a conceptual explanation, end with the minimum concrete verification steps:
structure / logic checks
capability-shape checks
manifest / compatibility checks
relo command sequence when applicable
Prefer concise checklists over long prose.
Checklist
Classified the request as author, review, debug, package/publish, or explain.
Consulted the smallest relevant reference files before writing advice.
Enforced Relatr plugin constraints around rounds, do, JSON args, and nullable results.
Verified capability names and argument shapes against the documented Relatr catalog.
Included packaging and validation steps when the task extends beyond raw .elo source.
Delivered output in a form the user can immediately use: plugin source, review notes, manifest, commands, or explanation.
Examples
Example:
Input: user asks for a plugin that scores recent note activity for a target pubkey and wants something publishable later.
Write a Relatr Elo plugin that scores users based on recent notes from the last 7 days. Keep it simple and safe, and tell me how I would publish it later.
Output: a bounded activity plugin plus minimal lifecycle guidance.
plan
notes = do 'nostr.query' {
kinds: [1],
authors: [_.targetPubkey],
since: _.now - 604800,
limit: 50
}
in
let
events = notes | [],
n = length(events)
in
if n >= 30 then 1.0
else if n >= 12 then 0.75
else if n >= 2 then 0.3
else 0.0
Collect first, score second — treat plugin authoring as a bounded data-collection phase followed by a pure scoring phase.
Capabilities are host-provided — a plugin may request only what Relatr exposes, and must never assume arbitrary runtime powers.
Null is normal — capability failures, missing fields, and absent context are expected; robust plugins always define fallbacks.
Keep plugins focused — one understandable signal is better than a monolithic trust algorithm hidden inside one plugin.
Lifecycle completeness matters — a good answer covers not only the source program, but also validation, packaging, compatibility, and publication when the user needs them.
