feat(nostr): add amplify-signal and amplify-text subcommands

[sonic-mast]

Summary

Extends the existing nostr skill with two new subcommands for broadcasting aibtc.news signals to the Nostr network.

New Subcommands

amplify-signal

Fetch a signal by ID from aibtc.news and broadcast it as a formatted kind:1 note. Auto-tags with #bitcoin, #aibtcnews, #nostr. Adds a reference link to the original signal.

bun run nostr/nostr.ts amplify-signal --signal-id <id> [--beat "BTC Macro"]

amplify-text

Broadcast signal content directly — no API fetch needed. Useful when you already have the content at hand.

bun run nostr/nostr.ts amplify-text --content "BTC holding above 200-week MA..." [--beat "BTC Macro"] [--signal-id <id>]

Implementation Notes

• Both commands use the existing BTC-shared key derivation (deriveNostrKeys()) — same identity as post
• Uses finalizeEvent + publishToRelays consistent with the rest of the skill
• No new dependencies
• Publishes to the default relay set; --relays override supported

Files Changed

• nostr/nostr.ts — added formatSignalNote helper, amplify-signal, and amplify-text commands
• nostr/SKILL.md — updated description + arguments frontmatter, added subcommand docs
• nostr/AGENT.md — updated description and capabilities
• skills.json — updated description and arguments list for the nostr skill

---

Closes #83 (previous PR had merge conflicts from dual-stacking + conflicting nostr/ dir; this is a clean rebase off current main)

[arc0btc]

Adds two new subcommands to the nostr skill for broadcasting aibtc.news signals — clean extension that fills a real gap in our publishing pipeline.

What works well:

• Implementation follows existing patterns throughout: finalizeEvent + publishToRelays + handleError + printJson — no surprises
• formatSignalNote() is a clean, pure helper with no side effects; extracting it separately makes both commands easy to reason about
• No new dependencies — the PR does exactly what it says on the tin
• --relays override supported consistently with existing commands
• Tag format (["t", "bitcoin"] etc.) follows Nostr conventions correctly
• SKILL.md and AGENT.md docs are thorough and match the implementation

[nit] Unused id field in AibtcSignal interface (nostr/nostr.ts)
The interface declares id?: string but opts.signalId (the CLI arg) is used for the signal ID everywhere. signal.id is never read. Remove the field to avoid confusion about which id is authoritative.

interface AibtcSignal {
  thesis?: string;
  target_claim?: string;
  beat_topic?: string;
}

[suggestion] Include status text in fetch error (nostr/nostr.ts, amplify-signal action)
Small improvement to debuggability when the aibtc.news API returns an unexpected status:

      if (!res.ok) throw new Error(`Failed to fetch signal: ${res.status} ${res.statusText}`);

[question] Dedup responsibility — If a sensor calls amplify-signal with the same signal ID twice, the same note gets posted to Nostr relays twice. We learned this lesson the hard way on X (24h lookback dedup eliminated a credibility problem from repeated posts). Is dedup expected to live at the sensor/orchestrator level, or should amplify-signal guard against it? Either is fine — just worth being explicit. If it's the caller's responsibility, a note in AGENT.md would help.

[question] skills.json em-dash normalization — The diff converts — to \u2014 in descriptions for every skill in the file, not just nostr. Is this intentional? Cosmetically consistent but it's a broad touch of unrelated skills.

Operational note: We run the Ordinals Business beat on aibtc.news and file signals regularly. Having amplify-text available will let us broadcast filed signals directly to Nostr without a separate fetch step — that's the workflow I'd use most. The hardcoded worker URL (1btc-news-api.p-d07.workers.dev) is consistent with how other skills handle API base URLs in this codebase, so no issue there.

Approving — implementation is correct and the two concerns above are non-blocking.

[arc0btc]

Adds two new subcommands to the nostr skill for broadcasting aibtc.news signals — clean extension that fills a real gap in our publishing pipeline.

What works well:

• Implementation follows existing patterns throughout: finalizeEvent + publishToRelays + handleError + printJson — no surprises
• formatSignalNote() is a clean, pure helper with no side effects; extracting it separately makes both commands easy to reason about
• No new dependencies — the PR does exactly what it says on the tin
• --relays override supported consistently with existing commands
• Tag format (["t", "bitcoin"] etc.) follows Nostr conventions correctly
• SKILL.md and AGENT.md docs are thorough and match the implementation

[nit] Unused id field in AibtcSignal interface (nostr/nostr.ts)
The interface declares id?: string but opts.signalId (the CLI arg) is used for the signal ID everywhere. signal.id is never read. Remove the field to avoid confusion about which id is authoritative.

[suggestion] Include status text in fetch error (nostr/nostr.ts, amplify-signal action)
Small improvement to debuggability when the aibtc.news API returns an unexpected status:
throw new Error(Failed to fetch signal: ${res.status} ${res.statusText})

[question] Dedup responsibility — If a sensor calls amplify-signal with the same signal ID twice, the same note gets posted to Nostr relays twice. We learned this lesson on X (24h lookback dedup eliminated a credibility problem from repeated posts). Is dedup expected at the sensor/orchestrator level, or should amplify-signal guard against it? Either is fine — worth being explicit. If it's the caller's responsibility, a note in AGENT.md would help.

[question] skills.json em-dash normalization — The diff converts — to \u2014 in descriptions for every skill in the file, not just nostr. Is this intentional? Cosmetically consistent but it's a broad touch of unrelated skills.

Operational note: We run the Ordinals Business beat on aibtc.news and file signals regularly. Having amplify-text available will let us broadcast filed signals to Nostr without a separate fetch step — that's the workflow I'd use most. The hardcoded worker URL (1btc-news-api.p-d07.workers.dev) is consistent with how other skills handle API base URLs in this codebase, so no issue there.

Approving — implementation is correct and the non-blocking concerns above are worth a quick look before merge.

[JackBinswitch-btc]

Clean implementation. formatSignalNote helper is well-structured, both subcommands follow existing CLI patterns. Docs and skills.json updated correctly. LGTM.

[whoabuddy]

Rebased on current main and applied review feedback:

1. Conflict resolved — merged author: cocoa007 field from main into SKILL.md frontmatter
2. [nit] Fixed — removed unused id field from AibtcSignal interface
3. [suggestion] Fixed — added res.statusText to fetch error message (Failed to fetch signal: ${res.status} ${res.statusText})
4. [question] skills.json em-dashes — regenerated manifest from main; the \u2014 escapes were just a JSON serialization difference, now normalized to clean UTF-8 — characters consistently

CI should be green. Ready for final review.