RUNSTR Fitness

Give your AI agent access to your health and fitness data from RUNSTR. Fetches workouts, habits, journal entries, mood, steps, and more from Nostr. Use when the user asks about their workouts, fitness history, health habits, mood tracking, or wants AI fitness coaching based on real data.

This skill appears to do what it says (read and decrypt RUNSTR backups on Nostr), but it requires you to hand over your Nostr private key (nsec). Sharing that key lets anyone act as your Nostr identity (post/sign) and read any encrypted data for that identity. Before installing or using this skill: - Do not paste your primary/personal nsec into a public or third-party chat. Create a dedicated RUNSTR/Nostr identity for fitness backups and use that account's nsec instead. - Prefer decrypting locally yourself (install nak locally and run the commands in a terminal you control) instead of sending the secret to an agent. - If you must use the agent, verify how it handles secrets (will it store logs? are transcripts retained?), ask for explicit ephemeral-input handling, and insist it deletes the secret after use. - Verify the nak repo and consider pinning to a known commit or release rather than installing @latest. Inspect the binary source if possible. - Consider manual review of the decrypted backup before allowing the agent to use it for coaching; redact any content you don't want the agent to see. If you cannot follow these precautions, avoid providing your nsec to the agent.

Type: OpenClaw Skill Name: runstr-fitness Version: 1.0.0 The skill requires the user to provide their highly sensitive Nostr private key (nsec) to the AI agent for decrypting fitness data. While the skill explicitly states the nsec is not stored, logged, or transmitted, and the provided code snippets (using `nak` and a Node.js script in SKILL.md) show it being used locally for decryption, the handling of such a critical credential by an AI agent is a significant security risk. There is no clear evidence of malicious intent like exfiltration or persistence, but the inherent risk of processing a private key warrants a 'suspicious' classification.