backup — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited backup (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.
This skill turns a MERLIN execution log into a structured triage report in under a minute. The goal is operator-style situational awareness: what happened in this cycle, what's broken, and what to do about it — not exhaustive forensics. The audience is the operator (me) reviewing a cycle on a phone or in a terminal, deciding whether to intervene now, next session, or not at all.
The required input is a path to a log file, OR a pasted log excerpt of at least ~20 lines. If neither is provided, request one — do not attempt triage on conversational descriptions of what happened.
If a file path is given, read the file directly. If the file is very large (>2000 lines), apply the head/tail/keyword-scan strategy described in Judgment guidance rather than refusing.
If the input is clearly not a MERLIN/VIGIL log (no [MERLIN], [ORACLE], [TECHNICIAN], [SHIELD], [RECONCILER], or Master Live Cycle markers in the first 20 lines), drop into Generic Log mode — described in Judgment guidance — rather than forcing the MERLIN taxonomy onto it.
This skill reads logs only. It does not connect to OANDA, restart agents, modify configuration, or take any action on the trading system. Triage only.
A structured report with four sections, in this exact order. The report should be readable end-to-end in under 60 seconds.
(pasted excerpt)A narrative answer to "what happened in this log." Cover:
This is the section that gets read first and sometimes only. Make it count.
Each anomaly is a structured entry. Order anomalies by severity (CRITICAL → WARNING → INFO), then by line number within each severity tier.
### [SEVERITY] Short title
- **Category:** <taxonomy name>
- **Occurrences:** <N> *(only include this line if N > 1)*
- **Lines:** <line numbers or timestamp range>
- **Evidence:**<quoted log line(s), max 3 lines>
- **Explanation:** <1–2 sentences: what this means and why it matters, including any cascading effects>If no anomalies are detected, output: "None detected. Clean run." Do not manufacture problems.
Anomaly taxonomy (use these exact category names):
Group repeated identical events into a single entry with Occurrences: <N>. Do not emit three separate entries for Missing XAI_API_KEY appearing three times in one cycle.
A table, ordered by urgency:
| # | Action | Rationale | Urgency |
|---|--------|-----------|---------|
| 1 | <specific, actionable step> | <why> | Immediate |
| 2 | ... | ... | Next session |
| 3 | ... | ... | Monitor |Urgency tiers:
If no actions are needed: "No action required."
Markdown only. Render the full report inline in the chat — do not write a file unless explicitly asked. The report should render cleanly in both a terminal (via glow, bat, etc.) and in a chat client. Keep code fences small. Do not pad the report with horizontal rules between every section.
On severity calibration. The single most important judgment call is distinguishing cosmetic noise from cascading systemic failure. A missed RSS feed is INFO. A failed Gemini call is CRITICAL because it zeros out Oracle sentiment, which causes Shield to VETO every signal in the cycle, which means the system is "live" but effectively offline. When you see a low-level error, ask: what does this break downstream? If it cascades, escalate the severity.
On silent failures. These are the most dangerous and the easiest to miss. The pattern: a component logs an error, then logs success. Both lines are true on their own and false in combination. Always cross-reference success messages with the lines immediately preceding them. The Oracle has synthesized after Gemini error: HTTP Error 400 is not a healthy line — it's a silent failure with two pieces of evidence.
On grouping. If the same anomaly appears 3+ times in one cycle (e.g., Missing XAI_API_KEY repeated per pair), emit one entry with Occurrences: <N>. If the same anomaly appears across multiple cycles in the log, group by cycle and note the cross-cycle pattern in the explanation — this often promotes the severity (one-time API blip vs. systemic outage).
On clean runs. A log with no anomalies is a real and valid output. Do not manufacture concerns to fill the section. "None detected. Clean run." is the correct output when warranted, and it's actually informative — it tells the operator the cycle is healthy.
On large logs. For files >2000 lines: read the first 500 lines (initial state + first cycle), the last 500 lines (final state + most recent errors), and keyword-scan the middle for: error, fail, traceback, STDERR, VETO, refused, timeout, Missing. Note in the Summary: "Large log (N lines). Full analysis covers first/last 500 lines; middle was keyword-scanned." Never claim comprehensive analysis of a partially-read log.
On truncation. If the last line is incomplete or doesn't end with a newline, note in the Summary: "Log appears truncated at line N." Add a WARNING anomaly with category "Crash / Unhandled Exception" — the logging pipeline itself may be broken, which is the kind of failure that hides every other failure.
On Generic Log mode. When the input has no MERLIN markers, fall back to a reduced taxonomy: API Failure, Missing Configuration, Crash / Unhandled Exception, Connection Drop. Add generic detectors for: build failures (BUILD FAILED, exit codes ≠ 0), test failures (FAILED, failures=N), stack traces (Python Traceback, Java at com.), timeouts, OOM, and permission errors. Use generic recommended actions ("Investigate the stack trace at line N") rather than MERLIN-specific ones ("Restart the Oracle agent"). Note in the header: Mode: Generic (no MERLIN markers detected).
On binary or unrecognizable input. If the file appears binary or has no recognizable log structure in the first 50 lines, do not force a triage. Output: "Input does not appear to be a text log file" or "Unrecognized log format — unable to perform structured triage," with a best-effort keyword scan if any error indicators are found.
This is a condensed version of a real run on a MERLIN execution log containing one Master Cycle and the start of an Hourly Tech Cycle. The full output is in examples/sample-merlin-cycle-triage.md.
Log file: merlin-2026-04-01.log Lines analyzed: 198 Time range: 2026-04-01 12:17:25 UTC → 2026-04-01 16:00:41 UTC Cycles detected: 1 Master, 1 Hourly Tech (partial)
The Master Cycle completed structurally but produced no executable trades — Oracle's Gemini synthesis failed (HTTP 400) and the system continued as if it had succeeded, leaving Oracle sentiment at 0 across all pairs. Shield correctly VETO'd the one LONG signal (USD/CAD, 79.2% confidence) for "lacks fundamental confluence," which is the right behavior given the upstream failure but masks the real issue: Oracle is broken, not the market. One closed position (EUR/GBP CLOSED_LOSS, -$149.97) processed cleanly, but the Discord/Telegram notification crashed with a TypeError.
[ORACLE] Gemini error: HTTP Error 400: Bad Request [ORACLE] Gemini error: HTTP Error 400: Bad Request
[MERLIN] The Oracle has synthesized multi-source intelligence to the blackboard.
[JOURNAL] Oracle deliberation recorded (75 articles, 0 pair verdicts).(Full report continues with WARNING anomalies for the Archivist TypeError and missing Kelly file, INFO anomalies for the Reuters/Calendar/COT data source failures, and a Recommended Actions table. See `examples/sample-merlin-cycle-triage.md`.)
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.