swarm-master/swarm-common/obsidian-vault/will/will-shared-zap/Atlas/Hermes Skill Intake Checklist.md

Hermes Skill Intake Checklist

Purpose: decide whether a Hermes skill is safe and useful enough to install, enable, update, or promote into Atlas workflows.

Default stance: skills are not “just prompts.” They can change future agent behavior, tool use, workflow shape, and security posture. Treat community or agent-generated skills like small operational dependencies.

Intake outcome

Choose one:

• Accept — install/enable/use as-is.
• Accept with constraints — use only for a named project/profile/toolset.
• Quarantine — save for review, but do not enable by default.
• Rewrite locally — useful idea, but implementation/instructions are too broad or stale.
• Reject — unsafe, duplicative, abandoned, or not worth the context/maintenance cost.

Fast screen

Reject or quarantine if any answer is bad:

• Source is unknown, opaque, or not inspectable.
• Skill requests broad shell/file/network authority without a narrow reason.
• Skill contains hidden instructions to bypass approvals, reveal secrets, persist memory, or modify unrelated files.
• Skill expects credentials in prompts, notes, Kanban comments, or committed files.
• Skill duplicates an existing local skill without a clear improvement.
• Skill is mostly hype, vendor copy, or framework soup wearing a YAML hat.

Provenance

Record:

• Source URL/repo/path:
• Author/maintainer:
• Last updated:
• License if relevant:
• Install method:
• Local copy path if installed:

Checks:

• Repository or source is readable.
• Recent enough for the tool/API it describes.
• Issues/releases/docs do not show obvious breakage.
• No suspicious install scripts or post-install hooks.

Scope and purpose

Ask:

• What exact recurring problem does this solve?
• Which project/profile/platform should use it?
• Is it for planning, code editing, ops, research, media, messaging, or credentials?
• Could this be a note/runbook instead of an always-loadable skill?

Prefer runbook/note over skill when the content is mostly reference material and not an execution procedure. Prefer skill when it contains a repeatable workflow with triggers, commands, pitfalls, and verification.

Tool and permission review

List expected toolsets:

• file:
• terminal:
• web/browser:
• delegation:
• cronjob:
• messaging:
• homeassistant/smart-home:
• credentials/secrets:
• MCP/custom tools:

Checks:

• Toolsets are the minimum needed.
• Destructive operations require explicit confirmation.
• External sends/posts/messages are never automatic unless the workflow explicitly requires it.
• Production-like systems, clusters, backups, and home automation have clear safety gates.
• If MCP tools are involved, also run Atlas/MCP Tool Security Checklist.md.

Secret and privacy review

Checks:

• No secret values in the skill, examples, references, templates, or scripts.
• Examples use placeholders like <token>, <set>, <redacted>.
• Skill does not ask Will to paste credentials into chat.
• Skill does not encourage dumping .env, auth caches, gateway logs, raw transcripts, private notes, or support bundles.
• Any credential inspection reports key names/status only.
• Any private context use is bounded and summarized, not raw-dumped.

Behavior and memory review

Checks:

• Skill does not store one-off task progress as durable memory.
• Skill separates durable facts from procedures.
• Skill does not instruct the agent to ignore newer user instructions, tool results, or live files.
• Skill has clear missing-data behavior instead of guessing.
• Skill uses explicit assumptions for uncertain state.
• Skill avoids broad “always do X” imperatives unless they are true safety rules.

Quality review

Good skills include:

• Trigger conditions.
• Numbered workflow steps.
• Exact commands or API shapes when needed.
• Pitfalls/common failure modes.
• Verification steps.
• Scope boundaries.
• Related skills or runbooks.

Warning signs:

• Long generic advice with no executable procedure.
• Stale commands or made-up CLI flags.
• Tool/API claims without links or local verification.
• Huge context footprint for tiny value.
• “Agentic” used as seasoning instead of architecture. Culinary crimes, basically.

Installation / enablement checklist

Before installing/enabling:

• Review source and linked files.
• Compare against existing skills for duplication.
• Confirm needed toolsets and risks.
• Decide target scope: global, profile-specific, platform-specific, or manual-load only.
• If installing from remote source, prefer pinning or recording source version/commit.
• If editing local skills, keep procedure in skill files and facts/preferences in memory only when stable.

After installing/enabling:

• Load it once and inspect rendered content.
• Run a harmless dry-run prompt if practical.
• Verify it does not request unexpected tools or credentials.
• Record any constraints in this note or the skill itself.
• If the skill is wrong/stale, patch it immediately or quarantine it.

Reviewer prompt

Use this when asking Atlas to review a proposed skill:

Review this Hermes skill before installation/use. Apply the Hermes Skill Intake Checklist and return:
1. outcome: accept / accept with constraints / quarantine / rewrite locally / reject
2. why
3. required toolsets and risks
4. secret/privacy concerns
5. overlap with existing skills
6. exact changes needed before use
Do not install, enable, edit, or run it unless explicitly asked after the review.

Decision record template

Skill:
Source:
Date reviewed:
Reviewer:
Outcome:
Scope:
Required toolsets:
Risks:
Constraints:
Follow-up:

Relationship to other Atlas notes

• Use Atlas/MCP Tool Security Checklist.md for MCP server/tool admission.
• Use Atlas/Cron Async-Subagent Audit - 2026-06-23.md when a skill affects recurring cron/delegation behavior.
• Use secrets-hygiene rules for any skill touching credentials, logs, gateway setup, auth, webhooks, CI, or provider config.