mirror of
https://github.com/NousResearch/hermes-agent.git
synced 2026-05-20 05:01:30 +00:00
Cross-checked 75 docs pages under user-guide/messaging/, developer-guide/,
guides/, and integrations/ against the live registries and gateway code.
messaging/
- index.md: API Server toolset is hermes-api-server (was 'hermes (default)');
Google Chat slug is hermes-google_chat (underscore — plugin name uses _).
- google_chat.md: drop bogus 'pip install hermes-agent[google_chat]' (no such
extra); list the actual deps (google-cloud-pubsub, google-api-python-client,
google-auth, google-auth-oauthlib).
- qqbot.md: config namespace is platforms.qqbot (was platforms.qq, which is
silently ignored by the adapter); QQ_STT_BASE_URL is not read directly —
baseUrl lives under platforms.qqbot.extra.stt.
- teams-meetings.md: 'hermes teams-pipeline' is plugin-gated (teams_pipeline
plugin must be enabled), not a built-in subcommand.
- sms.md: example log line 0.0.0.0:8080 -> 127.0.0.1:8080 (default
SMS_WEBHOOK_HOST).
- open-webui.md: API_SERVER_* are env vars, not YAML keys — write them to
per-profile .env, not 'hermes config set' (same pattern fixed in
api-server.md last round). Also bumped example ports to 8650+ to dodge the
default webhook (8644)/wecom-callback (8645)/msgraph-webhook (8646)
collision.
developer-guide/
- architecture.md: tool/toolset counts (61/52 -> 70+/~28); LOC stamps for
run_agent.py, cli.py, hermes_cli/main.py, setup.py, mcp_tool.py,
gateway/run.py replaced with 'large file' to stop drifting.
- agent-loop.md: same LOC drift (~13,700 -> 'a large file (15k+ lines)').
- gateway-internals.md: '14+ external messaging platforms' -> '20+'; gateway
platform tree updated (qqbot is a sub-package, not qqbot.py; added
yuanbao.py, feishu_comment.py, msgraph_webhook.py); 'gateway/builtin_hooks/
(always active)' was wrong — it's an empty extension point and
_register_builtin_hooks() is a no-op stub.
- acp-internals.md: drop fictional 'message_callback' from the bridged-
callbacks list; clarify thinking_callback is currently set to None.
- provider-runtime.md: provider list was missing AWS Bedrock, Azure Foundry,
NVIDIA NIM, xAI, Arcee, GMI Cloud, StepFun, Qwen OAuth, Xiaomi, Ollama
Cloud, LM Studio, Tencent TokenHub. Fallback section described only the
legacy single-pair model — corrected to the canonical list-form
fallback_providers chain.
- environments.md: parsers list missing llama4_json and the deepseek_v31
alias; both register via @register_parser.
- browser-supervisor.md: drop reference to scripts/browser_supervisor_e2e.py
which doesn't exist in-repo.
- contributing.md: tinker-atropos is a git submodule — note that
'git submodule update --init' is required if cloning without
--recurse-submodules.
guides/
- operate-teams-meeting-pipeline.md: cron flags were all wrong — schedule is
positional (not --schedule), the script-only flag is --no-agent (not
--script-only), and there's no --command flag. Replaced with a real example
that creates the script under ~/.hermes/scripts/ and uses the actual flags.
Also replaced fictional 'hermes cron show <name>' with 'hermes cron status'.
- automation-templates.md: 'cron create --skills "a,b"' doesn't work —
the flag is --skill (singular, repeatable). Fixed all 5 occurrences via AST
rewrite.
- minimax-oauth.md: 'hermes auth add minimax-oauth --region cn' silently
fails because --region isn't registered on the auth-add argparse spec.
Pointed users at the minimax-cn provider (or MINIMAX_CN_API_KEY env) for
China-region access.
- cron-script-only.md: 'hermes send' is fictional — replaced the comparison-
table mention with a webhook-subscription pointer; also fixed the dead link
to /guides/pipe-script-output (page doesn't exist).
- cron-troubleshooting.md: 'hermes serve' isn't a real subcommand. Pointed
at 'hermes gateway' (foreground) / 'hermes gateway start' (service).
- local-ollama-setup.md: 'agent.api_timeout' is not a config key. The right
knob is the HERMES_API_TIMEOUT env var.
- python-library.md: run_conversation() return dict has only final_response
and messages — task_id is stored on the agent instance, not echoed back.
- use-mcp-with-hermes.md: '--args /c "npx -y …"' wraps the npx command in
one quoted string, so cmd.exe gets a single arg instead of the multi-token
command line it needs. Removed the surrounding quotes — argparse nargs='*'
collects each token correctly.
integrations/
- providers.md: Bedrock guardrail YAML keys were 'id'/'version' (don't exist);
actual keys are guardrail_identifier/guardrail_version (matches DEFAULT_CONFIG
and the run_agent.py reader). GMI default base URL (api.gmi.ai/v1 ->
api.gmi-serving.com/v1) and portal URL (inference.gmi.ai -> www.gmicloud.ai)
refreshed. Fallback section rewritten to lead with the canonical
fallback_providers list form (was leading with the legacy fallback_model
single dict); supported-providers list extended to include azure-foundry,
alibaba-coding-plan, lmstudio.
index.md
- '68 built-in tools' -> '70+'; '15+ platforms' was both inconsistent with
integrations/index.md ('19+') and undercounted — bumped to 20+ and added
Weixin/QQ Bot/Yuanbao/Google Chat to the list.
Validation: 'npm run build' clean (exit 0); broken-link count unchanged at
155 (same as round-1 post-skill-regen baseline). 24 files, +132/-89.
593 lines
19 KiB
Markdown
593 lines
19 KiB
Markdown
---
|
|
sidebar_position: 15
|
|
title: "Automation Templates"
|
|
description: "Ready-to-use automation recipes — scheduled tasks, GitHub event triggers, API webhooks, and multi-skill workflows"
|
|
---
|
|
|
|
# Automation Templates
|
|
|
|
Copy-paste recipes for common automation patterns. Each template uses Hermes's built-in [cron scheduler](/docs/user-guide/features/cron) for time-based triggers and [webhook platform](/docs/user-guide/messaging/webhooks) for event-driven triggers.
|
|
|
|
Every template works with **any model** — not locked to a single provider.
|
|
|
|
:::tip Three Trigger Types
|
|
| Trigger | How | Tool |
|
|
|---------|-----|------|
|
|
| **Schedule** | Runs on a cadence (hourly, nightly, weekly) | `cronjob` tool or `/cron` slash command |
|
|
| **GitHub Event** | Fires on PR opens, pushes, issues, CI results | Webhook platform (`hermes webhook subscribe`) |
|
|
| **API Call** | External service POSTs JSON to your endpoint | Webhook platform (config.yaml routes or `hermes webhook subscribe`) |
|
|
|
|
All three support delivery to Telegram, Discord, Slack, SMS, email, GitHub comments, or local files.
|
|
:::
|
|
|
|
---
|
|
|
|
## Development Workflow
|
|
|
|
### Nightly Backlog Triage
|
|
|
|
Label, prioritize, and summarize new issues every night. Delivers a digest to your team channel.
|
|
|
|
**Trigger:** Schedule (nightly)
|
|
|
|
```bash
|
|
hermes cron create "0 2 * * *" \
|
|
"You are a project manager triaging the NousResearch/hermes-agent GitHub repo.
|
|
|
|
1. Run: gh issue list --repo NousResearch/hermes-agent --state open --json number,title,labels,author,createdAt --limit 30
|
|
2. Identify issues opened in the last 24 hours
|
|
3. For each new issue:
|
|
- Suggest a priority label (P0-critical, P1-high, P2-medium, P3-low)
|
|
- Suggest a category label (bug, feature, docs, security)
|
|
- Write a one-line triage note
|
|
4. Summarize: total open issues, new today, breakdown by priority
|
|
|
|
Format as a clean digest. If no new issues, respond with [SILENT]." \
|
|
--name "Nightly backlog triage" \
|
|
--deliver telegram
|
|
```
|
|
|
|
### Automatic PR Code Review
|
|
|
|
Review every pull request automatically when it's opened. Posts a review comment directly on the PR.
|
|
|
|
**Trigger:** GitHub webhook
|
|
|
|
**Option A — Dynamic subscription (CLI):**
|
|
|
|
```bash
|
|
hermes webhook subscribe github-pr-review \
|
|
--events "pull_request" \
|
|
--prompt "Review this pull request:
|
|
Repository: {repository.full_name}
|
|
PR #{pull_request.number}: {pull_request.title}
|
|
Author: {pull_request.user.login}
|
|
Action: {action}
|
|
Diff URL: {pull_request.diff_url}
|
|
|
|
Fetch the diff with: curl -sL {pull_request.diff_url}
|
|
|
|
Review for:
|
|
- Security issues (injection, auth bypass, secrets in code)
|
|
- Performance concerns (N+1 queries, unbounded loops, memory leaks)
|
|
- Code quality (naming, duplication, error handling)
|
|
- Missing tests for new behavior
|
|
|
|
Post a concise review. If the PR is a trivial docs/typo change, say so briefly." \
|
|
--skill github-code-review \
|
|
--deliver github_comment
|
|
```
|
|
|
|
**Option B — Static route (config.yaml):**
|
|
|
|
```yaml
|
|
platforms:
|
|
webhook:
|
|
enabled: true
|
|
extra:
|
|
port: 8644
|
|
secret: "your-global-secret"
|
|
routes:
|
|
github-pr-review:
|
|
events: ["pull_request"]
|
|
secret: "github-webhook-secret"
|
|
prompt: |
|
|
Review PR #{pull_request.number}: {pull_request.title}
|
|
Repository: {repository.full_name}
|
|
Author: {pull_request.user.login}
|
|
Diff URL: {pull_request.diff_url}
|
|
Review for security, performance, and code quality.
|
|
skills: ["github-code-review"]
|
|
deliver: "github_comment"
|
|
deliver_extra:
|
|
repo: "{repository.full_name}"
|
|
pr_number: "{pull_request.number}"
|
|
```
|
|
|
|
Then in GitHub: **Settings → Webhooks → Add webhook** → Payload URL: `http://your-server:8644/webhooks/github-pr-review`, Content type: `application/json`, Secret: `github-webhook-secret`, Events: **Pull requests**.
|
|
|
|
### Docs Drift Detection
|
|
|
|
Weekly scan of merged PRs to find API changes that need documentation updates.
|
|
|
|
**Trigger:** Schedule (weekly)
|
|
|
|
```bash
|
|
hermes cron create "0 9 * * 1" \
|
|
"Scan the NousResearch/hermes-agent repo for documentation drift.
|
|
|
|
1. Run: gh pr list --repo NousResearch/hermes-agent --state merged --json number,title,files,mergedAt --limit 30
|
|
2. Filter to PRs merged in the last 7 days
|
|
3. For each merged PR, check if it modified:
|
|
- Tool schemas (tools/*.py) — may need docs/reference/tools-reference.md update
|
|
- CLI commands (hermes_cli/commands.py, hermes_cli/main.py) — may need docs/reference/cli-commands.md update
|
|
- Config options (hermes_cli/config.py) — may need docs/user-guide/configuration.md update
|
|
- Environment variables — may need docs/reference/environment-variables.md update
|
|
4. Cross-reference: for each code change, check if the corresponding docs page was also updated in the same PR
|
|
|
|
Report any gaps where code changed but docs didn't. If everything is in sync, respond with [SILENT]." \
|
|
--name "Docs drift detection" \
|
|
--deliver telegram
|
|
```
|
|
|
|
### Dependency Security Audit
|
|
|
|
Daily scan for known vulnerabilities in project dependencies.
|
|
|
|
**Trigger:** Schedule (daily)
|
|
|
|
```bash
|
|
hermes cron create "0 6 * * *" \
|
|
"Run a dependency security audit on the hermes-agent project.
|
|
|
|
1. cd ~/.hermes/hermes-agent && source .venv/bin/activate
|
|
2. Run: pip audit --format json 2>/dev/null || pip audit 2>&1
|
|
3. Run: npm audit --json 2>/dev/null (in website/ directory if it exists)
|
|
4. Check for any CVEs with CVSS score >= 7.0
|
|
|
|
If vulnerabilities found:
|
|
- List each one with package name, version, CVE ID, severity
|
|
- Check if an upgrade is available
|
|
- Note if it's a direct dependency or transitive
|
|
|
|
If no vulnerabilities, respond with [SILENT]." \
|
|
--name "Dependency audit" \
|
|
--deliver telegram
|
|
```
|
|
|
|
---
|
|
|
|
## DevOps & Monitoring
|
|
|
|
### Deploy Verification
|
|
|
|
Trigger smoke tests after every deployment. Your CI/CD pipeline POSTs to the webhook when a deploy completes.
|
|
|
|
**Trigger:** API call (webhook)
|
|
|
|
```bash
|
|
hermes webhook subscribe deploy-verify \
|
|
--events "deployment" \
|
|
--prompt "A deployment just completed:
|
|
Service: {service}
|
|
Environment: {environment}
|
|
Version: {version}
|
|
Deployed by: {deployer}
|
|
|
|
Run these verification steps:
|
|
1. Check if the service is responding: curl -s -o /dev/null -w '%{http_code}' {health_url}
|
|
2. Search recent logs for errors: check the deployment payload for any error indicators
|
|
3. Verify the version matches: curl -s {health_url}/version
|
|
|
|
Report: deployment status (healthy/degraded/failed), response time, any errors found.
|
|
If healthy, keep it brief. If degraded or failed, provide detailed diagnostics." \
|
|
--deliver telegram
|
|
```
|
|
|
|
Your CI/CD pipeline triggers it:
|
|
|
|
```bash
|
|
curl -X POST http://your-server:8644/webhooks/deploy-verify \
|
|
-H "Content-Type: application/json" \
|
|
-H "X-Hub-Signature-256: sha256=$(echo -n '{"service":"api","environment":"prod","version":"2.1.0","deployer":"ci","health_url":"https://api.example.com/health"}' | openssl dgst -sha256 -hmac 'your-secret' | cut -d' ' -f2)" \
|
|
-d '{"service":"api","environment":"prod","version":"2.1.0","deployer":"ci","health_url":"https://api.example.com/health"}'
|
|
```
|
|
|
|
### Alert Triage
|
|
|
|
Correlate monitoring alerts with recent changes to draft a response. Works with Datadog, PagerDuty, Grafana, or any alerting system that can POST JSON.
|
|
|
|
**Trigger:** API call (webhook)
|
|
|
|
```bash
|
|
hermes webhook subscribe alert-triage \
|
|
--prompt "Monitoring alert received:
|
|
Alert: {alert.name}
|
|
Severity: {alert.severity}
|
|
Service: {alert.service}
|
|
Message: {alert.message}
|
|
Timestamp: {alert.timestamp}
|
|
|
|
Investigate:
|
|
1. Search the web for known issues with this error pattern
|
|
2. Check if this correlates with any recent deployments or config changes
|
|
3. Draft a triage summary with:
|
|
- Likely root cause
|
|
- Suggested first response steps
|
|
- Escalation recommendation (P1-P4)
|
|
|
|
Be concise. This goes to the on-call channel." \
|
|
--deliver slack
|
|
```
|
|
|
|
### Uptime Monitor
|
|
|
|
Check endpoints every 30 minutes. Only notify when something is down.
|
|
|
|
**Trigger:** Schedule (every 30 min)
|
|
|
|
```python title="~/.hermes/scripts/check-uptime.py"
|
|
import urllib.request, json, time
|
|
|
|
ENDPOINTS = [
|
|
{"name": "API", "url": "https://api.example.com/health"},
|
|
{"name": "Web", "url": "https://www.example.com"},
|
|
{"name": "Docs", "url": "https://docs.example.com"},
|
|
]
|
|
|
|
results = []
|
|
for ep in ENDPOINTS:
|
|
try:
|
|
start = time.time()
|
|
req = urllib.request.Request(ep["url"], headers={"User-Agent": "Hermes-Monitor/1.0"})
|
|
resp = urllib.request.urlopen(req, timeout=10)
|
|
elapsed = round((time.time() - start) * 1000)
|
|
results.append({"name": ep["name"], "status": resp.getcode(), "ms": elapsed})
|
|
except Exception as e:
|
|
results.append({"name": ep["name"], "status": "DOWN", "error": str(e)})
|
|
|
|
down = [r for r in results if r.get("status") == "DOWN" or (isinstance(r.get("status"), int) and r["status"] >= 500)]
|
|
if down:
|
|
print("OUTAGE DETECTED")
|
|
for r in down:
|
|
print(f" {r['name']}: {r.get('error', f'HTTP {r[\"status\"]}')} ")
|
|
print(f"\nAll results: {json.dumps(results, indent=2)}")
|
|
else:
|
|
print("NO_ISSUES")
|
|
```
|
|
|
|
```bash
|
|
hermes cron create "every 30m" \
|
|
"If the script reports OUTAGE DETECTED, summarize which services are down and suggest likely causes. If NO_ISSUES, respond with [SILENT]." \
|
|
--script ~/.hermes/scripts/check-uptime.py \
|
|
--name "Uptime monitor" \
|
|
--deliver telegram
|
|
```
|
|
|
|
---
|
|
|
|
## Research & Intelligence
|
|
|
|
### Competitive Repository Scout
|
|
|
|
Monitor competitor repos for interesting PRs, features, and architectural decisions.
|
|
|
|
**Trigger:** Schedule (daily)
|
|
|
|
```bash
|
|
hermes cron create "0 8 * * *" \
|
|
"Scout these AI agent repositories for notable activity in the last 24 hours:
|
|
|
|
Repos to check:
|
|
- anthropics/claude-code
|
|
- openai/codex
|
|
- All-Hands-AI/OpenHands
|
|
- Aider-AI/aider
|
|
|
|
For each repo:
|
|
1. gh pr list --repo <repo> --state all --json number,title,author,createdAt,mergedAt --limit 15
|
|
2. gh issue list --repo <repo> --state open --json number,title,labels,createdAt --limit 10
|
|
|
|
Focus on:
|
|
- New features being developed
|
|
- Architectural changes
|
|
- Integration patterns we could learn from
|
|
- Security fixes that might affect us too
|
|
|
|
Skip routine dependency bumps and CI fixes. If nothing notable, respond with [SILENT].
|
|
If there are findings, organize by repo with brief analysis of each item." \
|
|
--skill competitive-pr-scout \
|
|
--name "Competitor scout" \
|
|
--deliver telegram
|
|
```
|
|
|
|
### AI News Digest
|
|
|
|
Weekly roundup of AI/ML developments.
|
|
|
|
**Trigger:** Schedule (weekly)
|
|
|
|
```bash
|
|
hermes cron create "0 9 * * 1" \
|
|
"Generate a weekly AI news digest covering the past 7 days:
|
|
|
|
1. Search the web for major AI announcements, model releases, and research breakthroughs
|
|
2. Search for trending ML repositories on GitHub
|
|
3. Check arXiv for highly-cited papers on language models and agents
|
|
|
|
Structure:
|
|
## Headlines (3-5 major stories)
|
|
## Notable Papers (2-3 papers with one-sentence summaries)
|
|
## Open Source (interesting new repos or major releases)
|
|
## Industry Moves (funding, acquisitions, launches)
|
|
|
|
Keep each item to 1-2 sentences. Include links. Total under 600 words." \
|
|
--name "Weekly AI digest" \
|
|
--deliver telegram
|
|
```
|
|
|
|
### Paper Digest with Notes
|
|
|
|
Daily arXiv scan that saves summaries to your note-taking system.
|
|
|
|
**Trigger:** Schedule (daily)
|
|
|
|
```bash
|
|
hermes cron create "0 8 * * *" \
|
|
"Search arXiv for the 3 most interesting papers on 'language model reasoning' OR 'tool-use agents' from the past day. For each paper, create an Obsidian note with the title, authors, abstract summary, key contribution, and potential relevance to Hermes Agent development." \
|
|
--skill arxiv --skill obsidian \
|
|
--name "Paper digest" \
|
|
--deliver local
|
|
```
|
|
|
|
---
|
|
|
|
## GitHub Event Automations
|
|
|
|
### Issue Auto-Labeling
|
|
|
|
Automatically label and respond to new issues.
|
|
|
|
**Trigger:** GitHub webhook
|
|
|
|
```bash
|
|
hermes webhook subscribe github-issues \
|
|
--events "issues" \
|
|
--prompt "New GitHub issue received:
|
|
Repository: {repository.full_name}
|
|
Issue #{issue.number}: {issue.title}
|
|
Author: {issue.user.login}
|
|
Action: {action}
|
|
Body: {issue.body}
|
|
Labels: {issue.labels}
|
|
|
|
If this is a new issue (action=opened):
|
|
1. Read the issue title and body carefully
|
|
2. Suggest appropriate labels (bug, feature, docs, security, question)
|
|
3. If it's a bug report, check if you can identify the affected component from the description
|
|
4. Post a helpful initial response acknowledging the issue
|
|
|
|
If this is a label or assignment change, respond with [SILENT]." \
|
|
--deliver github_comment
|
|
```
|
|
|
|
### CI Failure Analysis
|
|
|
|
Analyze CI failures and post diagnostics on the PR.
|
|
|
|
**Trigger:** GitHub webhook
|
|
|
|
```yaml
|
|
# config.yaml route
|
|
platforms:
|
|
webhook:
|
|
enabled: true
|
|
extra:
|
|
routes:
|
|
ci-failure:
|
|
events: ["check_run"]
|
|
secret: "ci-secret"
|
|
prompt: |
|
|
CI check failed:
|
|
Repository: {repository.full_name}
|
|
Check: {check_run.name}
|
|
Status: {check_run.conclusion}
|
|
PR: #{check_run.pull_requests.0.number}
|
|
Details URL: {check_run.details_url}
|
|
|
|
If conclusion is "failure":
|
|
1. Fetch the log from the details URL if accessible
|
|
2. Identify the likely cause of failure
|
|
3. Suggest a fix
|
|
If conclusion is "success", respond with [SILENT].
|
|
deliver: "github_comment"
|
|
deliver_extra:
|
|
repo: "{repository.full_name}"
|
|
pr_number: "{check_run.pull_requests.0.number}"
|
|
```
|
|
|
|
### Auto-Port Changes Across Repos
|
|
|
|
When a PR merges in one repo, automatically port the equivalent change to another.
|
|
|
|
**Trigger:** GitHub webhook
|
|
|
|
```bash
|
|
hermes webhook subscribe auto-port \
|
|
--events "pull_request" \
|
|
--prompt "PR merged in the source repository:
|
|
Repository: {repository.full_name}
|
|
PR #{pull_request.number}: {pull_request.title}
|
|
Author: {pull_request.user.login}
|
|
Action: {action}
|
|
Merge commit: {pull_request.merge_commit_sha}
|
|
|
|
If action is 'closed' and pull_request.merged is true:
|
|
1. Fetch the diff: curl -sL {pull_request.diff_url}
|
|
2. Analyze what changed
|
|
3. Determine if this change needs to be ported to the Go SDK equivalent
|
|
4. If yes, create a branch, apply the equivalent changes, and open a PR on the target repo
|
|
5. Reference the original PR in the new PR description
|
|
|
|
If action is not 'closed' or not merged, respond with [SILENT]." \
|
|
--skill github-pr-workflow \
|
|
--deliver log
|
|
```
|
|
|
|
---
|
|
|
|
## Business Operations
|
|
|
|
### Stripe Payment Monitoring
|
|
|
|
Track payment events and get summaries of failures.
|
|
|
|
**Trigger:** API call (webhook)
|
|
|
|
```bash
|
|
hermes webhook subscribe stripe-payments \
|
|
--events "payment_intent.succeeded,payment_intent.payment_failed,charge.dispute.created" \
|
|
--prompt "Stripe event received:
|
|
Event type: {type}
|
|
Amount: {data.object.amount} cents ({data.object.currency})
|
|
Customer: {data.object.customer}
|
|
Status: {data.object.status}
|
|
|
|
For payment_intent.payment_failed:
|
|
- Identify the failure reason from {data.object.last_payment_error}
|
|
- Suggest whether this is a transient issue (retry) or permanent (contact customer)
|
|
|
|
For charge.dispute.created:
|
|
- Flag as urgent
|
|
- Summarize the dispute details
|
|
|
|
For payment_intent.succeeded:
|
|
- Brief confirmation only
|
|
|
|
Keep responses concise for the ops channel." \
|
|
--deliver slack
|
|
```
|
|
|
|
### Daily Revenue Summary
|
|
|
|
Compile key business metrics every morning.
|
|
|
|
**Trigger:** Schedule (daily)
|
|
|
|
```bash
|
|
hermes cron create "0 8 * * *" \
|
|
"Generate a morning business metrics summary.
|
|
|
|
Search the web for:
|
|
1. Current Bitcoin and Ethereum prices
|
|
2. S&P 500 status (pre-market or previous close)
|
|
3. Any major tech/AI industry news from the last 12 hours
|
|
|
|
Format as a brief morning briefing, 3-4 bullet points max.
|
|
Deliver as a clean, scannable message." \
|
|
--name "Morning briefing" \
|
|
--deliver telegram
|
|
```
|
|
|
|
---
|
|
|
|
## Multi-Skill Workflows
|
|
|
|
### Security Audit Pipeline
|
|
|
|
Combine multiple skills for a comprehensive weekly security review.
|
|
|
|
**Trigger:** Schedule (weekly)
|
|
|
|
```bash
|
|
hermes cron create "0 3 * * 0" \
|
|
"Run a comprehensive security audit of the hermes-agent codebase.
|
|
|
|
1. Check for dependency vulnerabilities (pip audit, npm audit)
|
|
2. Search the codebase for common security anti-patterns:
|
|
- Hardcoded secrets or API keys
|
|
- SQL injection vectors (string formatting in queries)
|
|
- Path traversal risks (user input in file paths without validation)
|
|
- Unsafe deserialization (pickle.loads, yaml.load without SafeLoader)
|
|
3. Review recent commits (last 7 days) for security-relevant changes
|
|
4. Check if any new environment variables were added without being documented
|
|
|
|
Write a security report with findings categorized by severity (Critical, High, Medium, Low).
|
|
If nothing found, report a clean bill of health." \
|
|
--skill codebase-security-audit \
|
|
--name "Weekly security audit" \
|
|
--deliver telegram
|
|
```
|
|
|
|
### Content Pipeline
|
|
|
|
Research, draft, and prepare content on a schedule.
|
|
|
|
**Trigger:** Schedule (weekly)
|
|
|
|
```bash
|
|
hermes cron create "0 10 * * 3" \
|
|
"Research and draft a technical blog post outline about a trending topic in AI agents.
|
|
|
|
1. Search the web for the most discussed AI agent topics this week
|
|
2. Pick the most interesting one that's relevant to open-source AI agents
|
|
3. Create an outline with:
|
|
- Hook/intro angle
|
|
- 3-4 key sections
|
|
- Technical depth appropriate for developers
|
|
- Conclusion with actionable takeaway
|
|
4. Save the outline to ~/drafts/blog-$(date +%Y%m%d).md
|
|
|
|
Keep the outline to ~300 words. This is a starting point, not a finished post." \
|
|
--name "Blog outline" \
|
|
--deliver local
|
|
```
|
|
|
|
---
|
|
|
|
## Quick Reference
|
|
|
|
### Cron Schedule Syntax
|
|
|
|
| Expression | Meaning |
|
|
|-----------|---------|
|
|
| `every 30m` | Every 30 minutes |
|
|
| `every 2h` | Every 2 hours |
|
|
| `0 2 * * *` | Daily at 2:00 AM |
|
|
| `0 9 * * 1` | Every Monday at 9:00 AM |
|
|
| `0 9 * * 1-5` | Weekdays at 9:00 AM |
|
|
| `0 3 * * 0` | Every Sunday at 3:00 AM |
|
|
| `0 */6 * * *` | Every 6 hours |
|
|
|
|
### Delivery Targets
|
|
|
|
| Target | Flag | Notes |
|
|
|--------|------|-------|
|
|
| Same chat | `--deliver origin` | Default — delivers to where the job was created |
|
|
| Local file | `--deliver local` | Saves output, no notification |
|
|
| Telegram | `--deliver telegram` | Home channel, or `telegram:CHAT_ID` for specific |
|
|
| Discord | `--deliver discord` | Home channel, or `discord:CHANNEL_ID` |
|
|
| Slack | `--deliver slack` | Home channel |
|
|
| SMS | `--deliver sms:+15551234567` | Direct to phone number |
|
|
| Specific thread | `--deliver telegram:-100123:456` | Telegram forum topic |
|
|
|
|
### Webhook Template Variables
|
|
|
|
| Variable | Description |
|
|
|----------|-------------|
|
|
| `{pull_request.title}` | PR title |
|
|
| `{issue.number}` | Issue number |
|
|
| `{repository.full_name}` | `owner/repo` |
|
|
| `{action}` | Event action (opened, closed, etc.) |
|
|
| `{__raw__}` | Full JSON payload (truncated at 4000 chars) |
|
|
| `{sender.login}` | GitHub user who triggered the event |
|
|
|
|
### The [SILENT] Pattern
|
|
|
|
When a cron job's response contains `[SILENT]`, delivery is suppressed. Use this to avoid notification spam on quiet runs:
|
|
|
|
```
|
|
If nothing noteworthy happened, respond with [SILENT].
|
|
```
|
|
|
|
This means you only get notified when the agent has something to report.
|