mirror of
https://github.com/affaan-m/everything-claude-code.git
synced 2026-04-03 07:33:31 +08:00
chore: checkpoint hermes-generated ops skills
This commit is contained in:
Affaan Mustafa
@@ -29,6 +29,5 @@
|
||||
],
|
||||
"commands": "../commands",
|
||||
"skills": "../skills",
|
||||
"agents": "../agents",
|
||||
"hooks": "../hooks/hooks.json"
|
||||
"agents": "../agents"
|
||||
}
|
||||
|
||||
@@ -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",
|
||||
|
||||
10
AGENTS.md
10
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
|
||||
|
||||
25
CHANGELOG.md
25
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
|
||||
|
||||
22
README.md
22
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)
|
||||
|
||||
110
docs/HERMES-SETUP.md
Normal file
110
docs/HERMES-SETUP.md
Normal file
@@ -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
|
||||
57
docs/releases/2.0.0-preview/article-outline.md
Normal file
57
docs/releases/2.0.0-preview/article-outline.md
Normal file
@@ -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.
|
||||
37
docs/releases/2.0.0-preview/launch-checklist.md
Normal file
37
docs/releases/2.0.0-preview/launch-checklist.md
Normal file
@@ -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"
|
||||
29
docs/releases/2.0.0-preview/linkedin-post.md
Normal file
29
docs/releases/2.0.0-preview/linkedin-post.md
Normal file
@@ -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.
|
||||
51
docs/releases/2.0.0-preview/release-notes.md
Normal file
51
docs/releases/2.0.0-preview/release-notes.md
Normal file
@@ -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.
|
||||
79
docs/releases/2.0.0-preview/video-shorts.md
Normal file
79
docs/releases/2.0.0-preview/video-shorts.md
Normal file
@@ -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.
|
||||
59
docs/releases/2.0.0-preview/x-thread.md
Normal file
59
docs/releases/2.0.0-preview/x-thread.md
Normal file
@@ -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:
|
||||
<repo-link>
|
||||
|
||||
Hermes x ECC setup:
|
||||
<repo-link>/blob/main/docs/HERMES-SETUP.md
|
||||
@@ -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
|
||||
}
|
||||
],
|
||||
|
||||
@@ -90,7 +90,6 @@
|
||||
"targets": [
|
||||
"claude",
|
||||
"cursor",
|
||||
"antigravity",
|
||||
"codex",
|
||||
"opencode"
|
||||
],
|
||||
@@ -141,7 +140,6 @@
|
||||
"targets": [
|
||||
"claude",
|
||||
"cursor",
|
||||
"antigravity",
|
||||
"codex",
|
||||
"opencode"
|
||||
],
|
||||
|
||||
4
package-lock.json
generated
4
package-lock.json
generated
@@ -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": {
|
||||
|
||||
@@ -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",
|
||||
|
||||
61
scripts/hooks/security-reminder-wrapper.js
Normal file
61
scripts/hooks/security-reminder-wrapper.js
Normal file
@@ -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);
|
||||
});
|
||||
@@ -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
|
||||
|
||||
45
skills/hermes-generated/SKILL.md
Normal file
45
skills/hermes-generated/SKILL.md
Normal file
@@ -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.
|
||||
88
skills/hermes-generated/automation-audit-ops/SKILL.md
Normal file
88
skills/hermes-generated/automation-audit-ops/SKILL.md
Normal file
@@ -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/<job>/...` 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
|
||||
@@ -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
|
||||
|
||||
104
skills/hermes-generated/ecc-tools-cost-audit/SKILL.md
Normal file
104
skills/hermes-generated/ecc-tools-cost-audit/SKILL.md
Normal file
@@ -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
|
||||
@@ -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 <id>` plus `python3 /Users/affoon/.hermes/scripts/email_guard.py can-send --id <id> --account <account> --recipient <recipient> --subject <subject>`
|
||||
- before any send or reply, run `python3 /Users/affoon/.hermes/scripts/email_guard.py history --recipient <recipient> --subject <subject snippet> --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 <id>` plus `python3 $HERMES_HOME/scripts/email_guard.py can-send --id <id> --account <account> --recipient <recipient> --subject <subject>`
|
||||
- before any send or reply, run `python3 $HERMES_HOME/scripts/email_guard.py history --recipient <recipient> --subject <subject snippet> --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 "<sender>" "<recipient>" "<subject>" "<body>" "/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 <account> -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 "<sender>" "<recipient>" "<subject>" "<body>" "/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 <account> -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 <account> -f Sent ...` or the account's actual sent folder
|
||||
|
||||
@@ -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
|
||||
|
||||
@@ -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
|
||||
|
||||
68
skills/hermes-generated/messages-ops/SKILL.md
Normal file
68
skills/hermes-generated/messages-ops/SKILL.md
Normal file
@@ -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 <ID> --limit <N>` 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 <service>` 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
|
||||
80
skills/hermes-generated/subscription-audit-ops/SKILL.md
Normal file
80
skills/hermes-generated/subscription-audit-ops/SKILL.md
Normal file
@@ -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
|
||||
@@ -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
|
||||
|
||||
|
||||
Reference in New Issue
Block a user