# 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:

```text
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

```text
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.
