mirror of
https://github.com/affaan-m/everything-claude-code.git
synced 2026-04-06 09:13:31 +08:00
feat: add ECC-native operator workflow skills
This commit is contained in:
Affaan Mustafa
@@ -1,6 +1,6 @@
|
||||
# Everything Claude Code (ECC) — Agent Instructions
|
||||
|
||||
This is a **production-ready AI coding plugin** providing 39 specialized agents, 169 skills, 72 commands, and automated hook workflows for software development.
|
||||
This is a **production-ready AI coding plugin** providing 39 specialized agents, 175 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/ — 39 specialized subagents
|
||||
skills/ — 169 workflow skills and domain knowledge
|
||||
skills/ — 175 workflow skills and domain knowledge
|
||||
commands/ — 72 slash commands
|
||||
hooks/ — Trigger-based automations
|
||||
rules/ — Always-follow guidelines (common + per-language)
|
||||
|
||||
@@ -236,7 +236,7 @@ For manual install instructions see the README in the `rules/` folder. When copy
|
||||
/plugin list ecc@ecc
|
||||
```
|
||||
|
||||
**That's it!** You now have access to 39 agents, 169 skills, and 72 legacy command shims.
|
||||
**That's it!** You now have access to 39 agents, 175 skills, and 72 legacy command shims.
|
||||
|
||||
### Multi-model commands require additional setup
|
||||
|
||||
@@ -1154,7 +1154,7 @@ The configuration is automatically detected from `.opencode/opencode.json`.
|
||||
|---------|-------------|----------|--------|
|
||||
| Agents | PASS: 39 agents | PASS: 12 agents | **Claude Code leads** |
|
||||
| Commands | PASS: 72 commands | PASS: 31 commands | **Claude Code leads** |
|
||||
| Skills | PASS: 169 skills | PASS: 37 skills | **Claude Code leads** |
|
||||
| Skills | PASS: 175 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** |
|
||||
@@ -1263,7 +1263,7 @@ ECC is the **first plugin to maximize every major AI coding tool**. Here's how e
|
||||
|---------|------------|------------|-----------|----------|
|
||||
| **Agents** | 39 | Shared (AGENTS.md) | Shared (AGENTS.md) | 12 |
|
||||
| **Commands** | 72 | Shared | Instruction-based | 31 |
|
||||
| **Skills** | 169 | Shared | 10 (native format) | 37 |
|
||||
| **Skills** | 175 | 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 |
|
||||
|
||||
@@ -106,7 +106,7 @@ cp -r everything-claude-code/rules/perl ~/.claude/rules/
|
||||
/plugin list ecc@ecc
|
||||
```
|
||||
|
||||
**完成！** 你现在可以使用 39 个代理、169 个技能和 72 个命令。
|
||||
**完成！** 你现在可以使用 39 个代理、175 个技能和 72 个命令。
|
||||
|
||||
### multi-* 命令需要额外配置
|
||||
|
||||
|
||||
@@ -152,3 +152,4 @@ Keep this file detailed for only the current sprint, blockers, and next actions.
|
||||
- 2026-04-05: Direct-ported the safe `globals` bump from PR `#1243` into `main` as part of the council lane and closed the PR as superseded.
|
||||
- 2026-04-05: Closed PR `#1232` after full audit. The proposed `skill-scout` workflow overlaps current `search-first`, `/skill-create`, and `skill-stocktake`; if a dedicated marketplace-discovery layer returns later it should be rebuilt on top of the current install/catalog model rather than landing as a parallel discovery path.
|
||||
- 2026-04-05: Ported the safe localized README switcher fixes from PR `#1209` directly into `main` rather than merging the docs PR wholesale. The navigation now consistently includes `Português (Brasil)` and `Türkçe` across the localized README switchers, while newer localized body copy stays intact.
|
||||
- 2026-04-05: Salvaged the reusable Hermes-generated operator workflow lane without replaying the whole branch. Added six ECC-native top-level skills instead of the old nested `skills/hermes-generated/*` tree: `automation-audit-ops`, `email-ops`, `finance-billing-ops`, `messages-ops`, `research-ops`, and `terminal-ops`. `research-ops` now wraps the existing research stack, while the other five extend `operator-workflows` without introducing any external runtime assumptions.
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# Everything Claude Code (ECC) — 智能体指令
|
||||
|
||||
这是一个**生产就绪的 AI 编码插件**，提供 39 个专业代理、169 项技能、72 条命令以及自动化钩子工作流，用于软件开发。
|
||||
这是一个**生产就绪的 AI 编码插件**，提供 39 个专业代理、175 项技能、72 条命令以及自动化钩子工作流，用于软件开发。
|
||||
|
||||
**版本:** 1.10.0
|
||||
|
||||
@@ -147,7 +147,7 @@
|
||||
|
||||
```
|
||||
agents/ — 39 个专业子代理
|
||||
skills/ — 169 个工作流技能和领域知识
|
||||
skills/ — 175 个工作流技能和领域知识
|
||||
commands/ — 72 个斜杠命令
|
||||
hooks/ — 基于触发的自动化
|
||||
rules/ — 始终遵循的指导方针（通用 + 每种语言）
|
||||
|
||||
@@ -209,7 +209,7 @@ npx ecc-install typescript
|
||||
/plugin list ecc@ecc
|
||||
```
|
||||
|
||||
**搞定！** 你现在可以使用 39 个智能体、169 项技能和 72 个命令了。
|
||||
**搞定！** 你现在可以使用 39 个智能体、175 项技能和 72 个命令了。
|
||||
|
||||
***
|
||||
|
||||
@@ -1096,7 +1096,7 @@ opencode
|
||||
|---------|-------------|----------|--------|
|
||||
| 智能体 | PASS: 39 个 | PASS: 12 个 | **Claude Code 领先** |
|
||||
| 命令 | PASS: 72 个 | PASS: 31 个 | **Claude Code 领先** |
|
||||
| 技能 | PASS: 169 项 | PASS: 37 项 | **Claude Code 领先** |
|
||||
| 技能 | PASS: 175 项 | 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 编码工具的插件**。以
|
||||
|---------|------------|------------|-----------|----------|
|
||||
| **智能体** | 39 | 共享 (AGENTS.md) | 共享 (AGENTS.md) | 12 |
|
||||
| **命令** | 72 | 共享 | 基于指令 | 31 |
|
||||
| **技能** | 169 | 共享 | 10 (原生格式) | 37 |
|
||||
| **技能** | 175 | 共享 | 10 (原生格式) | 37 |
|
||||
| **钩子事件** | 8 种类型 | 15 种类型 | 暂无 | 11 种类型 |
|
||||
| **钩子脚本** | 20+ 个脚本 | 16 个脚本 (DRY 适配器) | N/A | 插件钩子 |
|
||||
| **规则** | 34 (通用 + 语言) | 34 (YAML 前页) | 基于指令 | 13 条指令 |
|
||||
|
||||
@@ -271,7 +271,8 @@
|
||||
"paths": [
|
||||
"skills/claude-api",
|
||||
"skills/deep-research",
|
||||
"skills/exa-search"
|
||||
"skills/exa-search",
|
||||
"skills/research-ops"
|
||||
],
|
||||
"targets": [
|
||||
"claude",
|
||||
@@ -323,14 +324,19 @@
|
||||
"kind": "skills",
|
||||
"description": "Connected-app operator workflows for setup audits, billing operations, program tracking, Google Workspace, and network optimization.",
|
||||
"paths": [
|
||||
"skills/automation-audit-ops",
|
||||
"skills/connections-optimizer",
|
||||
"skills/customer-billing-ops",
|
||||
"skills/ecc-tools-cost-audit",
|
||||
"skills/email-ops",
|
||||
"skills/finance-billing-ops",
|
||||
"skills/github-ops",
|
||||
"skills/google-workspace-ops",
|
||||
"skills/jira-integration",
|
||||
"skills/knowledge-ops",
|
||||
"skills/messages-ops",
|
||||
"skills/project-flow-ops",
|
||||
"skills/terminal-ops",
|
||||
"skills/unified-notifications-ops",
|
||||
"skills/workspace-surface-audit"
|
||||
],
|
||||
|
||||
142
skills/automation-audit-ops/SKILL.md
Normal file
142
skills/automation-audit-ops/SKILL.md
Normal file
@@ -0,0 +1,142 @@
|
||||
---
|
||||
name: automation-audit-ops
|
||||
description: Evidence-first automation inventory and overlap audit workflow for ECC. Use when the user wants to know which jobs, hooks, connectors, MCP servers, or wrappers are live, broken, redundant, or missing before fixing anything.
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# 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 are actually doing useful work right now.
|
||||
|
||||
This is an audit-first operator skill. The job is to produce an evidence-backed inventory and a keep / merge / cut / fix-next recommendation set before rewriting anything.
|
||||
|
||||
## Skill Stack
|
||||
|
||||
Pull these ECC-native skills into the workflow when relevant:
|
||||
|
||||
- `workspace-surface-audit` for connector, MCP, hook, and app inventory
|
||||
- `knowledge-ops` when the audit needs to reconcile live repo truth with durable context
|
||||
- `github-ops` when the answer depends on CI, scheduled workflows, issues, or PR automation
|
||||
- `ecc-tools-cost-audit` when the real problem is webhook fanout, queued jobs, or billing burn in the sibling app repo
|
||||
- `research-ops` when local inventory must be compared against current platform support or public docs
|
||||
- `verification-loop` for proving post-fix state instead of relying on assumed recovery
|
||||
|
||||
## When to Use
|
||||
|
||||
- user asks "what automations do I have", "what is live", "what is broken", or "what overlaps"
|
||||
- the task spans cron jobs, GitHub Actions, local hooks, MCP servers, connectors, wrappers, or app integrations
|
||||
- the user wants to know what was ported from another agent system and what still needs to be rebuilt inside ECC
|
||||
- the workspace has accumulated multiple ways to do the same thing and the user wants one canonical lane
|
||||
|
||||
## Guardrails
|
||||
|
||||
- start read-only unless the user explicitly asked for fixes
|
||||
- separate:
|
||||
- configured
|
||||
- authenticated
|
||||
- recently verified
|
||||
- stale or broken
|
||||
- missing entirely
|
||||
- do not claim a tool is live just because a skill or config references it
|
||||
- do not merge or delete overlapping surfaces until the evidence table exists
|
||||
|
||||
## Workflow
|
||||
|
||||
### 1. Inventory the real surface
|
||||
|
||||
Read the current live surface before theorizing:
|
||||
|
||||
- repo hooks and local hook scripts
|
||||
- GitHub Actions and scheduled workflows
|
||||
- MCP configs and enabled servers
|
||||
- connector- or app-backed integrations
|
||||
- wrapper scripts and repo-specific automation entrypoints
|
||||
|
||||
Group them by surface:
|
||||
|
||||
- local runtime
|
||||
- repo CI / automation
|
||||
- connected external systems
|
||||
- messaging / notifications
|
||||
- billing / customer operations
|
||||
- research / monitoring
|
||||
|
||||
### 2. Classify each item by live state
|
||||
|
||||
For every surfaced automation, mark:
|
||||
|
||||
- configured
|
||||
- authenticated
|
||||
- recently verified
|
||||
- stale or broken
|
||||
- missing
|
||||
|
||||
Then classify the problem type:
|
||||
|
||||
- active breakage
|
||||
- auth outage
|
||||
- stale status
|
||||
- overlap or redundancy
|
||||
- missing capability
|
||||
|
||||
### 3. Trace the proof path
|
||||
|
||||
Back every important claim with a concrete source:
|
||||
|
||||
- file path
|
||||
- workflow run
|
||||
- hook log
|
||||
- config entry
|
||||
- recent command output
|
||||
- exact failure signature
|
||||
|
||||
If the current state is ambiguous, say so directly instead of pretending the audit is complete.
|
||||
|
||||
### 4. End with keep / merge / cut / fix-next
|
||||
|
||||
For each overlapping or suspect surface, return one call:
|
||||
|
||||
- keep
|
||||
- merge
|
||||
- cut
|
||||
- fix next
|
||||
|
||||
The value is in collapsing noisy automation into one canonical ECC lane, not in preserving every historical path.
|
||||
|
||||
## Output Format
|
||||
|
||||
```text
|
||||
CURRENT SURFACE
|
||||
- automation
|
||||
- source
|
||||
- live state
|
||||
- proof
|
||||
|
||||
FINDINGS
|
||||
- active breakage
|
||||
- overlap
|
||||
- stale status
|
||||
- missing capability
|
||||
|
||||
RECOMMENDATION
|
||||
- keep
|
||||
- merge
|
||||
- cut
|
||||
- fix next
|
||||
|
||||
NEXT ECC MOVE
|
||||
- exact skill / hook / workflow / app lane to strengthen
|
||||
```
|
||||
|
||||
## Pitfalls
|
||||
|
||||
- do not answer from memory when the live inventory can be read
|
||||
- do not treat "present in config" as "working"
|
||||
- do not fix lower-value redundancy before naming the broken high-signal path
|
||||
- do not widen the task into a repo rewrite if the user asked for inventory first
|
||||
|
||||
## Verification
|
||||
|
||||
- important claims cite a live proof path
|
||||
- each surfaced automation is labeled with a clear live-state category
|
||||
- the final recommendation distinguishes keep / merge / cut / fix-next
|
||||
121
skills/email-ops/SKILL.md
Normal file
121
skills/email-ops/SKILL.md
Normal file
@@ -0,0 +1,121 @@
|
||||
---
|
||||
name: email-ops
|
||||
description: Evidence-first mailbox triage, drafting, send verification, and sent-mail-safe follow-up workflow for ECC. Use when the user wants to organize email, draft or send through the real mail surface, or prove what landed in Sent.
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Email Ops
|
||||
|
||||
Use this when the real task is mailbox work: triage, drafting, replying, sending, or proving a message landed in Sent.
|
||||
|
||||
This is not a generic writing skill. It is an operator workflow around the actual mail surface.
|
||||
|
||||
## Skill Stack
|
||||
|
||||
Pull these ECC-native skills into the workflow when relevant:
|
||||
|
||||
- `brand-voice` before drafting anything user-facing
|
||||
- `investor-outreach` for investor, partner, or sponsor-facing mail
|
||||
- `customer-billing-ops` when the thread is a billing/support incident rather than generic correspondence
|
||||
- `knowledge-ops` when the message or thread should be captured into durable context afterward
|
||||
- `research-ops` when a reply depends on fresh external facts
|
||||
|
||||
## When to Use
|
||||
|
||||
- user asks to triage inbox or archive low-signal mail
|
||||
- user wants a draft, reply, or new outbound email
|
||||
- user wants to know whether a mail was already sent
|
||||
- the user wants proof of which account, thread, or Sent entry was used
|
||||
|
||||
## Guardrails
|
||||
|
||||
- draft first unless the user clearly asked for a live send
|
||||
- never claim a message was sent without a real Sent-folder or client-side confirmation
|
||||
- do not switch sender accounts casually; choose the account that matches the project and recipient
|
||||
- do not delete uncertain business mail during cleanup
|
||||
- if the task is really DM or iMessage work, hand off to `messages-ops`
|
||||
|
||||
## Workflow
|
||||
|
||||
### 1. Resolve the exact surface
|
||||
|
||||
Before acting, settle:
|
||||
|
||||
- which mailbox account
|
||||
- which thread or recipient
|
||||
- whether the task is triage, draft, reply, or send
|
||||
- whether the user wants draft-only or live send
|
||||
|
||||
### 2. Read the thread before composing
|
||||
|
||||
If replying:
|
||||
|
||||
- read the existing thread
|
||||
- identify the last outbound touch
|
||||
- identify any commitments, deadlines, or unanswered questions
|
||||
|
||||
If creating a new outbound:
|
||||
|
||||
- identify warmth level
|
||||
- select the correct channel and sender account
|
||||
- pull `brand-voice` before drafting
|
||||
|
||||
### 3. Draft, then verify
|
||||
|
||||
For draft-only work:
|
||||
|
||||
- produce the final copy
|
||||
- state sender, recipient, subject, and purpose
|
||||
|
||||
For live-send work:
|
||||
|
||||
- verify the exact final body first
|
||||
- send through the chosen mail surface
|
||||
- confirm the message landed in Sent or the equivalent sent-copy store
|
||||
|
||||
### 4. Report exact state
|
||||
|
||||
Use exact status words:
|
||||
|
||||
- drafted
|
||||
- approval-pending
|
||||
- sent
|
||||
- blocked
|
||||
- awaiting verification
|
||||
|
||||
If the send surface is blocked, preserve the draft and report the exact blocker instead of improvising a second transport without saying so.
|
||||
|
||||
## Output Format
|
||||
|
||||
```text
|
||||
MAIL SURFACE
|
||||
- account
|
||||
- thread / recipient
|
||||
- requested action
|
||||
|
||||
DRAFT
|
||||
- subject
|
||||
- body
|
||||
|
||||
STATUS
|
||||
- drafted / sent / blocked
|
||||
- proof of Sent when applicable
|
||||
|
||||
NEXT STEP
|
||||
- send
|
||||
- follow up
|
||||
- archive / move
|
||||
```
|
||||
|
||||
## Pitfalls
|
||||
|
||||
- do not claim send success without a sent-copy check
|
||||
- do not ignore the thread history and write a contextless reply
|
||||
- do not mix mailbox work with DM or text-message workflows
|
||||
- do not expose secrets, auth details, or unnecessary message metadata
|
||||
|
||||
## Verification
|
||||
|
||||
- the response names the account and thread or recipient
|
||||
- any send claim includes Sent proof or an explicit client-side confirmation
|
||||
- the final state is one of drafted / sent / blocked / awaiting verification
|
||||
127
skills/finance-billing-ops/SKILL.md
Normal file
127
skills/finance-billing-ops/SKILL.md
Normal file
@@ -0,0 +1,127 @@
|
||||
---
|
||||
name: finance-billing-ops
|
||||
description: Evidence-first revenue, pricing, refunds, team-billing, and billing-model truth workflow for ECC. Use when the user wants a sales snapshot, pricing comparison, duplicate-charge diagnosis, or code-backed billing reality instead of generic payments advice.
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Finance Billing Ops
|
||||
|
||||
Use this when the user wants to understand money, pricing, refunds, team-seat logic, or whether the product actually behaves the way the website and sales copy imply.
|
||||
|
||||
This is broader than `customer-billing-ops`. That skill is for customer remediation. This skill is for operator truth: revenue state, pricing decisions, team billing, and code-backed billing behavior.
|
||||
|
||||
## Skill Stack
|
||||
|
||||
Pull these ECC-native skills into the workflow when relevant:
|
||||
|
||||
- `customer-billing-ops` for customer-specific remediation and follow-up
|
||||
- `research-ops` when competitor pricing or current market evidence matters
|
||||
- `market-research` when the answer should end in a pricing recommendation
|
||||
- `github-ops` when the billing truth depends on code, backlog, or release state in sibling repos
|
||||
- `verification-loop` when the answer depends on proving checkout, seat handling, or entitlement behavior
|
||||
|
||||
## When to Use
|
||||
|
||||
- user asks for Stripe sales, refunds, MRR, or recent customer activity
|
||||
- user asks whether team billing, per-seat billing, or quota stacking is real in code
|
||||
- user wants competitor pricing comparisons or pricing-model benchmarks
|
||||
- the question mixes revenue facts with product implementation truth
|
||||
|
||||
## Guardrails
|
||||
|
||||
- distinguish live data from saved snapshots
|
||||
- separate:
|
||||
- revenue fact
|
||||
- customer impact
|
||||
- code-backed product truth
|
||||
- recommendation
|
||||
- do not say "per seat" unless the actual entitlement path enforces it
|
||||
- do not assume duplicate subscriptions imply duplicate value
|
||||
|
||||
## Workflow
|
||||
|
||||
### 1. Start from the freshest billing evidence
|
||||
|
||||
Prefer live billing data. If the data is not live, state the snapshot timestamp explicitly.
|
||||
|
||||
Normalize the picture:
|
||||
|
||||
- paid sales
|
||||
- active subscriptions
|
||||
- failed or incomplete checkouts
|
||||
- refunds
|
||||
- disputes
|
||||
- duplicate subscriptions
|
||||
|
||||
### 2. Separate customer incidents from product truth
|
||||
|
||||
If the question is customer-specific, classify first:
|
||||
|
||||
- duplicate checkout
|
||||
- real team intent
|
||||
- broken self-serve controls
|
||||
- unmet product value
|
||||
- failed payment or incomplete setup
|
||||
|
||||
Then separate that from the broader product question:
|
||||
|
||||
- does team billing really exist?
|
||||
- are seats actually counted?
|
||||
- does checkout quantity change entitlement?
|
||||
- does the site overstate current behavior?
|
||||
|
||||
### 3. Inspect code-backed billing behavior
|
||||
|
||||
If the answer depends on implementation truth, inspect the code path:
|
||||
|
||||
- checkout
|
||||
- pricing page
|
||||
- entitlement calculation
|
||||
- seat or quota handling
|
||||
- installation vs user usage logic
|
||||
- billing portal or self-serve management support
|
||||
|
||||
### 4. End with a decision and product gap
|
||||
|
||||
Report:
|
||||
|
||||
- sales snapshot
|
||||
- issue diagnosis
|
||||
- product truth
|
||||
- recommended operator action
|
||||
- product or backlog gap
|
||||
|
||||
## Output Format
|
||||
|
||||
```text
|
||||
SNAPSHOT
|
||||
- timestamp
|
||||
- revenue / subscriptions / anomalies
|
||||
|
||||
CUSTOMER IMPACT
|
||||
- who is affected
|
||||
- what happened
|
||||
|
||||
PRODUCT TRUTH
|
||||
- what the code actually does
|
||||
- what the website or sales copy claims
|
||||
|
||||
DECISION
|
||||
- refund / preserve / convert / no-op
|
||||
|
||||
PRODUCT GAP
|
||||
- exact follow-up item to build or fix
|
||||
```
|
||||
|
||||
## Pitfalls
|
||||
|
||||
- do not conflate failed attempts with net revenue
|
||||
- do not infer team billing from marketing language alone
|
||||
- do not compare competitor pricing from memory when current evidence is available
|
||||
- do not jump from diagnosis straight to refund without classifying the issue
|
||||
|
||||
## Verification
|
||||
|
||||
- the answer includes a live-data statement or snapshot timestamp
|
||||
- product-truth claims are code-backed
|
||||
- customer-impact and broader pricing/product conclusions are separated cleanly
|
||||
104
skills/messages-ops/SKILL.md
Normal file
104
skills/messages-ops/SKILL.md
Normal file
@@ -0,0 +1,104 @@
|
||||
---
|
||||
name: messages-ops
|
||||
description: Evidence-first live messaging workflow for ECC. Use when the user wants to read texts or DMs, recover a recent one-time code, inspect a thread before replying, or prove which message source was actually checked.
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Messages Ops
|
||||
|
||||
Use this when the task is live-message retrieval: iMessage, DMs, recent one-time codes, or thread inspection before a follow-up.
|
||||
|
||||
This is not email work. If the dominant surface is a mailbox, use `email-ops`.
|
||||
|
||||
## Skill Stack
|
||||
|
||||
Pull these ECC-native skills into the workflow when relevant:
|
||||
|
||||
- `email-ops` when the message task is really mailbox work
|
||||
- `connections-optimizer` when the DM thread belongs to outbound network work
|
||||
- `lead-intelligence` when the live thread should inform targeting or warm-path outreach
|
||||
- `knowledge-ops` when the thread contents need to be captured into durable context
|
||||
|
||||
## When to Use
|
||||
|
||||
- user says "read my messages", "check texts", "look in DMs", or "find the code"
|
||||
- the task depends on a live thread or a recent code delivered to a local messaging surface
|
||||
- the user wants proof of which source or thread was inspected
|
||||
|
||||
## Guardrails
|
||||
|
||||
- resolve the source first:
|
||||
- local messages
|
||||
- X / social DM
|
||||
- another browser-gated message surface
|
||||
- do not claim a thread was checked without naming the source
|
||||
- do not improvise raw database access if a checked helper or standard path exists
|
||||
- if auth or MFA blocks the surface, report the exact blocker
|
||||
|
||||
## Workflow
|
||||
|
||||
### 1. Resolve the exact thread
|
||||
|
||||
Before doing anything else, settle:
|
||||
|
||||
- message surface
|
||||
- sender / recipient / service
|
||||
- time window
|
||||
- whether the task is retrieval, inspection, or prep for a reply
|
||||
|
||||
### 2. Read before drafting
|
||||
|
||||
If the task may turn into an outbound follow-up:
|
||||
|
||||
- read the latest inbound
|
||||
- identify the open loop
|
||||
- then hand off to the correct outbound skill if needed
|
||||
|
||||
### 3. Handle codes as a focused retrieval task
|
||||
|
||||
For one-time codes:
|
||||
|
||||
- search the recent local message window first
|
||||
- narrow by service or sender when possible
|
||||
- stop once the code is found or the focused search is exhausted
|
||||
|
||||
### 4. Report exact evidence
|
||||
|
||||
Return:
|
||||
|
||||
- source used
|
||||
- thread or sender when possible
|
||||
- time window
|
||||
- exact status:
|
||||
- read
|
||||
- code-found
|
||||
- blocked
|
||||
- awaiting reply draft
|
||||
|
||||
## Output Format
|
||||
|
||||
```text
|
||||
SOURCE
|
||||
- message surface
|
||||
- sender / thread / service
|
||||
|
||||
RESULT
|
||||
- message summary or code
|
||||
- time window
|
||||
|
||||
STATUS
|
||||
- read / code-found / blocked / awaiting reply draft
|
||||
```
|
||||
|
||||
## Pitfalls
|
||||
|
||||
- do not blur mailbox work and DM/text work
|
||||
- do not claim retrieval without naming the source
|
||||
- do not burn time on broad searches when the ask is a recent-code lookup
|
||||
- do not keep retrying a blocked auth path without surfacing the blocker
|
||||
|
||||
## Verification
|
||||
|
||||
- the response names the message source
|
||||
- the response includes a sender, service, thread, or clear blocker
|
||||
- the final state is explicit and bounded
|
||||
112
skills/research-ops/SKILL.md
Normal file
112
skills/research-ops/SKILL.md
Normal file
@@ -0,0 +1,112 @@
|
||||
---
|
||||
name: research-ops
|
||||
description: Evidence-first current-state research workflow for ECC. Use when the user wants fresh facts, comparisons, enrichment, or a recommendation built from current public evidence and any supplied local context.
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Research Ops
|
||||
|
||||
Use this when the user asks to research something current, compare options, enrich people or companies, or turn repeated lookups into a monitored workflow.
|
||||
|
||||
This is the operator wrapper around the repo's research stack. It is not a replacement for `deep-research`, `exa-search`, or `market-research`; it tells you when and how to use them together.
|
||||
|
||||
## Skill Stack
|
||||
|
||||
Pull these ECC-native skills into the workflow when relevant:
|
||||
|
||||
- `exa-search` for fast current-web discovery
|
||||
- `deep-research` for multi-source synthesis with citations
|
||||
- `market-research` when the end result should be a recommendation or ranked decision
|
||||
- `lead-intelligence` when the task is people/company targeting instead of generic research
|
||||
- `knowledge-ops` when the result should be stored in durable context afterward
|
||||
|
||||
## When to Use
|
||||
|
||||
- user says "research", "look up", "compare", "who should I talk to", or "what's the latest"
|
||||
- the answer depends on current public information
|
||||
- the user already supplied evidence and wants it factored into a fresh recommendation
|
||||
- the task may be recurring enough that it should become a monitor instead of a one-off lookup
|
||||
|
||||
## Guardrails
|
||||
|
||||
- do not answer current questions from stale memory when fresh search is cheap
|
||||
- separate:
|
||||
- sourced fact
|
||||
- user-provided evidence
|
||||
- inference
|
||||
- recommendation
|
||||
- do not spin up a heavyweight research pass if the answer is already in local code or docs
|
||||
|
||||
## Workflow
|
||||
|
||||
### 1. Start from what the user already gave you
|
||||
|
||||
Normalize any supplied material into:
|
||||
|
||||
- already-evidenced facts
|
||||
- needs verification
|
||||
- open questions
|
||||
|
||||
Do not restart the analysis from zero if the user already built part of the model.
|
||||
|
||||
### 2. Classify the ask
|
||||
|
||||
Choose the right lane before searching:
|
||||
|
||||
- quick factual answer
|
||||
- comparison or decision memo
|
||||
- lead/enrichment pass
|
||||
- recurring monitoring candidate
|
||||
|
||||
### 3. Take the lightest useful evidence path first
|
||||
|
||||
- use `exa-search` for fast discovery
|
||||
- escalate to `deep-research` when synthesis or multiple sources matter
|
||||
- use `market-research` when the outcome should end in a recommendation
|
||||
- hand off to `lead-intelligence` when the real ask is target ranking or warm-path discovery
|
||||
|
||||
### 4. Report with explicit evidence boundaries
|
||||
|
||||
For important claims, say whether they are:
|
||||
|
||||
- sourced facts
|
||||
- user-supplied context
|
||||
- inference
|
||||
- recommendation
|
||||
|
||||
Freshness-sensitive answers should include concrete dates.
|
||||
|
||||
### 5. Decide whether the task should stay manual
|
||||
|
||||
If the user is likely to ask the same research question repeatedly, say so explicitly and recommend a monitoring or workflow layer instead of repeating the same manual search forever.
|
||||
|
||||
## Output Format
|
||||
|
||||
```text
|
||||
QUESTION TYPE
|
||||
- factual / comparison / enrichment / monitoring
|
||||
|
||||
EVIDENCE
|
||||
- sourced facts
|
||||
- user-provided context
|
||||
|
||||
INFERENCE
|
||||
- what follows from the evidence
|
||||
|
||||
RECOMMENDATION
|
||||
- answer or next move
|
||||
- whether this should become a monitor
|
||||
```
|
||||
|
||||
## Pitfalls
|
||||
|
||||
- do not mix inference into sourced facts without labeling it
|
||||
- do not ignore user-provided evidence
|
||||
- do not use a heavy research lane for a question local repo context can answer
|
||||
- do not give freshness-sensitive answers without dates
|
||||
|
||||
## Verification
|
||||
|
||||
- important claims are labeled by evidence type
|
||||
- freshness-sensitive outputs include dates
|
||||
- the final recommendation matches the actual research mode used
|
||||
109
skills/terminal-ops/SKILL.md
Normal file
109
skills/terminal-ops/SKILL.md
Normal file
@@ -0,0 +1,109 @@
|
||||
---
|
||||
name: terminal-ops
|
||||
description: Evidence-first repo execution workflow for ECC. Use when the user wants a command run, a repo checked, a CI failure debugged, or a narrow fix pushed with exact proof of what was executed and verified.
|
||||
origin: ECC
|
||||
---
|
||||
|
||||
# Terminal Ops
|
||||
|
||||
Use this when the user wants real repo execution: run commands, inspect git state, debug CI or builds, make a narrow fix, and report exactly what changed and what was verified.
|
||||
|
||||
This skill is intentionally narrower than general coding guidance. It is an operator workflow for evidence-first terminal execution.
|
||||
|
||||
## Skill Stack
|
||||
|
||||
Pull these ECC-native skills into the workflow when relevant:
|
||||
|
||||
- `verification-loop` for exact proving steps after changes
|
||||
- `tdd-workflow` when the right fix needs regression coverage
|
||||
- `security-review` when secrets, auth, or external inputs are involved
|
||||
- `github-ops` when the task depends on CI runs, PR state, or release status
|
||||
- `knowledge-ops` when the verified outcome needs to be captured into durable project context
|
||||
|
||||
## When to Use
|
||||
|
||||
- user says "fix", "debug", "run this", "check the repo", or "push it"
|
||||
- the task depends on command output, git state, test results, or a verified local fix
|
||||
- the answer must distinguish changed locally, verified locally, committed, and pushed
|
||||
|
||||
## Guardrails
|
||||
|
||||
- inspect before editing
|
||||
- stay read-only if the user asked for audit/review only
|
||||
- prefer repo-local scripts and helpers over improvised ad hoc wrappers
|
||||
- do not claim fixed until the proving command was rerun
|
||||
- do not claim pushed unless the branch actually moved upstream
|
||||
|
||||
## Workflow
|
||||
|
||||
### 1. Resolve the working surface
|
||||
|
||||
Settle:
|
||||
|
||||
- exact repo path
|
||||
- branch
|
||||
- local diff state
|
||||
- requested mode:
|
||||
- inspect
|
||||
- fix
|
||||
- verify
|
||||
- push
|
||||
|
||||
### 2. Read the failing surface first
|
||||
|
||||
Before changing anything:
|
||||
|
||||
- inspect the error
|
||||
- inspect the file or test
|
||||
- inspect git state
|
||||
- use any already-supplied logs or context before re-reading blindly
|
||||
|
||||
### 3. Keep the fix narrow
|
||||
|
||||
Solve one dominant failure at a time:
|
||||
|
||||
- use the smallest useful proving command first
|
||||
- only escalate to a bigger build/test pass after the local failure is addressed
|
||||
- if a command keeps failing with the same signature, stop broad retries and narrow scope
|
||||
|
||||
### 4. Report exact execution state
|
||||
|
||||
Use exact status words:
|
||||
|
||||
- inspected
|
||||
- changed locally
|
||||
- verified locally
|
||||
- committed
|
||||
- pushed
|
||||
- blocked
|
||||
|
||||
## Output Format
|
||||
|
||||
```text
|
||||
SURFACE
|
||||
- repo
|
||||
- branch
|
||||
- requested mode
|
||||
|
||||
EVIDENCE
|
||||
- failing command / diff / test
|
||||
|
||||
ACTION
|
||||
- what changed
|
||||
|
||||
STATUS
|
||||
- inspected / changed locally / verified locally / committed / pushed / blocked
|
||||
```
|
||||
|
||||
## Pitfalls
|
||||
|
||||
- do not work from stale memory when the live repo state can be read
|
||||
- do not widen a narrow fix into repo-wide churn
|
||||
- do not use destructive git commands
|
||||
- do not ignore unrelated local work
|
||||
|
||||
## Verification
|
||||
|
||||
- the response names the proving command or test
|
||||
- git-related work names the repo path and branch
|
||||
- any push claim includes the target branch and exact result
|
||||
Reference in New Issue
Block a user