feat: restore reusable ops skills from hermes branch

This commit is contained in:
Affaan Mustafa
2026-04-05 13:30:55 -07:00
parent 846ffb75da
commit 6eba30f02b
9 changed files with 440 additions and 11 deletions

View File

@@ -1,6 +1,6 @@
# Everything Claude Code (ECC) — Agent Instructions
This is a **production-ready AI coding plugin** providing 38 specialized agents, 156 skills, 72 commands, and automated hook workflows for software development.
This is a **production-ready AI coding plugin** providing 38 specialized agents, 159 skills, 72 commands, and automated hook workflows for software development.
**Version:** 1.10.0
@@ -146,7 +146,7 @@ Troubleshoot failures: check test isolation → verify mocks → fix implementat
```
agents/ — 38 specialized subagents
skills/ — 156 workflow skills and domain knowledge
skills/ — 159 workflow skills and domain knowledge
commands/ — 72 slash commands
hooks/ — Trigger-based automations
rules/ — Always-follow guidelines (common + per-language)

View File

@@ -236,7 +236,7 @@ For manual install instructions see the README in the `rules/` folder. When copy
/plugin list everything-claude-code@everything-claude-code
```
**That's it!** You now have access to 38 agents, 156 skills, and 72 legacy command shims.
**That's it!** You now have access to 38 agents, 159 skills, and 72 legacy command shims.
### Multi-model commands require additional setup
@@ -1131,7 +1131,7 @@ The configuration is automatically detected from `.opencode/opencode.json`.
|---------|-------------|----------|--------|
| Agents | PASS: 38 agents | PASS: 12 agents | **Claude Code leads** |
| Commands | PASS: 72 commands | PASS: 31 commands | **Claude Code leads** |
| Skills | PASS: 156 skills | PASS: 37 skills | **Claude Code leads** |
| Skills | PASS: 159 skills | PASS: 37 skills | **Claude Code leads** |
| Hooks | PASS: 8 event types | PASS: 11 events | **OpenCode has more!** |
| Rules | PASS: 29 rules | PASS: 13 instructions | **Claude Code leads** |
| MCP Servers | PASS: 14 servers | PASS: Full | **Full parity** |
@@ -1240,7 +1240,7 @@ ECC is the **first plugin to maximize every major AI coding tool**. Here's how e
|---------|------------|------------|-----------|----------|
| **Agents** | 38 | Shared (AGENTS.md) | Shared (AGENTS.md) | 12 |
| **Commands** | 72 | Shared | Instruction-based | 31 |
| **Skills** | 156 | Shared | 10 (native format) | 37 |
| **Skills** | 159 | Shared | 10 (native format) | 37 |
| **Hook Events** | 8 types | 15 types | None yet | 11 types |
| **Hook Scripts** | 20+ scripts | 16 scripts (DRY adapter) | N/A | Plugin hooks |
| **Rules** | 34 (common + lang) | 34 (YAML frontmatter) | Instruction-based | 13 instructions |

View File

@@ -106,7 +106,7 @@ cp -r everything-claude-code/rules/perl ~/.claude/rules/
/plugin list everything-claude-code@everything-claude-code
```
**完成!** 你现在可以使用 38 个代理、156 个技能和 72 个命令。
**完成!** 你现在可以使用 38 个代理、159 个技能和 72 个命令。
### multi-* 命令需要额外配置

View File

@@ -1,6 +1,6 @@
# Everything Claude Code (ECC) — 智能体指令
这是一个**生产就绪的 AI 编码插件**,提供 38 个专业代理、156 项技能、72 条命令以及自动化钩子工作流,用于软件开发。
这是一个**生产就绪的 AI 编码插件**,提供 38 个专业代理、159 项技能、72 条命令以及自动化钩子工作流,用于软件开发。
**版本:** 1.10.0
@@ -147,7 +147,7 @@
```
agents/ — 38 个专业子代理
skills/ — 156 个工作流技能和领域知识
skills/ — 159 个工作流技能和领域知识
commands/ — 72 个斜杠命令
hooks/ — 基于触发的自动化
rules/ — 始终遵循的指导方针(通用 + 每种语言)

View File

@@ -209,7 +209,7 @@ npx ecc-install typescript
/plugin list everything-claude-code@everything-claude-code
```
**搞定!** 你现在可以使用 38 个智能体、156 项技能和 72 个命令了。
**搞定!** 你现在可以使用 38 个智能体、159 项技能和 72 个命令了。
***
@@ -1096,7 +1096,7 @@ opencode
|---------|-------------|----------|--------|
| 智能体 | PASS: 38 个 | PASS: 12 个 | **Claude Code 领先** |
| 命令 | PASS: 72 个 | PASS: 31 个 | **Claude Code 领先** |
| 技能 | PASS: 156 项 | PASS: 37 项 | **Claude Code 领先** |
| 技能 | PASS: 159 项 | PASS: 37 项 | **Claude Code 领先** |
| 钩子 | PASS: 8 种事件类型 | PASS: 11 种事件 | **OpenCode 更多!** |
| 规则 | PASS: 29 条 | PASS: 13 条指令 | **Claude Code 领先** |
| MCP 服务器 | PASS: 14 个 | PASS: 完整 | **完全对等** |
@@ -1208,7 +1208,7 @@ ECC 是**第一个最大化利用每个主要 AI 编码工具的插件**。以
|---------|------------|------------|-----------|----------|
| **智能体** | 38 | 共享 (AGENTS.md) | 共享 (AGENTS.md) | 12 |
| **命令** | 72 | 共享 | 基于指令 | 31 |
| **技能** | 156 | 共享 | 10 (原生格式) | 37 |
| **技能** | 159 | 共享 | 10 (原生格式) | 37 |
| **钩子事件** | 8 种类型 | 15 种类型 | 暂无 | 11 种类型 |
| **钩子脚本** | 20+ 个脚本 | 16 个脚本 (DRY 适配器) | N/A | 插件钩子 |
| **规则** | 34 (通用 + 语言) | 34 (YAML 前页) | 基于指令 | 13 条指令 |

View File

@@ -205,6 +205,7 @@
"skills/continuous-learning-v2",
"skills/e2e-testing",
"skills/eval-harness",
"skills/hookify-rules",
"skills/iterative-retrieval",
"skills/plankton-code-quality",
"skills/project-guidelines-example",
@@ -316,8 +317,10 @@
"paths": [
"skills/connections-optimizer",
"skills/customer-billing-ops",
"skills/github-ops",
"skills/google-workspace-ops",
"skills/jira-integration",
"skills/knowledge-ops",
"skills/project-flow-ops",
"skills/workspace-surface-audit"
],

144
skills/github-ops/SKILL.md Normal file
View File

@@ -0,0 +1,144 @@
---
name: github-ops
description: GitHub repository operations, automation, and management. Issue triage, PR management, CI/CD operations, release management, and security monitoring using the gh CLI. Use when the user wants to manage GitHub issues, PRs, CI status, releases, contributors, stale items, or any GitHub operational task beyond simple git commands.
origin: ECC
---
# GitHub Operations
Manage GitHub repositories with a focus on community health, CI reliability, and contributor experience.
## When to Activate
- Triaging issues (classifying, labeling, responding, deduplicating)
- Managing PRs (review status, CI checks, stale PRs, merge readiness)
- Debugging CI/CD failures
- Preparing releases and changelogs
- Monitoring Dependabot and security alerts
- Managing contributor experience on open-source projects
- User says "check GitHub", "triage issues", "review PRs", "merge", "release", "CI is broken"
## Tool Requirements
- **gh CLI** for all GitHub API operations
- Repository access configured via `gh auth login`
## Issue Triage
Classify each issue by type and priority:
**Types:** bug, feature-request, question, documentation, enhancement, duplicate, invalid, good-first-issue
**Priority:** critical (breaking/security), high (significant impact), medium (nice to have), low (cosmetic)
### Triage Workflow
1. Read the issue title, body, and comments
2. Check if it duplicates an existing issue (search by keywords)
3. Apply appropriate labels via `gh issue edit --add-label`
4. For questions: draft and post a helpful response
5. For bugs needing more info: ask for reproduction steps
6. For good first issues: add `good-first-issue` label
7. For duplicates: comment with link to original, add `duplicate` label
```bash
# Search for potential duplicates
gh issue list --search "keyword" --state all --limit 20
# Add labels
gh issue edit <number> --add-label "bug,high-priority"
# Comment on issue
gh issue comment <number> --body "Thanks for reporting. Could you share reproduction steps?"
```
## PR Management
### Review Checklist
1. Check CI status: `gh pr checks <number>`
2. Check if mergeable: `gh pr view <number> --json mergeable`
3. Check age and last activity
4. Flag PRs >5 days with no review
5. For community PRs: ensure they have tests and follow conventions
### Stale Policy
- Issues with no activity in 14+ days: add `stale` label, comment asking for update
- PRs with no activity in 7+ days: comment asking if still active
- Auto-close stale issues after 30 days with no response (add `closed-stale` label)
```bash
# Find stale issues (no activity in 14+ days)
gh issue list --label "stale" --state open
# Find PRs with no recent activity
gh pr list --json number,title,updatedAt --jq '.[] | select(.updatedAt < "2026-03-01")'
```
## CI/CD Operations
When CI fails:
1. Check the workflow run: `gh run view <run-id> --log-failed`
2. Identify the failing step
3. Check if it is a flaky test vs real failure
4. For real failures: identify the root cause and suggest a fix
5. For flaky tests: note the pattern for future investigation
```bash
# List recent failed runs
gh run list --status failure --limit 10
# View failed run logs
gh run view <run-id> --log-failed
# Re-run a failed workflow
gh run rerun <run-id> --failed
```
## Release Management
When preparing a release:
1. Check all CI is green on main
2. Review unreleased changes: `gh pr list --state merged --base main`
3. Generate changelog from PR titles
4. Create release: `gh release create`
```bash
# List merged PRs since last release
gh pr list --state merged --base main --search "merged:>2026-03-01"
# Create a release
gh release create v1.2.0 --title "v1.2.0" --generate-notes
# Create a pre-release
gh release create v1.3.0-rc1 --prerelease --title "v1.3.0 Release Candidate 1"
```
## Security Monitoring
```bash
# Check Dependabot alerts
gh api repos/{owner}/{repo}/dependabot/alerts --jq '.[].security_advisory.summary'
# Check secret scanning alerts
gh api repos/{owner}/{repo}/secret-scanning/alerts --jq '.[].state'
# Review and auto-merge safe dependency bumps
gh pr list --label "dependencies" --json number,title
```
- Review and auto-merge safe dependency bumps
- Flag any critical/high severity alerts immediately
- Check for new Dependabot alerts weekly at minimum
## Quality Gate
Before completing any GitHub operations task:
- all issues triaged have appropriate labels
- no PRs older than 7 days without a review or comment
- CI failures have been investigated (not just re-run)
- releases include accurate changelogs
- security alerts are acknowledged and tracked

View File

@@ -0,0 +1,128 @@
---
name: hookify-rules
description: This skill should be used when the user asks to create a hookify rule, write a hook rule, configure hookify, add a hookify rule, or needs guidance on hookify rule syntax and patterns.
---
# Writing Hookify Rules
## Overview
Hookify rules are markdown files with YAML frontmatter that define patterns to watch for and messages to show when those patterns match. Rules are stored in `.claude/hookify.{rule-name}.local.md` files.
## Rule File Format
### Basic Structure
```markdown
---
name: rule-identifier
enabled: true
event: bash|file|stop|prompt|all
pattern: regex-pattern-here
---
Message to show Claude when this rule triggers.
Can include markdown formatting, warnings, suggestions, etc.
```
### Frontmatter Fields
| Field | Required | Values | Description |
|-------|----------|--------|-------------|
| name | Yes | kebab-case string | Unique identifier (verb-first: warn-*, block-*, require-*) |
| enabled | Yes | true/false | Toggle without deleting |
| event | Yes | bash/file/stop/prompt/all | Which hook event triggers this |
| action | No | warn/block | warn (default) shows message; block prevents operation |
| pattern | Yes* | regex string | Pattern to match (*or use conditions for complex rules) |
### Advanced Format (Multiple Conditions)
```markdown
---
name: warn-env-api-keys
enabled: true
event: file
conditions:
- field: file_path
operator: regex_match
pattern: \.env$
- field: new_text
operator: contains
pattern: API_KEY
---
You're adding an API key to a .env file. Ensure this file is in .gitignore!
```
**Condition fields by event:**
- bash: `command`
- file: `file_path`, `new_text`, `old_text`, `content`
- prompt: `user_prompt`
**Operators:** `regex_match`, `contains`, `equals`, `not_contains`, `starts_with`, `ends_with`
All conditions must match for rule to trigger.
## Event Type Guide
### bash Events
Match Bash command patterns:
- Dangerous commands: `rm\s+-rf`, `dd\s+if=`, `mkfs`
- Privilege escalation: `sudo\s+`, `su\s+`
- Permission issues: `chmod\s+777`
### file Events
Match Edit/Write/MultiEdit operations:
- Debug code: `console\.log\(`, `debugger`
- Security risks: `eval\(`, `innerHTML\s*=`
- Sensitive files: `\.env$`, `credentials`, `\.pem$`
### stop Events
Completion checks and reminders. Pattern `.*` matches always.
### prompt Events
Match user prompt content for workflow enforcement.
## Pattern Writing Tips
### Regex Basics
- Escape special chars: `.` to `\.`, `(` to `\(`
- `\s` whitespace, `\d` digit, `\w` word char
- `+` one or more, `*` zero or more, `?` optional
- `|` OR operator
### Common Pitfalls
- **Too broad**: `log` matches "login", "dialog" — use `console\.log\(`
- **Too specific**: `rm -rf /tmp` — use `rm\s+-rf`
- **YAML escaping**: Use unquoted patterns; quoted strings need `\\s`
### Testing
```bash
python3 -c "import re; print(re.search(r'your_pattern', 'test text'))"
```
## File Organization
- **Location**: `.claude/` directory in project root
- **Naming**: `.claude/hookify.{descriptive-name}.local.md`
- **Gitignore**: Add `.claude/*.local.md` to `.gitignore`
## Commands
- `/hookify [description]` - Create new rules (auto-analyzes conversation if no args)
- `/hookify-list` - View all rules in table format
- `/hookify-configure` - Toggle rules on/off interactively
- `/hookify-help` - Full documentation
## Quick Reference
Minimum viable rule:
```markdown
---
name: my-rule
enabled: true
event: bash
pattern: dangerous_command
---
Warning message here
```

View File

@@ -0,0 +1,154 @@
---
name: knowledge-ops
description: Knowledge base management, ingestion, sync, and retrieval across multiple storage layers (local files, MCP memory, vector stores, Git repos). Use when the user wants to save, organize, sync, deduplicate, or search across their knowledge systems.
origin: ECC
---
# Knowledge Operations
Manage a multi-layered knowledge system for ingesting, organizing, syncing, and retrieving knowledge across multiple stores.
Prefer the live workspace model:
- code work lives in the real cloned repos
- active execution context lives in GitHub, Linear, and repo-local working-context files
- broader human-facing notes can live in a non-repo context/archive folder
- durable cross-machine memory belongs in the knowledge base, not in a shadow repo workspace
## When to Activate
- User wants to save information to their knowledge base
- Ingesting documents, conversations, or data into structured storage
- Syncing knowledge across systems (local files, MCP memory, Supabase, Git repos)
- Deduplicating or organizing existing knowledge
- User says "save this to KB", "sync knowledge", "what do I know about X", "ingest this", "update the knowledge base"
- Any knowledge management task beyond simple memory recall
## Knowledge Architecture
### Layer 1: Active execution truth
- **Sources:** GitHub issues, PRs, discussions, release notes, Linear issues/projects/docs
- **Use for:** the current operational state of the work
- **Rule:** if something affects an active engineering plan, roadmap, rollout, or release, prefer putting it here first
### Layer 2: Claude Code Memory (Quick Access)
- **Path:** `~/.claude/projects/*/memory/`
- **Format:** Markdown files with frontmatter
- **Types:** user preferences, feedback, project context, reference
- **Use for:** quick-access context that persists across conversations
- **Automatically loaded at session start**
### Layer 3: MCP Memory Server (Structured Knowledge Graph)
- **Access:** MCP memory tools (create_entities, create_relations, add_observations, search_nodes)
- **Use for:** Semantic search across all stored memories, relationship mapping
- **Cross-session persistence with queryable graph structure**
### Layer 4: Knowledge base repo / durable document store
- **Use for:** curated durable notes, session exports, synthesized research, operator memory, long-form docs
- **Rule:** this is the preferred durable store for cross-machine context when the content is not repo-owned code
### Layer 5: External Data Store (Supabase, PostgreSQL, etc.)
- **Use for:** Structured data, large document storage, full-text search
- **Good for:** Documents too large for memory files, data needing SQL queries
### Layer 6: Local context/archive folder
- **Use for:** human-facing notes, archived gameplans, local media organization, temporary non-code docs
- **Rule:** writable for information storage, but not a shadow code workspace
- **Do not use for:** active code changes or repo truth that should live upstream
## Ingestion Workflow
When new knowledge needs to be captured:
### 1. Classify
What type of knowledge is it?
- Business decision -> memory file (project type) + MCP memory
- Active roadmap / release / implementation state -> GitHub + Linear first
- Personal preference -> memory file (user/feedback type)
- Reference info -> memory file (reference type) + MCP memory
- Large document -> external data store + summary in memory
- Conversation/session -> knowledge base repo + short summary in memory
### 2. Deduplicate
Check if this knowledge already exists:
- Search memory files for existing entries
- Query MCP memory with relevant terms
- Check whether the information already exists in GitHub or Linear before creating another local note
- Do not create duplicates. Update existing entries instead.
### 3. Store
Write to appropriate layer(s):
- Always update Claude Code memory for quick access
- Use MCP memory for semantic searchability and relationship mapping
- Update GitHub / Linear first when the information changes live project truth
- Commit to the knowledge base repo for durable long-form additions
### 4. Index
Update any relevant indexes or summary files.
## Sync Operations
### Conversation Sync
Periodically sync conversation history into the knowledge base:
- Sources: Claude session files, Codex sessions, other agent sessions
- Destination: knowledge base repo
- Generate a session index for quick browsing
- Commit and push
### Workspace State Sync
Mirror important workspace configuration and scripts to the knowledge base:
- Generate directory maps
- Redact sensitive config before committing
- Track changes over time
- Do not treat the knowledge base or archive folder as the live code workspace
### GitHub / Linear Sync
When the information affects active execution:
- update the relevant GitHub issue, PR, discussion, release notes, or roadmap thread
- attach supporting docs to Linear when the work needs durable planning context
- only mirror a local note afterwards if it still adds value
### Cross-Source Knowledge Sync
Pull knowledge from multiple sources into one place:
- Claude/ChatGPT/Grok conversation exports
- Browser bookmarks
- GitHub activity events
- Write status summary, commit and push
## Memory Patterns
```
# Short-term: current session context
Use TodoWrite for in-session task tracking
# Medium-term: project memory files
Write to ~/.claude/projects/*/memory/ for cross-session recall
# Long-term: GitHub / Linear / KB
Put active execution truth in GitHub + Linear
Put durable synthesized context in the knowledge base repo
# Semantic layer: MCP knowledge graph
Use mcp__memory__create_entities for permanent structured data
Use mcp__memory__create_relations for relationship mapping
Use mcp__memory__add_observations for new facts about known entities
Use mcp__memory__search_nodes to find existing knowledge
```
## Best Practices
- Keep memory files concise. Archive old data rather than letting files grow unbounded.
- Use frontmatter (YAML) for metadata on all knowledge files.
- Deduplicate before storing. Search first, then create or update.
- Prefer one canonical home per fact set. Avoid parallel copies of the same plan across local notes, repo files, and tracker docs.
- Redact sensitive information (API keys, passwords) before committing to Git.
- Use consistent naming conventions for knowledge files (lowercase-kebab-case).
- Tag entries with topics/categories for easier retrieval.
## Quality Gate
Before completing any knowledge operation:
- no duplicate entries created
- sensitive data redacted from any Git-tracked files
- indexes and summaries updated
- appropriate storage layer chosen for the data type
- cross-references added where relevant