@symerian/symi 2.9.1 → 2.9.3

package/skills/imsg/SKILL.md

@@ -21,6 +21,7 @@ metadata:
           ],
       },
   }
+triggers: [imsg]
 ---
 
 # imsg

package/skills/long-task/SKILL.md

@@ -1,6 +1,7 @@
 ---
 name: long-task
 description: Run long operations (deep scans, brute-forces, big builds, exhaustive enumeration) without hitting the agent-turn timeout. Detaches the command with setsid+nohup and schedules a cron monitor that polls status every 2-3 minutes. Use when a single exec call may exceed 15 minutes (deep nmap `-sS -sV -O` on /24 or larger, full hydra/gobuster/ffuf/masscan sweeps, multi-hour builds).
+triggers: [long-task, long, task]
 ---
 
 # Long-Running Task — detach + cron monitor pattern

package/skills/mcporter/SKILL.md

@@ -20,6 +20,7 @@ metadata:
           ],
       },
   }
+triggers: [mcporter]
 ---
 
 # mcporter

package/skills/model-usage/SKILL.md

@@ -20,6 +20,7 @@ metadata:
           ],
       },
   }
+triggers: [model-usage, model, usage]
 ---
 
 # Model usage

package/skills/nano-banana-pro/SKILL.md

@@ -21,6 +21,7 @@ metadata:
           ],
       },
   }
+triggers: [nano-banana-pro, nano, banana, pro]
 ---
 
 # Nano Banana Pro (Gemini 3 Pro Image)

package/skills/nano-pdf/SKILL.md

@@ -20,6 +20,7 @@ metadata:
           ],
       },
   }
+triggers: [nano-pdf, nano, pdf]
 ---
 
 # nano-pdf

package/skills/notion/SKILL.md

@@ -7,6 +7,7 @@ metadata:
     "symi":
       { "emoji": "📝", "requires": { "env": ["NOTION_API_KEY"] }, "primaryEnv": "NOTION_API_KEY" },
   }
+triggers: [notion]
 ---
 
 # notion

package/skills/obsidian/SKILL.md

@@ -20,6 +20,7 @@ metadata:
           ],
       },
   }
+triggers: [obsidian]
 ---
 
 # Obsidian

package/skills/openai-image-gen/SKILL.md

@@ -21,6 +21,7 @@ metadata:
           ],
       },
   }
+triggers: [openai-image-gen, openai, image, gen]
 ---
 
 # OpenAI Image Gen

package/skills/openai-whisper/SKILL.md

@@ -20,6 +20,7 @@ metadata:
           ],
       },
   }
+triggers: [openai-whisper, openai, whisper]
 ---
 
 # Whisper (CLI)

package/skills/openai-whisper-api/SKILL.md

@@ -11,6 +11,7 @@ metadata:
         "primaryEnv": "OPENAI_API_KEY",
       },
   }
+triggers: [openai-whisper-api, openai, whisper, api]
 ---
 
 # OpenAI Whisper API (curl)

package/skills/openhue/SKILL.md

@@ -20,6 +20,7 @@ metadata:
           ],
       },
   }
+triggers: [openhue]
 ---
 
 # OpenHue CLI

package/skills/oracle/SKILL.md

@@ -20,6 +20,7 @@ metadata:
           ],
       },
   }
+triggers: [oracle]
 ---
 
 # oracle — best use

package/skills/ordercli/SKILL.md

@@ -27,6 +27,7 @@ metadata:
           ],
       },
   }
+triggers: [ordercli]
 ---
 
 # ordercli

package/skills/peekaboo/SKILL.md

@@ -21,6 +21,7 @@ metadata:
           ],
       },
   }
+triggers: [peekaboo]
 ---
 
 # Peekaboo

package/skills/reactions-extensive/SKILL.md

@@ -0,0 +1,30 @@
+---
+name: reactions-extensive
+description: Liberal reaction policy for channels configured in EXTENSIVE reactions mode. React naturally — acknowledge messages with appropriate emojis, express sentiment, react to interesting content or notable events, confirm understanding. React whenever it feels natural.
+triggers: [reactions, react, emoji, extensive-reactions]
+---
+
+# Reactions — EXTENSIVE mode
+
+Reactions are enabled for the current channel in **EXTENSIVE** mode.
+
+## Feel free to react liberally
+
+- **Acknowledge messages** with appropriate emojis when text alone would feel cold or robotic.
+- **Express sentiment and personality** through reactions — humor, agreement, appreciation, surprise.
+- **React to interesting content** — a clever solution, a funny remark, a notable result.
+- **Use reactions to confirm understanding** or agreement when a full text reply would be overkill.
+
+## Cadence
+
+React whenever it **feels natural**. Don't ration them — this channel is configured to expect reactions as part of the conversational fabric.
+
+## Still avoid
+
+- Reacting to your own replies.
+- Reactions that contradict the text you're sending alongside ("👎 sounds great!").
+- A reaction storm (5+ different emojis on the same message). Pick one.
+
+## When in doubt
+
+In EXTENSIVE mode, lean toward reacting rather than not. The user-visible signal is "this agent feels engaged"; flat-affect responses break that.

package/skills/reactions-minimal/SKILL.md

@@ -0,0 +1,31 @@
+---
+name: reactions-minimal
+description: Sparing reaction policy for channels configured in MINIMAL reactions mode. React only when truly relevant — important user requests, genuine sentiment, never routine messages or your own replies. Guideline at most 1 reaction per 5-10 exchanges.
+triggers: [reactions, react, emoji, minimal-reactions]
+---
+
+# Reactions — MINIMAL mode
+
+Reactions are enabled for the current channel in **MINIMAL** mode.
+
+## React ONLY when truly relevant
+
+- **Acknowledge important user requests** or confirmations (a thumbs-up on "yes that's exactly what I wanted" — but only if no text reply is also being sent).
+- **Express genuine sentiment** — humor, appreciation — sparingly. Don't fake it.
+- **Avoid reacting** to:
+  - Routine messages and procedural exchanges.
+  - Your own replies (never).
+  - Every message in a back-and-forth (no reaction storms).
+
+## Cadence
+
+At most **1 reaction per 5-10 exchanges**. If you've reacted recently, default to no reaction.
+
+## Anti-patterns
+
+- 👍 on every user message: noise.
+- 🤔 on a question: meaningless.
+- 🚀 on a successful tool call: nobody asked.
+- A reaction PLUS a verbose reply: the reaction is redundant.
+
+If you're considering whether to react and not sure, don't.

package/skills/safe-edit/SKILL.md

@@ -0,0 +1,51 @@
+---
+name: safe-edit
+description: Best practices for the edit tool plus recovery patterns when oldText doesn't match. Read before editing, use shortest unique snippets, prefer distinctive lines, never skip past a failed match. Loaded JIT when an edit fails or the agent is about to make a non-trivial code change.
+triggers: [edit, oldtext, recovery, match, failed, wrong, snippet, hallucinated]
+---
+
+# Safe Edit — best practices and recovery patterns
+
+The `edit` tool replaces an exact `oldText` snippet with `newText`. When `oldText` doesn't match, the call fails. The runtime guard refuses edits to files you haven't read in this session, but it can't tell whether the text you're replacing actually exists at that location. This skill is the discipline that prevents wasted turns.
+
+## Before any edit
+
+1. **Read the file first.** The runtime read-before-edit guard requires it; the practical reason is that you cannot match text you haven't seen.
+2. **Locate the exact text** in the read output. Copy-paste it directly — do not retype, do not "remember" it.
+3. **Choose the shortest unique snippet** that identifies the location. 1-3 lines is usually right. Pasting whole functions makes match failures harder to diagnose and increases the chance of accidentally matching multiple sites.
+4. **Prefer distinctive content** — function names, unique strings, comments — over generic code (closing braces, blank lines, common keywords). Distinctive snippets fail loudly when wrong; generic snippets silently match the wrong place.
+
+## When an edit fails
+
+If `edit` returns an error like "Could not find the exact text", do NOT:
+
+- Skip to a different file or task.
+- Paraphrase the oldText and retry.
+- Try with whitespace tweaks ("maybe it's tabs not spaces").
+
+Instead:
+
+1. **Re-read the file** with `read`. The file may have changed (another tool wrote to it; auto-formatter ran on save).
+2. **Copy the exact text from the fresh read output** into your retry. Whitespace, indentation, line endings — match precisely.
+3. If the file content has shifted significantly, **update your edit plan** before retrying. Don't bash on the same wrong text.
+
+## When the file content surprises you
+
+If the read output doesn't look like what you expected:
+
+- Check the path is right (relative vs absolute, workspace vs sandbox).
+- Confirm you're in the right session (workspace dir matches your assumption).
+- Look for a recent `write` that may have replaced the file content wholesale.
+
+## Multi-edit workflow
+
+If you need several edits to the same file:
+
+- Make them one at a time, re-reading between non-adjacent edits.
+- For tightly-coupled edits (e.g., adding an import + using the import), do the most-stable edit first (the import, which doesn't depend on later changes).
+- After each successful edit, the file's content has changed — older snippets you saved from an earlier read may no longer match.
+
+## What this skill is not
+
+- **Not a refactoring strategy.** For large structural changes, prefer rewriting the file via `write` or generating an `apply_patch` payload. The edit tool is for surgical replacements, not whole-section rewrites.
+- **Not a substitute for reading.** Even with this skill loaded, you still must `read` first.

package/skills/sag/SKILL.md

@@ -21,6 +21,7 @@ metadata:
           ],
       },
   }
+triggers: [sag]
 ---
 
 # sag

package/skills/session-logs/SKILL.md

@@ -2,6 +2,7 @@
 name: session-logs
 description: Search and analyze your own session logs (older/parent conversations) using jq.
 metadata: { "symi": { "emoji": "📜", "requires": { "bins": ["jq", "rg"] } } }
+triggers: [session-logs, session, logs]
 ---
 
 # session-logs

package/skills/sherpa-onnx-tts/SKILL.md

@@ -55,6 +55,7 @@ metadata:
           ],
       },
   }
+triggers: [sherpa-onnx-tts, sherpa, onnx, tts]
 ---
 
 # sherpa-onnx-tts

package/skills/skill-creator/SKILL.md

@@ -1,6 +1,7 @@
 ---
 name: skill-creator
 description: Create or update AgentSkills. Use when designing, structuring, or packaging skills with scripts, references, and assets.
+triggers: [skill-creator, skill, creator]
 ---
 
 # Skill Creator

package/skills/slack/SKILL.md

@@ -2,6 +2,7 @@
 name: slack
 description: Use when you need to control Slack from Symi via the slack tool, including reacting to messages or pinning/unpinning items in Slack channels or DMs.
 metadata: { "symi": { "emoji": "💬", "requires": { "config": ["channels.slack"] } } }
+triggers: [slack]
 ---
 
 # Slack Actions

package/skills/songsee/SKILL.md

@@ -20,6 +20,7 @@ metadata:
           ],
       },
   }
+triggers: [songsee]
 ---
 
 # songsee

package/skills/sonoscli/SKILL.md

@@ -20,6 +20,7 @@ metadata:
           ],
       },
   }
+triggers: [sonoscli]
 ---
 
 # Sonos CLI

package/skills/spotify-player/SKILL.md

@@ -28,6 +28,7 @@ metadata:
           ],
       },
   }
+triggers: [spotify-player, spotify, player]
 ---
 
 # spogo / spotify_player

package/skills/summarize/SKILL.md

@@ -20,6 +20,7 @@ metadata:
           ],
       },
   }
+triggers: [summarize]
 ---
 
 # Summarize

package/skills/symihub/SKILL.md

@@ -18,6 +18,7 @@ metadata:
           ],
       },
   }
+triggers: [symihub]
 ---
 
 # SymiHub CLI

package/skills/things-mac/SKILL.md

@@ -21,6 +21,7 @@ metadata:
           ],
       },
   }
+triggers: [things-mac, things, mac]
 ---
 
 # Things 3 CLI

package/skills/tmux/SKILL.md

@@ -2,6 +2,7 @@
 name: tmux
 description: Remote-control tmux sessions for interactive CLIs by sending keystrokes and scraping pane output.
 metadata: { "symi": { "emoji": "🧵", "os": ["darwin", "linux"], "requires": { "bins": ["tmux"] } } }
+triggers: [tmux]
 ---
 
 # tmux Session Control

package/skills/tool-narration/SKILL.md

@@ -0,0 +1,40 @@
+---
+name: tool-narration
+description: When and how to narrate tool calls. Default to silence on routine, low-risk tool calls; narrate only when it adds value (multi-step work, sensitive actions, complex problems, or explicit user request). Keep narration brief and value-dense.
+triggers: [narrate, narration, tool-call, verbose, explain]
+---
+
+# Tool Call Style
+
+**Default: do not narrate routine, low-risk tool calls.** Just call the tool.
+
+Narrate only when it helps:
+
+- **Multi-step work** where the user benefits from knowing the plan or progress.
+- **Complex / challenging problems** where you're making non-obvious choices.
+- **Sensitive actions** (deletions, destructive operations, external sends) — confirm intent before executing.
+- **When the user explicitly asks** what you're doing or why.
+
+Keep narration brief and value-dense. Avoid:
+
+- Repeating obvious steps the user can see in the tool call.
+- "Now I'll read the file" — they can see the read.
+- "Let me think about this" — silence.
+- Restating the user's question back at them.
+
+Use plain human language for narration unless you're in an explicitly technical context (debugging, writing docs, reviewing code). Don't pad with markdown headers, status emojis, or progress bars on simple tasks.
+
+## Anti-patterns
+
+These all happen automatically without narration:
+
+- File reads, greps, finds, ls.
+- Memory searches at the start of an answer (the model is supposed to do this).
+- Single-shot tool calls where the result speaks for itself.
+
+## When narration genuinely helps
+
+- "I'm going to do A, B, then C" — for multi-step plans, before any tool call.
+- "This will delete the file. Confirm to proceed?" — sensitive ops.
+- "Found the issue: X. Fixing now." — between debugging and the fix.
+- "The build is taking longer than expected because Y" — when delays would otherwise look like the agent stalling.

package/skills/trello/SKILL.md

@@ -7,6 +7,7 @@ metadata:
     "symi":
       { "emoji": "📋", "requires": { "bins": ["jq"], "env": ["TRELLO_API_KEY", "TRELLO_TOKEN"] } },
   }
+triggers: [trello]
 ---
 
 # Trello Skill

package/skills/verify-output/SKILL.md

@@ -0,0 +1,47 @@
+---
+name: verify-output
+description: Structured verification pass before delivering code, scripts, configurations, or any technical artifact. Re-read request, check each requirement against output, actually run the code, include tests when asked, self-review, fix silently before responding. Apply on every coding task — skipping verification is the most common cause of incomplete outputs.
+triggers: [verify, verification, test, deliver, ship, check, validate, review, qa, lint, compile]
+---
+
+# Verify Your Work
+
+Apply this skill BEFORE delivering any code, script, configuration, or technical artifact. Skipping verification is the single most common cause of incomplete or broken outputs. Treat as mandatory for every coding task, not optional polish.
+
+## 1. Re-read the request
+
+Before finalizing your response, re-read the user's original message (and any follow-ups) in full. Extract every discrete requirement, constraint, and preference they stated. Write them down internally as a checklist. This catches drift — it's easy to start solving a related-but-different problem mid-task.
+
+## 2. Check each requirement against your output
+
+Walk through your internal checklist point by point. For each requirement, locate the exact lines in your output that satisfy it. If you cannot point to concrete lines that fulfill a requirement, the work is not done — go back and address the gap before responding. Pay special attention to edge cases, error handling, and boundary conditions the user mentioned.
+
+## 3. Run the code
+
+Whenever possible, use `exec` to actually run, compile, lint, or test your code before presenting it. Do not guess whether code works — execute it and observe the result. If the code produces errors, fix them and re-run until it succeeds.
+
+- For scripts: run with representative inputs.
+- For libraries/modules: write and execute a minimal smoke test.
+- For config files: validate syntax (json, yaml, toml parsers).
+
+If execution is genuinely impossible (no runtime, user said don't run), state that you were unable to verify execution and explain why — do not silently skip.
+
+## 4. Include tests when requested
+
+If the user asked for tests, they are a hard requirement — not a nice-to-have. Deliver the tests alongside the implementation, not as an afterthought. Run the tests and confirm they pass before responding. If the user did not explicitly ask for tests but the change is non-trivial, consider whether a test would catch a regression and offer one.
+
+## 5. Self-review
+
+After everything above, use `read` to re-read any files you created or modified. Look with fresh eyes as if reviewing someone else's code. Check for:
+
+- typos, missing imports, unused variables
+- inconsistent naming
+- hardcoded values that should be configurable
+- incomplete error handling
+- security issues (exposed secrets, injection vectors, missing input validation)
+
+If you find problems during self-review, fix them, re-run verification, and only then respond.
+
+## Verification failures
+
+If any step above reveals a gap, do NOT respond with a partial answer and a disclaimer. Instead, fix the issue silently and re-verify. The user should receive working, complete output — not a draft with known issues. Only flag genuinely unresolvable ambiguities (where you need the user's decision to proceed).

package/skills/video-frames/SKILL.md

@@ -20,6 +20,7 @@ metadata:
           ],
       },
   }
+triggers: [video-frames, video, frames]
 ---
 
 # Video Frames (ffmpeg)

package/skills/voice-call/SKILL.md

@@ -10,6 +10,7 @@ metadata:
         "requires": { "config": ["plugins.entries.voice-call.enabled"] },
       },
   }
+triggers: [voice-call, voice, call]
 ---
 
 # Voice Call

package/skills/wacli/SKILL.md

@@ -27,6 +27,7 @@ metadata:
           ],
       },
   }
+triggers: [wacli]
 ---
 
 # wacli

package/skills/weather/SKILL.md

@@ -3,6 +3,7 @@ name: weather
 description: "Get current weather and forecasts via wttr.in or Open-Meteo. Use when: user asks about weather, temperature, or forecasts for any location. NOT for: historical weather data, severe weather alerts, or detailed meteorological analysis. No API key needed."
 homepage: https://wttr.in/:help
 metadata: { "symi": { "emoji": "🌤️", "requires": { "bins": ["curl"] } } }
+triggers: [weather]
 ---
 
 # Weather Skill

package/skills/xurl/SKILL.md

@@ -26,6 +26,7 @@ metadata:
           ],
       },
   }
+triggers: [xurl]
 ---
 
 # xurl — Agent Skill Reference