hermes-nightly-self-check-decisions

Records decisions from nightly self-check findings as executable rules in a Markdown log.

115|9|Updated Aug 5, 2026
One-click install
npx skills add https://github.com/AtlasOmnia/donna-starter --skill hermes-nightly-self-check-decisions-atlasomnia
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: hermes-nightly-self-check-decisions
Source: https://github.com/AtlasOmnia/donna-starter/tree/main/skills/hermes-nightly-self-check-decisions
Command: npx skills add https://github.com/AtlasOmnia/donna-starter --skill hermes-nightly-self-check-decisions-atlasomnia

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Nightly self-checks surface findings, but without a persistent record the same issues get re-litigated every session and fixes are applied inconsistently. This Skill provides a structured decisions log so each finding produces one durable, executable rule. ## Core Features & Use Cases - Structured decision entries: Each finding is logged with an Issue (symptom, source, cause) and a Decision (the rule to apply going forward), dated and appended chronologically. - Executable rules, not notes: Decisions are written as actionable rules a future session can apply directly, with pointers to where config or skill changes live so the next check can verify them. - Safe logging conventions: Credentials, tokens, and private paths are excluded; locations are referenced by role, and recurring findings tighten the check rather than repeating the note. - Use Case: After a nightly self-check flags a config mismatch between two locations, record the decision that one location is canonical so future checks stop flagging it as a conflict. ## Quick Start Record the decision from the latest nightly self-check finding in the decisions log using the standard entry format.

Frequently Asked Questions about hermes-nightly-self-check-decisions

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I record a decision from a nightly self-check finding?

Append one dated entry per finding under Decision history using the format: a heading with date and issue title, an Issue line describing the symptom and cause, and a Decision line stating the rule to apply going forward. Write the decision as an executable rule, not a description of what was done.

What should a self-check decision entry contain?

Each entry contains the date, a short issue title, the Issue (symptom, source, and why it happened), and the Decision (the rule or fix chosen). If the fix lives in config, skills, or process, note where so the next check can verify it.

Can I log file paths or credentials in the decisions log?

No. The log must not contain credentials, tokens, or private paths. Reference locations by role instead, such as "the primary model endpoint" or "the profile config", so the log stays safe to share and persist.

What should I do when the same self-check finding keeps recurring?

Do not just repeat the note. The decision should tighten the check or the underlying rule so the finding class is resolved permanently, and the entry should point to where that change was made.

When should I not use a decisions log for self-check findings?

Skip the log for one-off transient issues that require no lasting rule, such as a temporary network failure. The log is meant for findings that produce a durable behavioral rule or a verifiable config change.