From 51966476812bd9f7fecdea26238452debf72cd69 Mon Sep 17 00:00:00 2001 From: Affaan Mustafa Date: Thu, 2 Apr 2026 15:14:20 -0700 Subject: [PATCH] chore: checkpoint hermes-generated ops skills --- .claude-plugin/plugin.json | 3 +- .opencode/package.json | 4 +- AGENTS.md | 10 +- CHANGELOG.md | 25 ++++ README.md | 22 +++- VERSION | 2 +- docs/HERMES-SETUP.md | 110 ++++++++++++++++++ .../releases/2.0.0-preview/article-outline.md | 57 +++++++++ .../2.0.0-preview/launch-checklist.md | 37 ++++++ docs/releases/2.0.0-preview/linkedin-post.md | 29 +++++ docs/releases/2.0.0-preview/release-notes.md | 51 ++++++++ docs/releases/2.0.0-preview/video-shorts.md | 79 +++++++++++++ docs/releases/2.0.0-preview/x-thread.md | 59 ++++++++++ hooks/hooks.json | 2 +- manifests/install-modules.json | 2 - package-lock.json | 4 +- package.json | 4 +- scripts/hooks/security-reminder-wrapper.js | 61 ++++++++++ skills/hermes-generated/README.md | 2 +- skills/hermes-generated/SKILL.md | 45 +++++++ .../automation-audit-ops/SKILL.md | 88 ++++++++++++++ .../content-crosspost-ops/SKILL.md | 13 ++- .../ecc-tools-cost-audit/SKILL.md | 104 +++++++++++++++++ skills/hermes-generated/email-ops/SKILL.md | 10 +- .../finance-billing-ops/SKILL.md | 2 +- .../hermes-generated/knowledge-ops/SKILL.md | 8 +- skills/hermes-generated/messages-ops/SKILL.md | 68 +++++++++++ .../subscription-audit-ops/SKILL.md | 80 +++++++++++++ skills/hermes-generated/terminal-ops/SKILL.md | 22 +++- 29 files changed, 958 insertions(+), 45 deletions(-) create mode 100644 docs/HERMES-SETUP.md create mode 100644 docs/releases/2.0.0-preview/article-outline.md create mode 100644 docs/releases/2.0.0-preview/launch-checklist.md create mode 100644 docs/releases/2.0.0-preview/linkedin-post.md create mode 100644 docs/releases/2.0.0-preview/release-notes.md create mode 100644 docs/releases/2.0.0-preview/video-shorts.md create mode 100644 docs/releases/2.0.0-preview/x-thread.md create mode 100644 scripts/hooks/security-reminder-wrapper.js create mode 100644 skills/hermes-generated/SKILL.md create mode 100644 skills/hermes-generated/automation-audit-ops/SKILL.md create mode 100644 skills/hermes-generated/ecc-tools-cost-audit/SKILL.md create mode 100644 skills/hermes-generated/messages-ops/SKILL.md create mode 100644 skills/hermes-generated/subscription-audit-ops/SKILL.md diff --git a/.claude-plugin/plugin.json b/.claude-plugin/plugin.json index ace31273..2b5ac0ce 100644 --- a/.claude-plugin/plugin.json +++ b/.claude-plugin/plugin.json @@ -29,6 +29,5 @@ ], "commands": "../commands", "skills": "../skills", - "agents": "../agents", - "hooks": "../hooks/hooks.json" + "agents": "../agents" } diff --git a/.opencode/package.json b/.opencode/package.json index 35d124e0..8671db62 100644 --- a/.opencode/package.json +++ b/.opencode/package.json @@ -1,7 +1,7 @@ { "name": "ecc-universal", - "version": "1.9.0", - "description": "Everything Claude Code (ECC) plugin for OpenCode - agents, commands, hooks, and skills", + "version": "2.0.0", + "description": "Everything Claude Code (ECC) 2.0 preview for OpenCode - cross-harness agents, commands, hooks, skills, and operator workflows", "main": "dist/index.js", "types": "dist/index.d.ts", "type": "module", diff --git a/AGENTS.md b/AGENTS.md index cfcd3a8f..fafd2807 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -1,8 +1,8 @@ # Everything Claude Code (ECC) — Agent Instructions -This is a **production-ready AI coding plugin** providing 28 specialized agents, 119 skills, 60 commands, and automated hook workflows for software development. +This is a **production-ready AI coding plugin and harness system** providing 36 specialized agents, 128 skills, 69 commands, and automated hook workflows for software development and operator workflows. -**Version:** 1.9.0 +**Version:** 2.0.0 (preview) ## Core Principles @@ -141,9 +141,9 @@ Troubleshoot failures: check test isolation → verify mocks → fix implementat ## Project Structure ``` -agents/ — 28 specialized subagents -skills/ — 117 workflow skills and domain knowledge -commands/ — 60 slash commands +agents/ — 36 specialized subagents +skills/ — 128 workflow skills and domain knowledge +commands/ — 69 slash commands hooks/ — Trigger-based automations rules/ — Always-follow guidelines (common + per-language) scripts/ — Cross-platform Node.js utilities diff --git a/CHANGELOG.md b/CHANGELOG.md index a4465740..25b2448e 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1,5 +1,30 @@ # Changelog +## 2.0.0 - 2026-04-01 + +### Highlights + +- Public ECC 2.0 preview release surface aligned across root package metadata, docs, and release collateral. +- Hermes is now part of the public ECC story via a sanitized setup guide, generated-skills surface, and operator workflow documentation. +- Launch pack added for same-day rollout: release notes, X thread, LinkedIn post, article outline, launch checklist, and short-form video scripts. +- Repo version drift fixed between `package.json`, `package-lock.json`, `.opencode/package.json`, `AGENTS.md`, and `VERSION`. + +### New Docs + +- `docs/HERMES-SETUP.md` — sanitized public guide for running Hermes with ECC as the operator surface +- `docs/releases/2.0.0-preview/release-notes.md` +- `docs/releases/2.0.0-preview/x-thread.md` +- `docs/releases/2.0.0-preview/linkedin-post.md` +- `docs/releases/2.0.0-preview/video-shorts.md` +- `docs/releases/2.0.0-preview/article-outline.md` +- `docs/releases/2.0.0-preview/launch-checklist.md` + +### Positioning + +- ECC 2.0 is framed as a cross-harness operating system for agentic work, not only a Claude Code plugin. +- Hermes is positioned as the opinionated operator shell sitting on top of ECC skills, MCPs, hooks, crons, and workflow assets. +- The public preview intentionally ships the documented setup and launch assets first; additional private/local integrations can land incrementally. + ## 1.9.0 - 2026-03-20 ### Highlights diff --git a/README.md b/README.md index b1161a5a..499ca7f4 100644 --- a/README.md +++ b/README.md @@ -38,7 +38,9 @@ Not just configs. A complete system: skills, instincts, memory optimization, continuous learning, security scanning, and research-first development. Production-ready agents, hooks, commands, rules, and MCP configurations evolved over 10+ months of intensive daily use building real products. -Works across **Claude Code**, **Codex**, **Cowork**, and other AI agent harnesses. +Works across **Claude Code**, **Codex**, **Cowork**, and other AI agent harnesses, with **Hermes x ECC** now documented as a public preview operator stack. + +**New in ECC 2.0 preview:** [Hermes setup guide](docs/HERMES-SETUP.md) · [release notes](docs/releases/2.0.0-preview/release-notes.md) · [launch pack](docs/releases/2.0.0-preview/launch-checklist.md) --- @@ -84,6 +86,14 @@ This repo is the raw code only. The guides explain everything. ## What's New +### v2.0.0 Preview — Hermes x ECC Operator Stack (Apr 2026) + +- **Hermes x ECC public preview** — ECC now documents a sanitized Hermes operator setup built around ECC skills, MCPs, hooks, crons, and generated workflow packs. +- **Launch-ready release pack** — Added release notes, X thread, LinkedIn draft, article outline, launch checklist, and short-form video scripts for same-day distribution. +- **Cross-harness positioning cleanup** — Public repo metadata now matches the 2.0 direction already reflected in the Claude plugin manifest and internal architecture docs. +- **Version drift fixed** — Root `package.json`, lockfile, `VERSION`, `.opencode/package.json`, and `AGENTS.md` are back in sync. +- **Preview boundary made explicit** — Public docs show the setup surface and workflow map first; private auth, secrets, and local operator state remain intentionally out of repo. + ### v1.9.0 — Selective Install & Language Expansion (Mar 2026) - **Selective install architecture** — Manifest-driven install pipeline with `install-plan.js` and `install-apply.js` for targeted component installation. State store tracks what's installed and enables incremental updates. @@ -212,7 +222,7 @@ For manual install instructions see the README in the `rules/` folder. /plugin list everything-claude-code@everything-claude-code ``` -✨ **That's it!** You now have access to 28 agents, 119 skills, and 60 commands. +✨ **That's it!** You now have access to 36 agents, 128 skills, and 69 commands. --- @@ -1083,9 +1093,9 @@ The configuration is automatically detected from `.opencode/opencode.json`. | Feature | Claude Code | OpenCode | Status | |---------|-------------|----------|--------| -| Agents | ✅ 28 agents | ✅ 12 agents | **Claude Code leads** | -| Commands | ✅ 60 commands | ✅ 31 commands | **Claude Code leads** | -| Skills | ✅ 119 skills | ✅ 37 skills | **Claude Code leads** | +| Agents | ✅ 36 agents | ✅ 12 agents | **Claude Code leads** | +| Commands | ✅ 69 commands | ✅ 31 commands | **Claude Code leads** | +| Skills | ✅ 128 skills | ✅ 37 skills | **Claude Code leads** | | Hooks | ✅ 8 event types | ✅ 11 events | **OpenCode has more!** | | Rules | ✅ 29 rules | ✅ 13 instructions | **Claude Code leads** | | MCP Servers | ✅ 14 servers | ✅ Full | **Full parity** | @@ -1204,7 +1214,7 @@ ECC is the **first plugin to maximize every major AI coding tool**. Here's how e | **Context File** | CLAUDE.md + AGENTS.md | AGENTS.md | AGENTS.md | AGENTS.md | | **Secret Detection** | Hook-based | beforeSubmitPrompt hook | Sandbox-based | Hook-based | | **Auto-Format** | PostToolUse hook | afterFileEdit hook | N/A | file.edited hook | -| **Version** | Plugin | Plugin | Reference config | 1.9.0 | +| **Version** | Plugin | Plugin | Reference config | 2.0.0 preview | **Key architectural decisions:** - **AGENTS.md** at root is the universal cross-tool file (read by all 4 tools) diff --git a/VERSION b/VERSION index 6e8bf73a..227cea21 100644 --- a/VERSION +++ b/VERSION @@ -1 +1 @@ -0.1.0 +2.0.0 diff --git a/docs/HERMES-SETUP.md b/docs/HERMES-SETUP.md new file mode 100644 index 00000000..6184dd69 --- /dev/null +++ b/docs/HERMES-SETUP.md @@ -0,0 +1,110 @@ +# Hermes x ECC Setup + +Hermes is the operator shell. ECC is the reusable system behind it. + +This guide is the public, sanitized version of the Hermes stack used to run content, outreach, research, sales ops, finance checks, and engineering workflows from one terminal-native surface. + +## What Ships Publicly + +- ECC skills, agents, commands, hooks, and MCP configs from this repo +- Hermes-generated workflow skills that are stable enough to reuse +- a documented operator topology for chat, crons, workspace memory, and distribution flows +- launch collateral for sharing the stack publicly + +This guide does **not** include private secrets, live tokens, personal data, or a raw `~/.hermes` export. + +## Architecture + +Use Hermes as the front door and ECC as the reusable workflow substrate. + +```text +Telegram / CLI / TUI + ↓ + Hermes + ↓ + ECC skills + hooks + MCPs + generated workflow packs + ↓ + Google Drive / GitHub / browser automation / research APIs / media tools / finance tools +``` + +## Public Workspace Map + +Use this as the minimal surface to reproduce the setup without leaking private state. + +- `~/.hermes/config.yaml` + - model routing + - MCP server registration + - plugin loading +- `~/.hermes/skills/ecc-imports/` + - ECC skills copied in for Hermes-native use +- `skills/hermes-generated/` + - operator patterns distilled from repeated Hermes sessions +- `~/.hermes/plugins/` + - bridge plugins for hooks, reminders, and workflow-specific tool glue +- `~/.hermes/cron/jobs.json` + - scheduled automation runs with explicit prompts and channels +- `~/.hermes/workspace/` + - business, ops, health, content, and memory artifacts + +## Recommended Capability Stack + +### Core + +- Hermes for chat, cron, orchestration, and workspace state +- ECC for skills, rules, prompts, and cross-harness conventions +- GitHub + Context7 + Exa + Firecrawl + Playwright as the baseline MCP layer + +### Content + +- FFmpeg for local edit and assembly +- Remotion for programmable clips +- fal.ai for image/video generation +- ElevenLabs for voice, cleanup, and audio packaging +- CapCut or VectCutAPI for final social-native polish + +### Business Ops + +- Google Drive as the system of record for docs, sheets, decks, and research dumps +- Stripe for revenue and payment operations +- GitHub for engineering execution +- Telegram and iMessage style channels for urgent nudges and approvals + +## What Still Requires Local Auth + +These stay local and should be configured per operator: + +- Google OAuth token for Drive / Docs / Sheets / Slides +- X / LinkedIn / outbound distribution credentials +- Stripe keys +- browser automation credentials and stealth/proxy settings +- any CRM or project system credentials such as Linear or Apollo +- Apple Health export or ingest path if health automations are enabled + +## Suggested Bring-Up Order + +1. Install ECC and verify the baseline harness setup. +2. Install Hermes and point it at ECC-imported skills. +3. Register the MCP servers you actually use every day. +4. Authenticate Google Drive first, then GitHub, then distribution channels. +5. Start with a small cron surface: readiness check, content accountability, inbox triage, revenue monitor. +6. Only then add heavier personal workflows like health, relationship graphing, or outbound sequencing. + +## Why Hermes x ECC + +This stack is useful when you want: + +- one terminal-native place to run business and engineering operations +- reusable skills instead of one-off prompts +- automation that can nudge, audit, and escalate +- a public repo that shows the system shape without exposing your private operator state + +## Public Preview Scope + +ECC 2.0 preview documents the Hermes surface and ships launch collateral now. + +The remaining private pieces can be layered later: + +- additional sanitized templates +- richer public examples +- more generated workflow packs +- tighter CRM and Google Workspace integrations diff --git a/docs/releases/2.0.0-preview/article-outline.md b/docs/releases/2.0.0-preview/article-outline.md new file mode 100644 index 00000000..514156d6 --- /dev/null +++ b/docs/releases/2.0.0-preview/article-outline.md @@ -0,0 +1,57 @@ +# Article Outline - ECC 2.0 Preview + +## Working Title + +How I Turned ECC Into an Operator System With Hermes + +## Core Argument + +Most people treat AI coding tools like isolated chat products. + +The leverage comes when you treat the harness, workflow surface, and operator stack as a system: + +- reusable skills +- stable hooks +- MCP-backed tools +- cron/accountability loops +- one operator shell tying the pieces together + +## Structure + +### 1. The Problem + +- too many tools +- too much context switching +- too many workflows stuck in personal muscle memory + +### 2. What ECC Already Solved + +- reusable skills +- cross-harness portability +- hook discipline +- verification and security patterns + +### 3. Why Hermes Was the Missing Layer + +- chat + TUI + cron + workspace memory +- business and content ops live next to engineering +- terminal-native operator flow instead of app sprawl + +### 4. What Ships in the Public Preview + +- sanitized Hermes setup guide +- generated workflow skills +- release and distribution collateral +- cross-harness 2.0 positioning + +### 5. What Is Still Private or Still Coming + +- secrets and auth +- personal datasets +- some operator-specific automation packs +- deeper CRM/finance/Google Workspace integrations + +### 6. Closing Point + +The goal is not “use my exact stack.” +The goal is to build an operator system that compounds. diff --git a/docs/releases/2.0.0-preview/launch-checklist.md b/docs/releases/2.0.0-preview/launch-checklist.md new file mode 100644 index 00000000..5d020a67 --- /dev/null +++ b/docs/releases/2.0.0-preview/launch-checklist.md @@ -0,0 +1,37 @@ +# ECC 2.0 Preview Launch Checklist + +## Repo + +- update public version surface +- publish Hermes setup guide +- verify release notes and launch assets are committed +- leave private tokens, personal docs, and raw workspace exports out of repo + +## Content + +- post X thread from `x-thread.md` +- post LinkedIn draft from `linkedin-post.md` +- turn one of the short clips in `video-shorts.md` into a 30-60 second video +- use `article-outline.md` to draft the longer writeup + +## Demo Asset Suggestions + +- terminal view of Hermes + ECC side by side +- Drive playbook -> brief -> post workflow +- cron or readiness artifact showing operator accountability +- one short proof-of-work clip instead of a polished brand reel + +## Call To Action + +- repo link +- Hermes setup doc link +- one sentence on why this is preview and what comes next + +## Preview Messaging + +Use language like: + +- "public preview" +- "sanitized operator stack" +- "shipping the reusable surface first" +- "private/local integrations land later" diff --git a/docs/releases/2.0.0-preview/linkedin-post.md b/docs/releases/2.0.0-preview/linkedin-post.md new file mode 100644 index 00000000..1ee8e85d --- /dev/null +++ b/docs/releases/2.0.0-preview/linkedin-post.md @@ -0,0 +1,29 @@ +# LinkedIn Draft - ECC 2.0 Preview + +ECC 2.0 preview is live. + +This is the first public version of a setup I have been converging toward for a while: one operator stack for engineering, research, content, outreach, and business operations. + +The practical shift is that ECC is no longer framed as only a Claude Code plugin or config bundle. + +It is a cross-harness operating system for agentic work: + +- reusable skills instead of one-off prompts +- hooks and workflow automation instead of manual checklists +- MCP-backed access to research, docs, browser automation, finance, and distribution surfaces +- a Hermes operator shell on top for chat, cron, accountability, and orchestration + +For the public preview I kept the repo honest. + +I did not dump a private workspace into GitHub. I shipped: + +- a sanitized Hermes setup guide +- launch-ready release collateral +- the reusable parts of the workflow surface +- aligned versioning across the public repo + +If you are building with AI coding tools daily, the real leverage is not just prompting better. + +It is reducing surface area, consolidating workflows, and making your operator system measurable and repeatable. + +I will keep adding the remaining pieces incrementally, but this preview is enough to start from. diff --git a/docs/releases/2.0.0-preview/release-notes.md b/docs/releases/2.0.0-preview/release-notes.md new file mode 100644 index 00000000..ebabf874 --- /dev/null +++ b/docs/releases/2.0.0-preview/release-notes.md @@ -0,0 +1,51 @@ +# ECC 2.0 Preview Release Notes + +## Positioning + +ECC 2.0 preview turns the repo into a more explicit cross-harness operating system. + +Claude Code is still a core target. Codex, OpenCode, and Cursor remain first-class. Hermes now joins the public story as the operator shell that can sit on top of ECC. + +## What Changed + +- Public repo metadata now aligns with the 2.0 direction already visible in the plugin manifest and architecture docs. +- Hermes setup is documented as a sanitized, reusable operator stack. +- Hermes-generated skills are now easier to explain as part of ECC's reusable workflow layer. +- Same-day launch collateral is included in-repo so the release can ship without rebuilding the messaging from scratch. + +## Why This Matters + +ECC is no longer just “Claude Code tips in a repo.” + +It is a reusable system for: + +- engineering execution +- research and market intelligence +- outbound and comms operations +- content production and distribution +- operator accountability through hooks, cron jobs, and workflow packs + +## Preview Boundaries + +This is a public preview, not the final form. + +What ships now: + +- cross-harness positioning +- Hermes setup documentation +- launch content pack +- version alignment across root package surfaces + +What can land later: + +- richer sanitized Hermes templates +- more public MCP presets +- deeper CRM and Google Workspace playbooks +- additional operator packs distilled from live usage + +## Suggested Upgrade Motion + +1. Update to the ECC 2.0 public surface. +2. Read the [Hermes setup guide](../../HERMES-SETUP.md). +3. Pick the workflows you want public first: content, research, outreach, or engineering. +4. Use the launch pack in this folder to announce the release without re-drafting everything from scratch. diff --git a/docs/releases/2.0.0-preview/video-shorts.md b/docs/releases/2.0.0-preview/video-shorts.md new file mode 100644 index 00000000..66fad996 --- /dev/null +++ b/docs/releases/2.0.0-preview/video-shorts.md @@ -0,0 +1,79 @@ +# Short-Form Video Scripts - ECC 2.0 Preview + +These are designed for 30-60 second clips. Record directly from the terminal and Hermes UI where possible. + +## Clip 1 - "I Replaced Five Apps With One Operator Stack" + +### Hook + +"I got tired of switching between coding tools, research tabs, notes, and outreach dashboards, so I collapsed it into one operator stack." + +### Beat Outline + +1. Show ECC repo and Hermes side by side. +2. Explain: ECC holds the reusable skills, hooks, and MCP patterns. +3. Explain: Hermes is the operator shell that runs the workflows. +4. Flash examples: + - coding + - research + - content + - cron nudges +5. Close with: "This is ECC 2.0 preview." + +### On-Screen Text + +- "one operator stack" +- "skills + MCPs + automations" +- "Hermes x ECC" + +## Clip 2 - "How I Turn Drive Playbooks Into Content" + +### Hook + +"This is how I turn raw operating docs into posts and videos without starting from a blank page." + +### Beat Outline + +1. Open the Ito playbooks folder. +2. Show Hermes pulling the source material into a working brief. +3. Show ECC release/content docs as the packaging layer. +4. Show output targets: + - X thread + - LinkedIn post + - short clip script +5. Close with: "One source, multiple outputs." + +### On-Screen Text + +- "Drive -> brief -> posts -> clips" +- "no blank page" + +## Clip 3 - "Why Hermes Matters" + +### Hook + +"The point of Hermes is not another chat app. It is operator control." + +### Beat Outline + +1. Show a cron or readiness check artifact. +2. Explain that Hermes can audit, remind, and route work. +3. Show ECC skills and MCP-backed workflows behind the scenes. +4. Explain why terminal-native matters: + - fewer tabs + - better repeatability + - faster execution +5. Close with the preview framing. + +### On-Screen Text + +- "operator control" +- "terminal-native" +- "ECC 2.0 preview" + +## Recording Notes + +- Prefer live typing plus quick jump cuts over long screen recordings. +- Keep each beat under 5 seconds. +- Use captions aggressively. +- End each clip with the repo URL or doc title on screen. diff --git a/docs/releases/2.0.0-preview/x-thread.md b/docs/releases/2.0.0-preview/x-thread.md new file mode 100644 index 00000000..4937a68f --- /dev/null +++ b/docs/releases/2.0.0-preview/x-thread.md @@ -0,0 +1,59 @@ +# X Thread Draft - ECC 2.0 Preview + +1/ ECC 2.0 preview is live. + +This is the first public pass at the setup I actually want to run daily: one operator stack for coding, research, content, outreach, and business ops. + +2/ The shift is simple: + +ECC is no longer just a Claude Code config pack. +It is a cross-harness operating system for agentic work. + +3/ Claude Code, Codex, Cursor, and OpenCode are still in the mix. + +Now Hermes joins the public story as the operator shell on top of ECC skills, MCPs, hooks, and workflow packs. + +4/ I wanted fewer surfaces, not more. + +Less “which app do I open?” +More “one place where the system already knows the workflows.” + +5/ The preview ships a sanitized Hermes setup guide, not a raw private workspace dump. + +That means: +- no secrets +- no personal tokens +- no fake polish +- just the reusable system shape + +6/ I also added release collateral directly in the repo: +- release notes +- launch checklist +- LinkedIn draft +- short-form video scripts + +7/ Why? + +Because half the battle with agent systems is not building them. +It is operationalizing them: +- shipping content +- tracking revenue +- triaging comms +- keeping research and execution in one loop + +8/ If you want the repo: +read the Hermes setup doc first, then lift the parts you need. + +You do not need my exact stack. +You need a system that compounds. + +9/ ECC 2.0 is still preview. + +The public docs ship now. +The rest lands incrementally as the operator surface hardens. + +10/ Repo + docs: + + +Hermes x ECC setup: +/blob/main/docs/HERMES-SETUP.md diff --git a/hooks/hooks.json b/hooks/hooks.json index 537515fe..d579b462 100644 --- a/hooks/hooks.json +++ b/hooks/hooks.json @@ -122,7 +122,7 @@ "hooks": [ { "type": "command", - "command": "python3 \"${CLAUDE_PLUGIN_ROOT}/scripts/hooks/security-reminder.py\"", + "command": "node \"${CLAUDE_PLUGIN_ROOT}/scripts/hooks/run-with-flags.js\" \"pre:security-reminder\" \"scripts/hooks/security-reminder-wrapper.js\" \"standard,strict\"", "timeout": 5 } ], diff --git a/manifests/install-modules.json b/manifests/install-modules.json index 45b8d8a7..9da75a60 100644 --- a/manifests/install-modules.json +++ b/manifests/install-modules.json @@ -90,7 +90,6 @@ "targets": [ "claude", "cursor", - "antigravity", "codex", "opencode" ], @@ -141,7 +140,6 @@ "targets": [ "claude", "cursor", - "antigravity", "codex", "opencode" ], diff --git a/package-lock.json b/package-lock.json index 4ab265da..ee5a48e7 100644 --- a/package-lock.json +++ b/package-lock.json @@ -1,12 +1,12 @@ { "name": "ecc-universal", - "version": "1.9.0", + "version": "2.0.0", "lockfileVersion": 3, "requires": true, "packages": { "": { "name": "ecc-universal", - "version": "1.9.0", + "version": "2.0.0", "hasInstallScript": true, "license": "MIT", "dependencies": { diff --git a/package.json b/package.json index 5e82a1b3..c63e0541 100644 --- a/package.json +++ b/package.json @@ -1,7 +1,7 @@ { "name": "ecc-universal", - "version": "1.9.0", - "description": "Complete collection of battle-tested Claude Code configs — agents, skills, hooks, commands, and rules evolved over 10+ months of intensive daily use by an Anthropic hackathon winner", + "version": "2.0.0", + "description": "Cross-harness AI agent performance system for Claude Code, Codex, OpenCode, Cursor, and Hermes workflows — agents, skills, hooks, commands, and rules evolved through daily production use", "keywords": [ "claude-code", "ai", diff --git a/scripts/hooks/security-reminder-wrapper.js b/scripts/hooks/security-reminder-wrapper.js new file mode 100644 index 00000000..51bd3130 --- /dev/null +++ b/scripts/hooks/security-reminder-wrapper.js @@ -0,0 +1,61 @@ +#!/usr/bin/env node +/** + * Security reminder wrapper for run-with-flags compatibility. + * + * The original hook logic lives in security-reminder.py. This wrapper keeps + * the hook on the approved Node-based execution path while preserving the + * existing Python implementation. + */ + +'use strict'; + +const path = require('path'); +const { spawnSync } = require('child_process'); + +const MAX_STDIN = 1024 * 1024; + +let raw = ''; +process.stdin.setEncoding('utf8'); +process.stdin.on('data', chunk => { + if (raw.length < MAX_STDIN) { + raw += chunk.substring(0, MAX_STDIN - raw.length); + } +}); + +process.stdin.on('end', () => { + const scriptPath = path.join(__dirname, 'security-reminder.py'); + const pythonCandidates = ['python3', 'python']; + let result; + + for (const pythonBin of pythonCandidates) { + result = spawnSync(pythonBin, [scriptPath], { + input: raw, + encoding: 'utf8', + env: process.env, + cwd: process.cwd(), + timeout: 5000, + }); + + if (result.error && result.error.code === 'ENOENT') { + continue; + } + break; + } + + if (!result || (result.error && result.error.code === 'ENOENT')) { + process.stderr.write('[SecurityReminder] python3/python not found. Skipping security reminder hook.\n'); + process.stdout.write(raw); + process.exit(0); + } + + if (result.error) { + process.stderr.write(`[SecurityReminder] Hook failed to run: ${result.error.message}\n`); + process.stdout.write(raw); + process.exit(0); + } + + if (result.stdout) process.stdout.write(result.stdout); + if (result.stderr) process.stderr.write(result.stderr); + + process.exit(Number.isInteger(result.status) ? result.status : 0); +}); diff --git a/skills/hermes-generated/README.md b/skills/hermes-generated/README.md index 36f04ce4..0c053a50 100644 --- a/skills/hermes-generated/README.md +++ b/skills/hermes-generated/README.md @@ -5,5 +5,5 @@ This directory is reserved for skills distilled from Hermes session data, repeat Rules: - keep skills specific and evidence-backed - prefer reusable operational patterns over one-off tasks -- mirror from `~/.hermes/skills/generated/` only after the pattern is stable +- mirror from `$HERMES_HOME/skills/generated/` only after the pattern is stable - do not overwrite unrelated ECC skills diff --git a/skills/hermes-generated/SKILL.md b/skills/hermes-generated/SKILL.md new file mode 100644 index 00000000..748acc66 --- /dev/null +++ b/skills/hermes-generated/SKILL.md @@ -0,0 +1,45 @@ +--- +name: hermes-generated +description: Index skill for Hermes-generated workflow packs. Use when the task clearly belongs to a Hermes-derived operator pattern and you need to choose the right generated subskill before acting. +origin: ECC +--- + +# Hermes Generated + +This skill is the entrypoint for the Hermes-generated skill bucket. + +Use it when the user is operating in a Hermes-style workflow and the task appears to map to one of the generated operator packs in this directory. + +## Purpose + +- route the request to the right Hermes-generated subskill +- avoid inventing a new workflow when a stable Hermes pattern already exists +- keep Hermes-derived operational behavior discoverable in the public ECC surface + +## Available Subskills + +- `automation-audit-ops` +- `content-crosspost-ops` +- `ecc-tools-cost-audit` +- `email-ops` +- `finance-billing-ops` +- `knowledge-ops` +- `messages-ops` +- `research-ops` +- `terminal-ops` + +## Routing Guidance + +Choose the narrowest matching subskill first: + +- content and distribution -> `content-crosspost-ops` +- ECC Tools burn, PR recursion, quota bypass, or premium-model leakage -> `ecc-tools-cost-audit` +- inbox, triage, cleanup, and email sequencing -> `email-ops` +- billing, revenue, and payments -> `finance-billing-ops` +- memory and prior-session recovery -> `knowledge-ops` +- Telegram, chat, or messaging triage -> `messages-ops` +- research and source-backed investigation -> `research-ops` +- shell execution and terminal workflows -> `terminal-ops` +- cron, overlap, or automation hygiene -> `automation-audit-ops` + +If no generated subskill fits cleanly, fall back to the closest standard ECC skill instead of forcing a Hermes-specific pattern. diff --git a/skills/hermes-generated/automation-audit-ops/SKILL.md b/skills/hermes-generated/automation-audit-ops/SKILL.md new file mode 100644 index 00000000..602bf5f2 --- /dev/null +++ b/skills/hermes-generated/automation-audit-ops/SKILL.md @@ -0,0 +1,88 @@ +--- +name: automation-audit-ops +description: Evidence-first automation audit workflow for Hermes. Use when auditing cron jobs, tooling, connectors, auth wiring, MCP surfaces, local-system parity, or automation overlap before fixing or pruning anything. +metadata: + hermes: + tags: [generated, automation, cron, tooling, workflow, audit, verification, parity, auth, mcp] +--- + +# Automation Audit Ops + +Use this when the user asks what automations are live, which jobs are broken, where overlap exists, or what tooling and connectors Hermes is actually benefiting from right now. + +## Skill Stack + +Pull these skills into the workflow when relevant: +- `continuous-agent-loop` for multi-step audits that cross cron, tooling, and config surfaces +- `agentic-engineering` for decomposing the audit into verifiable units with a clear done condition +- `terminal-ops` when the audit turns into a concrete local fix or command run +- `research-ops` when local inventory has to be compared against current docs, platform support, or missing-capability claims +- `search-first` before inventing a new helper, wrapper, or inventory path +- `eval-harness` mindset for exact failure signatures, proof paths, and post-fix verification + +## When To Use + +- user asks `what automations do i have set up?` +- user asks to audit cron overlap, redundancy, broken jobs, or job coverage +- user asks which tools, connectors, auth surfaces, MCP servers, or wrappers are actually live +- user asks what is ported from another local agentic system, what is still missing, or what should be wired next +- the task spans both local inventory and a small number of high-impact fixes + +## Workflow + +1. Start from prepared evidence when it exists: + - read the prepared failure summary, request patterns, docs scan, and skill-sync notes before opening raw logs + - if the prepared failure summary says there is no dominant cluster, do not spray-read raw log bundles anyway +2. Inventory the live local surface before theorizing: + - for cron work, inspect `$HERMES_HOME/cron/jobs.json`, the latest relevant `$HERMES_HOME/cron/output//...` files, and matching `$HERMES_HOME/cron/delivery-state/*.json` + - for tooling or connector parity, inspect live config, plugins, helper scripts, wrappers, auth files, and verification logs before claiming something is missing + - when the user names another local system or repo, inspect that live source too before saying Hermes lacks or already has the capability +3. Classify each finding by failure class: + - active broken logic + - auth or provider outage + - stale error that has not rerun yet + - MCP or schema-level infrastructure break + - overlap or redundancy + - missing or unported capability +4. Classify each surfaced integration by live state: + - configured + - authenticated + - recently verified + - stale or broken + - missing +5. Answer inventory questions with proof, not memory: + - group automations by surface such as cron, messaging, content, GitHub, research, billing, or health + - include schedules, current status, and the proof path behind each claim + - for parity audits, separate `already ported`, `available but not wired`, and `missing entirely` + - for overlap audits, end with `keep`, `merge`, `cut`, or `fix next`, plus the evidence path behind each call +6. Freeze audit scope before changing anything: + - if the user asked for an inventory, audit table, comparison, or otherwise kept the task read-only, stay read-only until the user explicitly asks for fixes + - collect evidence with config reads, logs, status files, and non-writing proving steps first + - do not rewrite cron, config, wrappers, or auth surfaces just because a likely fix is visible +7. Fix only the highest-impact proved issues: + - keep the pass bounded to one to three changes + - prefer durable config, instruction, or helper-script fixes over one-off replies + - if the prepared evidence shows a failure happened before a later config change, record that as stale-runtime or stale-status risk instead of rewriting the config blindly +8. Verify after any change: + - rerun the smallest proving step + - regenerate any affected context artifacts + - record exact remaining risks when runtime state is outside the scope of the current pass + +## Pitfalls + +- do not treat `last_status=error` as proof of a current bug if the job has not rerun since recovery +- do not conflate a provider outage or MCP schema error with job-specific prompt logic +- do not claim a tool or connector is live just because a skill references it +- do not treat `present in config` as the same thing as `authenticated` or `recently verified` +- do not say Hermes is missing a capability before comparing the named local system or repo the user pointed at +- do not answer `what automations do i have set up?` from memory without reading the current local inventory +- do not open broad raw log bundles when the prepared summary already says there is no dominant cluster +- do not turn an audit-only inventory pass into config or cron edits unless the user expands scope +- do not fix low-value redundancy before resolving the concrete broken path the user actually asked about + +## Verification + +- each important claim points to a live file, log, config entry, or exact failure signature +- each surfaced integration is labeled `configured`, `authenticated`, `recently verified`, `stale/broken`, or `missing` +- each fix names the proving command, regenerated artifact, or re-read output that confirmed it +- remaining risks clearly distinguish stale status, runtime drift, and unresolved infrastructure blockers diff --git a/skills/hermes-generated/content-crosspost-ops/SKILL.md b/skills/hermes-generated/content-crosspost-ops/SKILL.md index acd10f82..c53bc0ca 100644 --- a/skills/hermes-generated/content-crosspost-ops/SKILL.md +++ b/skills/hermes-generated/content-crosspost-ops/SKILL.md @@ -31,8 +31,8 @@ Pull these imported skills into the workflow when relevant: ## Support Source Of Truth Treat these live sources as authoritative for destination support: -- `/Users/affoon/.hermes/workspace/content/postbridge_publish.py` -- `/Users/affoon/.hermes/workspace/content/crosspost-verification-latest.md` +- `$HERMES_WORKSPACE/content/postbridge_publish.py` +- `$HERMES_WORKSPACE/content/crosspost-verification-latest.md` Examples in this skill are destination patterns, not a promise that every destination is live right now. If a destination has no current wrapper path or no recent verified publish record, report `unverified capability` or `blocked by unsupported capability` until checked. @@ -52,12 +52,13 @@ Do not flatten these into one label. `PostBridge unsupported` can still mean `br - if the user pasted thread requirements, comply with those requirements before drafting 2. If the request depends on platform capability, API support, or quota behavior, verify it before answering. - if the user asks whether PostBridge can handle a destination or format, inspect the real wrapper, configs, or recent publish logs before promising support - - treat `/Users/affoon/.hermes/workspace/content/postbridge_publish.py` plus recent verification records as the source of truth for current support + - treat `$HERMES_WORKSPACE/content/postbridge_publish.py` plus recent verification records as the source of truth for current support - separate the destination question from the transport question, and answer both - if there is no current wrapper path or recent proof, report `unverified capability` before drafting - if PostBridge is unsupported but a browser path exists, say `PostBridge unsupported, browser path available` instead of flattening the whole destination to `unsupported` - if the destination itself is unsupported, say `blocked by unsupported capability` and give the next viable path - if the task started as a support question or `did you do it?`, settle that capability or verification answer before drafting or scheduling other destinations + - if a budget warning is active or there are 3 or fewer tool turns left, stop expanding capability checks, answer from the current wrapper or verification proof first, then use at most one high-confidence proving step 3. Extract one core idea and a few specifics. Split multiple ideas into separate posts. 4. Write native variants instead of reusing the same copy: - X: fast hook, minimal framing @@ -86,9 +87,10 @@ Do not flatten these into one label. `PostBridge unsupported` can still mean `br - capture a returned post ID, URL, API response, or an updated verification log - when the user asks `did you do it?`, answer with the exact status for each platform: posted, queued, drafted, uploaded-only, blocked, or awaiting verification - when the user interrupts with `are you working?`, answer in one sentence with the exact current step or blocker on the explicitly asked destination before more tool use + - if a budget warning is already active, do not make another exploratory call before replying to `did you do it?` or `are you working?` - lead with the explicitly asked destination first, and include the proof or blocker on that destination before mentioning any secondary platform work - if the asked destination is still unresolved, say that first instead of leading with successful side work on other platforms - - record every attempt with `/Users/affoon/.hermes/workspace/content/log_crosspost.py` or `/Users/affoon/.hermes/workspace/content/postbridge_publish.py` + - record every attempt with `$HERMES_WORKSPACE/content/log_crosspost.py` or `$HERMES_WORKSPACE/content/postbridge_publish.py` - if the state is only drafted, uploaded-only, queued, blocked, or pending manual action, report that exact status ## Pitfalls @@ -105,10 +107,11 @@ Do not flatten these into one label. `PostBridge unsupported` can still mean `br - do not hide an unresolved asked destination behind progress on other supported destinations - do not answer `did you do it?` by leading with successful secondary platforms while the explicitly asked destination is still unresolved - do not keep scheduling or verifying secondary destinations after a status interrupt while the explicitly asked destination is still unresolved +- do not keep expanding capability checks after a budget warning when the current wrapper state or verification log already supports a precise status answer - do not ignore the user's preference for screenshots or native media over raw links ## Verification -- `/Users/affoon/.hermes/workspace/content/crosspost-verification-latest.md` reflects the latest attempts +- `$HERMES_WORKSPACE/content/crosspost-verification-latest.md` reflects the latest attempts - each destination has an ID, URL, or explicit failure reason - the copy and media logged match what was actually sent diff --git a/skills/hermes-generated/ecc-tools-cost-audit/SKILL.md b/skills/hermes-generated/ecc-tools-cost-audit/SKILL.md new file mode 100644 index 00000000..29c49a50 --- /dev/null +++ b/skills/hermes-generated/ecc-tools-cost-audit/SKILL.md @@ -0,0 +1,104 @@ +--- +name: ecc-tools-cost-audit +description: Evidence-first ECC Tools burn and billing audit workflow. Use when investigating runaway PR creation, quota bypass, premium-model leakage, or GitHub App cost spikes in the ECC Tools repo. +origin: ECC +--- + +# ECC Tools Cost Audit + +Use this when the user suspects the ECC Tools GitHub App is burning cost, over-creating PRs, bypassing usage limits, or routing free users into premium analysis paths. + +## Skill Stack + +Pull these imported skills into the workflow when relevant: +- `continuous-agent-loop` for scope freezes, recovery gates, and cost-aware tracing when audits are long or failure signatures repeat +- `terminal-ops` for repo-local inspection, narrow edits, and proving commands +- `finance-billing-ops` when customer-impact math has to be separated from repo behavior +- `agentic-engineering` for tracing entrypoints, queue paths, and fix sequencing +- `plankton-code-quality` for safer code changes and rerun behavior +- `eval-harness` mindset for exact root-cause evidence and post-fix verification +- `search-first` before inventing a new helper or abstraction +- `security-review` when auth, secrets, usage gates, or entitlement paths are touched + +## When To Use + +- user says ECC Tools burn rate, PR recursion, over-created PRs, usage-limit bypass, or expensive model routing +- the task is an audit or fix in `$PRIMARY_REPOS_ROOT/ECC/skill-creator-app` +- the answer depends on webhook handlers, queue workers, usage reservation, PR creation logic, or paid-gate enforcement + +## Workflow + +1. Freeze repo scope first: + - use `$PRIMARY_REPOS_ROOT/ECC/skill-creator-app` + - check branch and local diff before changing anything +2. Freeze audit mode before tracing: + - if the user asked for `report only`, `audit only`, `review only`, or explicitly said `do not modify code`, keep the pass read-only until the user changes scope + - gather evidence with reads, searches, git status/diff, and other non-writing proving commands first + - do not patch `src/index.ts`, run generators, install dependencies, or stage changes during an audit-only pass +3. Trace ingress before suggesting fixes: + - inspect webhook entrypoints in `src/index.ts` + - search every `ANALYSIS_QUEUE.send(...)` or equivalent enqueue + - map which triggers share a job type +4. Trace the queue consumer and its side effects: + - inspect `handleAnalysisQueue(...)` or the equivalent worker + - confirm whether queued analysis always ends in PR creation, file writes, or premium model calls +5. Audit PR multiplication: + - inspect PR helpers and branch naming + - check dedupe, branch skip logic, synchronize-event handling, and reuse of existing PRs + - treat app-generated branches such as `ecc-tools/*` or timestamped branches as red-flag evidence paths +6. Audit usage and billing truth: + - inspect rate-limit check and increment paths + - if quota is checked before enqueue but incremented only in the worker, mark it as a real race + - separate overrun risk, customer billing impact, and entitlement truth +7. Audit model routing: + - inspect analyzer `fastMode` or equivalent flags, free-vs-paid tier branching, and actual provider/model calls + - confirm whether free queued work can still hit Anthropic or another premium path when keys exist +8. Audit rerun safety and file updates: + - inspect file update helpers for existing-file `sha` handling or equivalent optimistic concurrency + - if reruns can spend analysis cost and then fail on PR or file creation, mark it as burn-with-broken-output +9. Fix in priority order only if the user asked for code changes: + - stop automatic PR multiplication first + - stop quota bypass second + - stop premium leakage third + - then close rerun/update safety gaps and missing entitlement gates +10. Answer status interrupts before more tracing: + - if the user asks `did you do it?`, `are you working?`, or the session is near the tool budget, reply from the current verified repo state before more searching + - lead with whether root causes are `found`, fixes are `changed locally`, `verified locally`, `pushed`, or still `blocked` + - if the asked burn path is still unresolved, say that before side findings or lower-priority issues +11. Verify with the smallest proving commands: + - rerun only the focused tests or typecheck that cover changed paths + - report `changed locally`, `verified locally`, `pushed`, `deployed`, or `blocked` exactly + +## High-Signal Failure Patterns + +### 1. One queue type for all triggers +If pushes, PR syncs, and manual audits all enqueue the same analyze job and the worker always calls the PR-creation path, analysis equals PR spam. + +### 2. Post-enqueue usage increment +If usage is reserved only inside the worker, concurrent requests can all pass the front-door check and exceed quotas. + +### 3. Free tier on premium model path +If free queued jobs still set `fastMode: false` or equivalent while premium provider keys exist, free users can burn premium spend. + +### 4. App-generated branches re-entering the webhook +If `pull_request.synchronize` or similar runs on `ecc-tools/*` branches, the app can analyze its own output and recurse. + +### 5. Update-without-sha reruns +If generated files are updated without passing the existing file `sha`, reruns can fail after the expensive work already happened. + +## Pitfalls + +- do not start with broad repo wandering, settle webhook -> queue -> worker path first +- do not mix customer billing inference with code-backed product truth +- do not mutate the repo during an audit-only or `do not modify code` pass +- do not claim burn is fixed until the narrow proving command was rerun +- do not push or deploy unless the user asked +- do not ignore existing local changes in the repo, work around them or stop if they conflict +- do not keep tracing lower-priority repo paths after a budget warning or status interrupt when the main root-cause state is already known + +## Verification + +- root causes cite exact file paths and code areas +- fixes are ordered by burn impact, not code neatness +- proving commands are named +- final status distinguishes local change, verification, push, and deployment diff --git a/skills/hermes-generated/email-ops/SKILL.md b/skills/hermes-generated/email-ops/SKILL.md index 2be5e3da..a11cc2c8 100644 --- a/skills/hermes-generated/email-ops/SKILL.md +++ b/skills/hermes-generated/email-ops/SKILL.md @@ -43,17 +43,17 @@ Pull these companion skills into the workflow when relevant: - read the full thread first - choose the sender account that matches the project or recipient - if the user has not explicitly approved the exact outgoing text, draft first and show the final copy before sending - - store approval state with `python3 /Users/affoon/.hermes/scripts/email_guard.py queue ...` - - before any send, require `python3 /Users/affoon/.hermes/scripts/email_guard.py approve --id ` plus `python3 /Users/affoon/.hermes/scripts/email_guard.py can-send --id --account --recipient --subject ` - - before any send or reply, run `python3 /Users/affoon/.hermes/scripts/email_guard.py history --recipient --subject --days 45 --json` to catch prior outbound and accidental repeats + - store approval state with `python3 $HERMES_HOME/scripts/email_guard.py queue ...` + - before any send, require `python3 $HERMES_HOME/scripts/email_guard.py approve --id ` plus `python3 $HERMES_HOME/scripts/email_guard.py can-send --id --account --recipient --subject ` + - before any send or reply, run `python3 $HERMES_HOME/scripts/email_guard.py history --recipient --subject --days 45 --json` to catch prior outbound and accidental repeats - if the exact Himalaya send syntax is uncertain, check `himalaya ... --help` or a checked-in helper path before trying a new subcommand - compose with `himalaya template send` or `himalaya message send` using file-backed content when possible, not ad hoc heredoc or inline Python raw-MIME wrappers - avoid editor-driven flows unless required 5. If the request mentions attachments or images: - resolve the exact absolute file path before broad mailbox searching - keep the task on the local send-and-verify path instead of branching into unrelated web or repo exploration - - if Mail.app fallback is needed, pass the attachment paths after the body: `osascript /Users/affoon/.hermes/scripts/send_mail.applescript "" "" "" "" "/absolute/file1" ...` -6. If the user wants an actual send and Himalaya fails with an IMAP append or save-copy error, a CLI dead end, or a raw-message parser crash, do not immediately resend. First verify whether the message already landed in Sent using the history check or `himalaya envelope list -a -f Sent ...`. If the failure was an invalid command path or a panic before Sent proof exists, report the exact blocked state such as `blocked on invalid himalaya send path` or `blocked on himalaya parser crash` and preserve the draft. Only if there is still no sent copy and the user explicitly approved the send may you fall back to `/Users/affoon/.hermes/scripts/send_mail.applescript`. If the user constrained the method to Himalaya only, report the exact blocked state instead of silently switching tools. + - if Mail.app fallback is needed, pass the attachment paths after the body: `osascript $HERMES_HOME/scripts/send_mail.applescript "" "" "" "" "/absolute/file1" ...` +6. If the user wants an actual send and Himalaya fails with an IMAP append or save-copy error, a CLI dead end, or a raw-message parser crash, do not immediately resend. First verify whether the message already landed in Sent using the history check or `himalaya envelope list -a -f Sent ...`. If the failure was an invalid command path or a panic before Sent proof exists, report the exact blocked state such as `blocked on invalid himalaya send path` or `blocked on himalaya parser crash` and preserve the draft. Only if there is still no sent copy and the user explicitly approved the send may you fall back to `$HERMES_HOME/scripts/send_mail.applescript`. If the user constrained the method to Himalaya only, report the exact blocked state instead of silently switching tools. 7. During long-running mailbox work, keep the loop tight: draft -> approval -> send -> Sent proof. Do the next irreversible step first, and do not branch into unrelated transports or searches while the current blocker is unresolved. If a budget warning says 3 or fewer tool calls remain, stop broad exploration and spend the remaining calls on the highest-confidence execution or verification step, or report exact status and next action. 8. If the user wants sent-mail evidence: - verify via `himalaya envelope list -a -f Sent ...` or the account's actual sent folder diff --git a/skills/hermes-generated/finance-billing-ops/SKILL.md b/skills/hermes-generated/finance-billing-ops/SKILL.md index a1f5a902..64b3defd 100644 --- a/skills/hermes-generated/finance-billing-ops/SKILL.md +++ b/skills/hermes-generated/finance-billing-ops/SKILL.md @@ -29,7 +29,7 @@ Pull these imported skills into the workflow when relevant: 1. Start with the freshest revenue evidence available: - if a live Stripe pull exists, refresh it first - - otherwise read `/Users/affoon/.hermes/workspace/business/stripe-sales.md` and `/Users/affoon/.hermes/workspace/business/financial-status.md` + - otherwise read `$HERMES_WORKSPACE/business/stripe-sales.md` and `$HERMES_WORKSPACE/business/financial-status.md` - always report the snapshot timestamp if the data is not live 2. Normalize the revenue picture before answering: - separate paid sales, failed attempts, successful retries, `$0` invoices, refunds, disputes, and active subscriptions diff --git a/skills/hermes-generated/knowledge-ops/SKILL.md b/skills/hermes-generated/knowledge-ops/SKILL.md index 723867b8..84ed1a79 100644 --- a/skills/hermes-generated/knowledge-ops/SKILL.md +++ b/skills/hermes-generated/knowledge-ops/SKILL.md @@ -31,12 +31,12 @@ Pull these companion skills into the workflow when relevant: - do not waste turns re-reading the same files unless the summary is clearly insufficient 2. Search in a fixed order before saying `not found`, unless the user already named the store: - `mcp_supermemory_recall` with a targeted query - - grep `/Users/affoon/.hermes/workspace/memory/` - - grep `/Users/affoon/.hermes/workspace/` more broadly + - grep `$HERMES_WORKSPACE/memory/` + - grep `$HERMES_WORKSPACE/` more broadly - `session_search` for recent Hermes conversations - - grep `/Users/affoon/GitHub/affaans_knowledge_base/` and `/Users/affoon/.hermes/openclaw-home/hub/workspace/memory/` for historical context + - grep `$KNOWLEDGE_BASE_ROOT/` and `$OPENCLAW_MEMORY_ROOT/` for historical context 3. If the user says the answer is in a specific memory store, pivot there immediately after the initial targeted recall: - - `openclaw memory` means favor `/Users/affoon/GitHub/affaans_knowledge_base/` and `/Users/affoon/.hermes/openclaw-home/hub/workspace/memory/` + - `openclaw memory` means favor `$KNOWLEDGE_BASE_ROOT/` and `$OPENCLAW_MEMORY_ROOT/` - `not in this session` means stop digging through the current thread and move to persistent stores instead of re-reading current-session files 4. Keep the search narrow and evidence-led: - reuse names, dates, channels, account names, or quoted phrases from the user diff --git a/skills/hermes-generated/messages-ops/SKILL.md b/skills/hermes-generated/messages-ops/SKILL.md new file mode 100644 index 00000000..6ca2fe68 --- /dev/null +++ b/skills/hermes-generated/messages-ops/SKILL.md @@ -0,0 +1,68 @@ +--- +name: messages-ops +description: Evidence-first live messaging workflow for Hermes. Use when reading iMessage threads, checking X DMs, pulling recent local MFA codes, or proving which thread or message was actually reviewed. +metadata: + hermes: + tags: [generated, messages, imessage, dm, mfa, workflow, verification] +--- + +# Messages Ops + +Use this when the user wants Hermes to read texts or DMs, recover a recent one-time code, inspect a live thread before replying, or prove which message source was checked. + +## Skill Stack + +Pull these imported skills into the workflow when relevant: +- `continuous-agent-loop` when the task spans source resolution, retrieval, and a follow-up draft or action +- `continuous-learning-v2` when the live message task turns into a cross-session memory or pattern-capture issue +- `search-first` before inventing a new message lookup path or raw database query +- `eval-harness` mindset for exact source attribution and blocked-state reporting + +## When To Use + +- user says `read my messages`, `check texts`, `look in iMessage`, `check DMs`, or similar +- the task depends on a live local Messages thread, an X DM thread, or a recent code delivered to Messages +- the user asks whether Hermes already checked a specific thread, sender, or service +- the prompt mixes live message retrieval with a likely handoff into `email-ops` or `knowledge-ops` + +## Workflow + +1. Resolve the source first: + - iMessage thread + - recent local code in Messages + - X DM or another browser-gated message source + - email or persistent memory handoff +2. For iMessage threads: + - use `imsg chats` when the chat id is unclear + - use `imsg history --chat-id --limit ` for the actual read + - known chat ids can save turns when they match the ask, for example Alejandro=`458` and Haley/Henry=`364` +3. For recent one-time codes from local Messages: + - use `python3 $HERMES_HOME/scripts/messages_recent_codes.py --limit 8 --minutes 20` + - add `--query ` when the sender or brand is known + - do not jump to ad hoc `sqlite3`, `python3 -c`, or other inline database reads before the helper path is tried + - if one focused resend plus one fresh helper check still shows no match, report `blocked on missing MFA code` and stop +4. For X DMs or other browser-gated message sources: + - use the logged-in browser path first + - verify the active account before reading or drafting + - if auth or MFA blocks access, do the focused code-check path once, then report the exact blocker instead of wandering into side work +5. Hand off cleanly when the task is really another workflow: + - use `email-ops` when the dominant task is mailbox triage, folder moves, replies, or Sent proof + - use `knowledge-ops` when the user says `openclaw memory`, `not in this session`, or the prompt already provides loaded context plus a memory-retrieval hint +6. Report exact evidence: + - name the source tool and thread or chat id when possible + - include sender, service, timestamp window, or blocker + - use exact status words such as `read`, `drafted`, `blocked`, or `awaiting verification` + +## Pitfalls + +- do not say `I can't retrieve` when `imsg`, the browser session, or the checked helper script can settle the question +- do not confuse live message retrieval with mailbox work, hand off to `email-ops` when email is the real surface +- do not burn turns on raw database one-liners before the checked helper path for local codes +- do not keep re-reading the current session after the user already pointed to OpenClaw or another persistent store +- do not claim a thread was checked without naming the source tool, thread, or service behind the claim + +## Verification + +- the response names the source store or tool used +- the response includes a thread id, sender, service, or explicit blocker +- MFA/code checks end with either a concrete match or the exact blocked status diff --git a/skills/hermes-generated/subscription-audit-ops/SKILL.md b/skills/hermes-generated/subscription-audit-ops/SKILL.md new file mode 100644 index 00000000..81999973 --- /dev/null +++ b/skills/hermes-generated/subscription-audit-ops/SKILL.md @@ -0,0 +1,80 @@ +--- +name: subscription-audit-ops +description: Evidence-first recurring-charge and subscription audit workflow for Hermes. Use when auditing personal spend across cards, recurring merchants, and cancellation candidates under time or cash pressure. +metadata: + hermes: + tags: [generated, finance, subscriptions, recurring-charges, credit-karma, email, verification] +--- + +# Subscription Audit Ops + +Use this when the user asks to audit subscriptions, recurring charges, monthly software spend, or cancellation candidates across personal cards and accounts. + +## Skill Stack + +Pull these imported skills into the workflow when relevant: +- `continuous-agent-loop` for bounded multi-step audits with explicit stop conditions when proof is partial +- `agentic-engineering` for exact done conditions and the one-to-three-change scope discipline +- `market-research` when the user wants vendor or plan comparisons before canceling +- `deep-research` and `exa-search` when outside pricing, cancellation flows, or market alternatives need current verification +- `search-first` before inventing a custom scraper, parser, or finance helper +- `eval-harness` mindset for proof tiers, timestamps, and exact confidence labels + +## When To Use + +- user says `audit my subscriptions`, `what can i cancel`, `find recurring charges`, or similar +- the user wants a ruthless keep/cancel pass before a move, budget cut, or runway review +- direct card exports are missing and you need to assemble evidence from multiple partial sources + +## Workflow + +1. Start with the freshest finance snapshot available: + - read `/Users/affoon/.hermes/workspace/business/financial-status.md` + - use it as the source of truth for last verified recurring-charge evidence, card balances, and snapshot timestamp + - if it references Credit Karma or other live sources, preserve the exact timestamp in the final answer +2. If live Credit Karma is accessible, use browser tools to confirm: + - net worth page for balances and recent transactions + - manage accounts page for linked institutions and account names + - use `browser_vision` on screenshots when the DOM/snapshot truncates or hides account details + - distinguish `visible recurring charge`, `recent transaction`, and `linked account` clearly +3. If direct transaction exports are unavailable, use fallback evidence layers: + - search prior session logs for saved Credit Karma findings and merchant names + - inspect known finance files in workspace and memory for previous subscription analyses + - use email search for billing/receipt subjects only if it is likely to surface merchant proof + - use a passwords export only as account-existence evidence, never as billing proof +4. Classify findings into proof tiers: + - tier 1: live transaction or current finance snapshot with amount/date + - tier 2: prior saved note with explicit price and service + - tier 3: account-existence evidence only, needs billing verification +5. Build the recommendation set: + - `cancel now` for low-value tools with explicit prior cost evidence or obvious move-related services + - `verify this week` for plausible subscriptions without live billing proof + - `keep for now` for core infra or tools still likely in active use + - call out the biggest unresolved swing item, usually the highest-cost ambiguous plan +6. Report exact confidence: + - say `first-pass audit` if the evidence is partial + - never pretend you have a complete ledger unless you saw a full recurring-charge screen or statement export + - separate `billing proof`, `account evidence`, and `inference` + +## Heuristics That Worked + +- `financial-status.md` may contain the freshest recurring-charge evidence even when live browser access later fails +- prior Apple Notes / knowledge-base subscription analyses are useful for cost baselines, but they are not live proof +- Credit Karma `Manage accounts` can expose linked institutions even when transaction detail is sparse +- passwords export is good for finding likely paid surfaces like gym, utilities, hosting, SaaS, and media, but should never be used to claim a subscription is active +- move-related audits should explicitly check internet, gym, phone, and location-bound services first + +## Pitfalls + +- do not claim `every single subscription` unless you have a current recurring-charge list or statement export +- do not turn passwords-export hits into confirmed charges +- do not mix `recent transaction` with `recurring subscription` +- do not hide stale timestamps +- do not miss the biggest swing item just because it is ambiguous, flag it as the top verification priority + +## Verification + +- answer includes the freshest verified finance timestamp +- each recommendation is labeled by evidence strength +- final output separates `cancel now`, `verify this week`, and `keep for now` +- if coverage is partial, the answer explicitly says so and names the fastest path to full certainty diff --git a/skills/hermes-generated/terminal-ops/SKILL.md b/skills/hermes-generated/terminal-ops/SKILL.md index c32f4bdb..5525a2a0 100644 --- a/skills/hermes-generated/terminal-ops/SKILL.md +++ b/skills/hermes-generated/terminal-ops/SKILL.md @@ -31,34 +31,44 @@ Pull these imported skills into the workflow when relevant: 1. Resolve the exact working surface first: - use the user-provided absolute repo path when given - if the target is not a git repo, do not reach for git-only steps - - prefer `/Users/affoon/GitHub/...` over any iCloud or Documents mirror + - prefer `$PRIMARY_REPOS_ROOT/...` over any iCloud or Documents mirror 2. Inspect before editing: - read the failing command, file, test, or CI error first - check current branch and local state before changing or pushing anything - if the prompt already includes loaded-file markers or a compaction summary, use that evidence instead of re-reading blindly -3. Keep fixes narrow and evidence-led: +3. Freeze execution mode before editing: + - if the user asked for an audit, review, inspection, or explicitly said `do not modify code`, stay read-only until the user changes scope + - use logs, diffs, git state, file reads, and other non-writing proving steps to gather evidence + - do not apply patches, run codegen, install dependencies, format files, or stage/commit while the task is still read-only +4. Keep fixes narrow and evidence-led: - solve one dominant failure at a time - prefer repo-local scripts, package scripts, and checked-in helpers over ad hoc one-liners - if a dependency or helper is needed, use `search-first` before writing custom glue -4. Verify after each meaningful change: +5. Verify after each meaningful change: - rerun the smallest command that proves the fix - escalate to the broader build, lint, or test only after the local failure is addressed - if the same proving command keeps failing with the same signature, freeze the broader loop, reduce scope to the failing unit, and stop repeating the same retry - review the diff before any commit or push -5. Push only when the requested state is real: +6. Answer status interrupts before more terminal work: + - if the user asks `are you working?`, `did you do it?`, or a low-budget warning appears, stop discovery and answer from the current verified state before running more commands + - lead with the explicitly asked repo, branch, or failure state first, especially when the main fix is still unresolved + - use exact words like `changed locally`, `verified locally`, `pushed`, `blocked`, or `awaiting verification` +7. Push only when the requested state is real: - distinguish `changed locally`, `verified locally`, `committed`, and `pushed` - if push is requested, use a non-interactive git flow and report the branch and result -6. Report exact status words: +8. Report exact status words: - drafted, changed locally, verified locally, committed, pushed, blocked, awaiting verification ## Pitfalls - do not guess the failure from memory when logs or tests can settle it -- do not work in `/Users/affoon/Documents/...` clones when `/Users/affoon/GitHub/...` exists +- do not turn an audit-only, review-only, or `do not modify code` request into edits because a fix seems obvious +- do not work in `$DOCUMENTS_ROOT/...` clones when `$PRIMARY_REPOS_ROOT/...` exists - do not use destructive git commands or revert unrelated local work - do not claim `fixed` if the proving command was not rerun - do not claim `pushed` if the change only exists locally - do not keep rerunning broad verification after the same unchanged failure, narrow the loop or report the blocker +- do not keep exploring after a budget warning or status interrupt when the current repo state can already be reported precisely ## Verification