From 1abeff9be79ac0b1b06f87a04c57823e10d068ee Mon Sep 17 00:00:00 2001 From: Affaan Mustafa Date: Wed, 1 Apr 2026 02:37:42 -0700 Subject: [PATCH] feat: add connected operator workflow skills --- AGENTS.md | 4 +- README.md | 6 +- README.zh-CN.md | 2 +- WORKING-CONTEXT.md | 2 + docs/zh-CN/AGENTS.md | 4 +- docs/zh-CN/README.md | 6 +- manifests/install-components.json | 8 ++ manifests/install-modules.json | 25 +++++ manifests/install-profiles.json | 1 + skills/customer-billing-ops/SKILL.md | 140 ++++++++++++++++++++++++ skills/google-workspace-ops/SKILL.md | 95 ++++++++++++++++ skills/project-flow-ops/SKILL.md | 111 +++++++++++++++++++ skills/workspace-surface-audit/SKILL.md | 125 +++++++++++++++++++++ 13 files changed, 518 insertions(+), 11 deletions(-) create mode 100644 skills/customer-billing-ops/SKILL.md create mode 100644 skills/google-workspace-ops/SKILL.md create mode 100644 skills/project-flow-ops/SKILL.md create mode 100644 skills/workspace-surface-audit/SKILL.md diff --git a/AGENTS.md b/AGENTS.md index 3fca216e..031de739 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -1,6 +1,6 @@ # Everything Claude Code (ECC) — Agent Instructions -This is a **production-ready AI coding plugin** providing 36 specialized agents, 143 skills, 68 commands, and automated hook workflows for software development. +This is a **production-ready AI coding plugin** providing 36 specialized agents, 147 skills, 68 commands, and automated hook workflows for software development. **Version:** 1.9.0 @@ -146,7 +146,7 @@ Troubleshoot failures: check test isolation → verify mocks → fix implementat ``` agents/ — 36 specialized subagents -skills/ — 143 workflow skills and domain knowledge +skills/ — 147 workflow skills and domain knowledge commands/ — 68 slash commands hooks/ — Trigger-based automations rules/ — Always-follow guidelines (common + per-language) diff --git a/README.md b/README.md index 68e91c77..ced6bbc7 100644 --- a/README.md +++ b/README.md @@ -225,7 +225,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 36 agents, 143 skills, and 68 legacy command shims. +**That's it!** You now have access to 36 agents, 147 skills, and 68 legacy command shims. ### Multi-model commands require additional setup @@ -1120,7 +1120,7 @@ The configuration is automatically detected from `.opencode/opencode.json`. |---------|-------------|----------|--------| | Agents | PASS: 36 agents | PASS: 12 agents | **Claude Code leads** | | Commands | PASS: 68 commands | PASS: 31 commands | **Claude Code leads** | -| Skills | PASS: 143 skills | PASS: 37 skills | **Claude Code leads** | +| Skills | PASS: 147 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** | @@ -1229,7 +1229,7 @@ ECC is the **first plugin to maximize every major AI coding tool**. Here's how e |---------|------------|------------|-----------|----------| | **Agents** | 36 | Shared (AGENTS.md) | Shared (AGENTS.md) | 12 | | **Commands** | 68 | Shared | Instruction-based | 31 | -| **Skills** | 143 | Shared | 10 (native format) | 37 | +| **Skills** | 147 | 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 | diff --git a/README.zh-CN.md b/README.zh-CN.md index 4c116bef..219428fb 100644 --- a/README.zh-CN.md +++ b/README.zh-CN.md @@ -106,7 +106,7 @@ cp -r everything-claude-code/rules/perl ~/.claude/rules/ /plugin list everything-claude-code@everything-claude-code ``` -**完成！** 你现在可以使用 36 个代理、143 个技能和 68 个命令。 +**完成！** 你现在可以使用 36 个代理、147 个技能和 68 个命令。 ### multi-* 命令需要额外配置 diff --git a/WORKING-CONTEXT.md b/WORKING-CONTEXT.md index fd255ea5..7d42e2b5 100644 --- a/WORKING-CONTEXT.md +++ b/WORKING-CONTEXT.md @@ -35,6 +35,7 @@ Public ECC plugin repo for agents, skills, commands, hooks, rules, install surfa - remove generic LLM rhetoric, canned CTA patterns, and forced platform stereotypes - continue one-by-one audit of overlapping or low-signal skill content - move repo guidance and contribution flow to skills-first, leaving commands only as explicit compatibility shims + - add operator skills that wrap connected surfaces instead of exposing only raw APIs or disconnected primitives - Security: - keep dependency posture clean - preserve self-contained hook and MCP behavior @@ -95,3 +96,4 @@ Keep this file detailed for only the current sprint, blockers, and next actions. - 2026-04-01: Ported the useful core of `#1078` directly into `main`, but tightened the implementation so legacy no-id hook installs deduplicate cleanly on the first reinstall instead of the second. Added stable hook ids to `hooks/hooks.json`, semantic fallback aliases in `mergeHookEntries()`, and a regression test covering upgrade from pre-id settings. - 2026-04-01: Collapsed the obvious command/skill duplicates into thin legacy shims so `skills/` now hold the maintained bodies for NanoClaw, context-budget, DevFleet, docs lookup, E2E, evals, orchestration, prompt optimization, rules distillation, TDD, and verification. - 2026-04-01: Ported the self-contained core of `#844` directly into `main` as `skills/ui-demo/SKILL.md` and registered it under the `media-generation` install module instead of merging the PR wholesale. +- 2026-04-01: Added the first connected-workflow operator lane as ECC-native skills instead of leaving the surface as raw plugins or APIs: `workspace-surface-audit`, `customer-billing-ops`, `project-flow-ops`, and `google-workspace-ops`. These are tracked under the new `operator-workflows` install module. diff --git a/docs/zh-CN/AGENTS.md b/docs/zh-CN/AGENTS.md index 3c4dbe25..98d4c39f 100644 --- a/docs/zh-CN/AGENTS.md +++ b/docs/zh-CN/AGENTS.md @@ -1,6 +1,6 @@ # Everything Claude Code (ECC) — 智能体指令 -这是一个**生产就绪的 AI 编码插件**，提供 36 个专业代理、143 项技能、68 条命令以及自动化钩子工作流，用于软件开发。 +这是一个**生产就绪的 AI 编码插件**，提供 36 个专业代理、147 项技能、68 条命令以及自动化钩子工作流，用于软件开发。 **版本:** 1.9.0 @@ -147,7 +147,7 @@ ``` agents/ — 36 个专业子代理 -skills/ — 143 个工作流技能和领域知识 +skills/ — 147 个工作流技能和领域知识 commands/ — 68 个斜杠命令 hooks/ — 基于触发的自动化 rules/ — 始终遵循的指导方针（通用 + 每种语言） diff --git a/docs/zh-CN/README.md b/docs/zh-CN/README.md index c755c0e7..0d76160b 100644 --- a/docs/zh-CN/README.md +++ b/docs/zh-CN/README.md @@ -209,7 +209,7 @@ npx ecc-install typescript /plugin list everything-claude-code@everything-claude-code ``` -**搞定！** 你现在可以使用 36 个智能体、143 项技能和 68 个命令了。 +**搞定！** 你现在可以使用 36 个智能体、147 项技能和 68 个命令了。 *** @@ -1096,7 +1096,7 @@ opencode |---------|-------------|----------|--------| | 智能体 | PASS: 36 个 | PASS: 12 个 | **Claude Code 领先** | | 命令 | PASS: 68 个 | PASS: 31 个 | **Claude Code 领先** | -| 技能 | PASS: 143 项 | PASS: 37 项 | **Claude Code 领先** | +| 技能 | PASS: 147 项 | 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 编码工具的插件**。以 |---------|------------|------------|-----------|----------| | **智能体** | 36 | 共享 (AGENTS.md) | 共享 (AGENTS.md) | 12 | | **命令** | 68 | 共享 | 基于指令 | 31 | -| **技能** | 143 | 共享 | 10 (原生格式) | 37 | +| **技能** | 147 | 共享 | 10 (原生格式) | 37 | | **钩子事件** | 8 种类型 | 15 种类型 | 暂无 | 11 种类型 | | **钩子脚本** | 20+ 个脚本 | 16 个脚本 (DRY 适配器) | N/A | 插件钩子 | | **规则** | 34 (通用 + 语言) | 34 (YAML 前页) | 基于指令 | 13 条指令 | diff --git a/manifests/install-components.json b/manifests/install-components.json index 8f3d7306..5531b7cb 100644 --- a/manifests/install-components.json +++ b/manifests/install-components.json @@ -145,6 +145,14 @@ "business-content" ] }, + { + "id": "capability:operators", + "family": "capability", + "description": "Connected-app operator workflows for setup audits, billing operations, program tracking, and Google Workspace.", + "modules": [ + "operator-workflows" + ] + }, { "id": "capability:social", "family": "capability", diff --git a/manifests/install-modules.json b/manifests/install-modules.json index f305c3ed..7d038bcd 100644 --- a/manifests/install-modules.json +++ b/manifests/install-modules.json @@ -303,6 +303,31 @@ "cost": "heavy", "stability": "stable" }, + { + "id": "operator-workflows", + "kind": "skills", + "description": "Connected-app operator workflows for setup audits, billing operations, program tracking, and Google Workspace.", + "paths": [ + "skills/customer-billing-ops", + "skills/google-workspace-ops", + "skills/project-flow-ops", + "skills/workspace-surface-audit" + ], + "targets": [ + "claude", + "cursor", + "antigravity", + "codex", + "opencode", + "codebuddy" + ], + "dependencies": [ + "platform-configs" + ], + "defaultInstall": false, + "cost": "medium", + "stability": "beta" + }, { "id": "social-distribution", "kind": "skills", diff --git a/manifests/install-profiles.json b/manifests/install-profiles.json index 08c39833..c35bb0db 100644 --- a/manifests/install-profiles.json +++ b/manifests/install-profiles.json @@ -66,6 +66,7 @@ "security", "research-apis", "business-content", + "operator-workflows", "social-distribution", "media-generation", "orchestration", diff --git a/skills/customer-billing-ops/SKILL.md b/skills/customer-billing-ops/SKILL.md new file mode 100644 index 00000000..d3bc4c77 --- /dev/null +++ b/skills/customer-billing-ops/SKILL.md @@ -0,0 +1,140 @@ +--- +name: customer-billing-ops +description: Operate customer billing workflows such as subscriptions, refunds, churn triage, billing-portal recovery, and plan analysis using connected billing tools like Stripe. Use when the user needs to help a customer, inspect subscription state, or manage revenue-impacting billing operations. +origin: ECC +--- + +# Customer Billing Ops + +Use this skill for real customer operations, not generic payment API design. + +The goal is to help the operator answer: who is this customer, what happened, what is the safest fix, and what follow-up should we send? + +## When to Use + +- Customer says billing is broken, they want a refund, or they cannot cancel +- Investigating duplicate subscriptions, accidental charges, failed renewals, or churn risk +- Reviewing plan mix, active subscriptions, yearly vs monthly conversion, or team-seat confusion +- Creating or validating a billing portal flow +- Auditing support complaints that touch subscriptions, invoices, refunds, or payment methods + +## Preferred Tool Surface + +- Use connected billing tools such as Stripe first +- Use email, GitHub, or issue trackers only as supporting evidence +- Prefer hosted billing/customer portals over custom account-management code when the platform already provides the needed controls + +## Guardrails + +- Never expose secret keys, full card details, or unnecessary customer PII in the response +- Do not refund blindly; first classify the issue +- Distinguish among: + - accidental duplicate purchase + - deliberate multi-seat or team purchase + - broken product / unmet value + - failed or incomplete checkout + - cancellation due to missing self-serve controls +- For annual plans, team plans, and prorated states, verify the contract shape before taking action + +## Workflow + +### 1. Identify the customer cleanly + +Start from the strongest identifier available: + +- customer email +- Stripe customer ID +- subscription ID +- invoice ID +- GitHub username or support email if it is known to map back to billing + +Return a concise identity summary: + +- customer +- active subscriptions +- canceled subscriptions +- invoices +- obvious anomalies such as duplicate active subscriptions + +### 2. Classify the issue + +Put the case into one bucket before acting: + +| Case | Typical action | +|------|----------------| +| Duplicate personal subscription | cancel extras, consider refund | +| Real multi-seat/team intent | preserve seats, clarify billing model | +| Failed payment / incomplete checkout | recover via portal or update payment method | +| Missing self-serve controls | provide portal, cancellation path, or invoice access | +| Product failure or trust break | refund, apologize, log product issue | + +### 3. Take the safest reversible action first + +Preferred order: + +1. restore self-serve management +2. fix duplicate or broken billing state +3. refund only the affected charge or duplicate +4. document the reason +5. send a short customer follow-up + +If the fix requires product work, separate: + +- customer remediation now +- product bug / workflow gap for backlog + +### 4. Check operator-side product gaps + +If the customer pain comes from a missing operator surface, call it out explicitly. Common examples: + +- no billing portal +- no usage/rate-limit visibility +- no plan/seat explanation +- no cancellation flow +- no duplicate-subscription guard + +Treat those as ECC or website follow-up items, not just support incidents. + +### 5. Produce the operator handoff + +End with: + +- customer state summary +- action taken +- revenue impact +- follow-up text to send +- product or backlog issue to create + +## Output Format + +Use this structure: + +```text +CUSTOMER +- name / email +- relevant account identifiers + +BILLING STATE +- active subscriptions +- invoice or renewal state +- anomalies + +DECISION +- issue classification +- why this action is correct + +ACTION TAKEN +- refund / cancel / portal / no-op + +FOLLOW-UP +- short customer message + +PRODUCT GAP +- what should be fixed in the product or website +``` + +## Examples of Good Recommendations + +- "The right fix is a billing portal, not a custom dashboard yet" +- "This looks like duplicate personal checkout, not a real team-seat purchase" +- "Refund one duplicate charge, keep the remaining active subscription, then convert the customer to org billing later if needed" diff --git a/skills/google-workspace-ops/SKILL.md b/skills/google-workspace-ops/SKILL.md new file mode 100644 index 00000000..54ef2708 --- /dev/null +++ b/skills/google-workspace-ops/SKILL.md @@ -0,0 +1,95 @@ +--- +name: google-workspace-ops +description: Operate across Google Drive, Docs, Sheets, and Slides as one workflow surface for plans, trackers, decks, and shared documents. Use when the user needs to find, summarize, edit, migrate, or clean up Google Workspace assets without dropping to raw tool calls. +origin: ECC +--- + +# Google Workspace Ops + +This skill is for operating shared docs, spreadsheets, and decks as working systems, not just editing one file in isolation. + +## When to Use + +- User needs to find a doc, sheet, or deck and update it in place +- Consolidating plans, trackers, notes, or customer lists stored in Google Drive +- Cleaning or restructuring a shared spreadsheet +- Importing, repairing, or reformatting a Google Slides deck +- Producing summaries from Docs, Sheets, or Slides for decision-making + +## Preferred Tool Surface + +Use Google Drive as the entry point, then switch to the right specialist: + +- Google Docs for text-heavy docs +- Google Sheets for tabular work, formulas, and charts +- Google Slides for decks, imports, template migration, and cleanup + +Do not guess structure from filenames alone. Inspect first. + +## Workflow + +### 1. Find the asset + +Start with the Drive search surface to locate: + +- the exact file +- sibling assets +- likely duplicates +- recently modified versions + +If several documents look similar, confirm by title, owner, modified time, or folder. + +### 2. Inspect before editing + +Before making changes: + +- summarize current structure +- identify tabs, headings, or slide count +- detect whether the task is local cleanup or structural surgery + +Pick the smallest tool that can safely perform the work. + +### 3. Edit with precision + +- For Docs: use index-aware edits, not vague rewrites +- For Sheets: operate on explicit tabs and ranges +- For Slides: distinguish content edits from visual cleanup or template migration + +If the requested work is visual or layout-sensitive, iterate with inspection and verification instead of one giant blind update. + +### 4. Keep the working system clean + +When the file is part of a larger workflow, also surface: + +- duplicate trackers +- outdated decks +- stale docs vs canonical docs +- whether the asset should be archived, merged, or renamed + +## Output Format + +Use: + +```text +ASSET +- file name +- type +- why this is the right file + +CURRENT STATE +- structure summary +- key problems or blockers + +ACTION +- edits made or recommended + +FOLLOW-UPS +- archive / merge / duplicate cleanup / next file to update +``` + +## Good Use Cases + +- "Find the active planning doc and condense it" +- "Clean up this customer spreadsheet and show me the churn-risk rows" +- "Import this deck into Slides and make it presentable" +- "Find the current tracker, not the stale duplicate" diff --git a/skills/project-flow-ops/SKILL.md b/skills/project-flow-ops/SKILL.md new file mode 100644 index 00000000..3c3b46ee --- /dev/null +++ b/skills/project-flow-ops/SKILL.md @@ -0,0 +1,111 @@ +--- +name: project-flow-ops +description: Operate execution flow across GitHub and Linear by triaging issues and pull requests, linking active work, and keeping GitHub public-facing while Linear remains the internal execution layer. Use when the user wants backlog control, PR triage, or GitHub-to-Linear coordination. +origin: ECC +--- + +# Project Flow Ops + +This skill turns disconnected GitHub issues, PRs, and Linear tasks into one execution flow. + +Use it when the problem is coordination, not coding. + +## When to Use + +- Triage open PR or issue backlogs +- Decide what belongs in Linear vs what should remain GitHub-only +- Link active GitHub work to internal execution lanes +- Classify PRs into merge, port/rebuild, close, or park +- Audit whether review comments, CI failures, or stale issues are blocking execution + +## Operating Model + +- **GitHub** is the public and community truth +- **Linear** is the internal execution truth for active scheduled work +- Not every GitHub issue needs a Linear issue +- Create or update Linear only when the work is: + - active + - delegated + - scheduled + - cross-functional + - important enough to track internally + +## Core Workflow + +### 1. Read the public surface first + +Gather: + +- GitHub issue or PR state +- author and branch status +- review comments +- CI status +- linked issues + +### 2. Classify the work + +Every item should end up in one of these states: + +| State | Meaning | +|-------|---------| +| Merge | self-contained, policy-compliant, ready | +| Port/Rebuild | useful idea, but should be manually re-landed inside ECC | +| Close | wrong direction, stale, unsafe, or duplicated | +| Park | potentially useful, but not scheduled now | + +### 3. Decide whether Linear is warranted + +Create or update Linear only if: + +- execution is actively planned +- multiple repos or workstreams are involved +- the work needs internal ownership or sequencing +- the issue is part of a larger program lane + +Do not mirror everything mechanically. + +### 4. Keep the two systems consistent + +When work is active: + +- GitHub issue/PR should say what is happening publicly +- Linear should track owner, priority, and execution lane internally + +When work ships or is rejected: + +- post the public resolution back to GitHub +- mark the Linear task accordingly + +## Review Rules + +- Never merge from title, summary, or trust alone; use the full diff +- External-source features should be rebuilt inside ECC when they are valuable but not self-contained +- CI red means classify and fix or block; do not pretend it is merge-ready +- If the real blocker is product direction, say so instead of hiding behind tooling + +## Output Format + +Return: + +```text +PUBLIC STATUS +- issue / PR state +- CI / review state + +CLASSIFICATION +- merge / port-rebuild / close / park +- one-paragraph rationale + +LINEAR ACTION +- create / update / no Linear item needed +- project / lane if applicable + +NEXT OPERATOR ACTION +- exact next move +``` + +## Good Use Cases + +- "Audit the open PR backlog and tell me what to merge vs rebuild" +- "Map GitHub issues into our ECC 1.x and ECC 2.0 program lanes" +- "Check whether this needs a Linear issue or should stay GitHub-only" diff --git a/skills/workspace-surface-audit/SKILL.md b/skills/workspace-surface-audit/SKILL.md new file mode 100644 index 00000000..2967fe34 --- /dev/null +++ b/skills/workspace-surface-audit/SKILL.md @@ -0,0 +1,125 @@ +--- +name: workspace-surface-audit +description: Audit the active repo, MCP servers, plugins, connectors, env surfaces, and harness setup, then recommend the highest-value ECC-native skills, hooks, agents, and operator workflows. Use when the user wants help setting up Claude Code or understanding what capabilities are actually available in their environment. +origin: ECC +--- + +# Workspace Surface Audit + +Read-only audit skill for answering the question "what can this workspace and machine actually do right now, and what should we add or enable next?" + +This is the ECC-native answer to setup-audit plugins. It does not modify files unless the user explicitly asks for follow-up implementation. + +## When to Use + +- User says "set up Claude Code", "recommend automations", "what plugins or MCPs should I use?", or "what am I missing?" +- Auditing a machine or repo before installing more skills, hooks, or connectors +- Comparing official marketplace plugins against ECC-native coverage +- Reviewing `.env`, `.mcp.json`, plugin settings, or connected-app surfaces to find missing workflow layers +- Deciding whether a capability should be a skill, hook, agent, MCP, or external connector + +## Non-Negotiable Rules + +- Never print secret values. Surface only provider names, capability names, file paths, and whether a key or config exists. +- Prefer ECC-native workflows over generic "install another plugin" advice when ECC can reasonably own the surface. +- Treat external plugins as benchmarks and inspiration, not authoritative product boundaries. +- Separate three things clearly: + - already available now + - available but not wrapped well in ECC + - not available and would require a new integration + +## Audit Inputs + +Inspect only the files and settings needed to answer the question well: + +1. Repo surface + - `package.json`, lockfiles, language markers, framework config, `README.md` + - `.mcp.json`, `.lsp.json`, `.claude/settings*.json`, `.codex/*` + - `AGENTS.md`, `CLAUDE.md`, install manifests, hook configs +2. Environment surface + - `.env*` files in the active repo and obvious adjacent ECC workspaces + - Surface only key names such as `STRIPE_API_KEY`, `TWILIO_AUTH_TOKEN`, `FAL_KEY` +3. Connected tool surface + - Installed plugins, enabled connectors, MCP servers, LSPs, and app integrations +4. ECC surface + - Existing skills, commands, hooks, agents, and install modules that already cover the need + +## Audit Process + +### Phase 1: Inventory What Exists + +Produce a compact inventory: + +- active harness targets +- installed plugins and connected apps +- configured MCP servers +- configured LSP servers +- env-backed services implied by key names +- existing ECC skills already relevant to the workspace + +If a surface exists only as a primitive, call that out. Example: + +- "Stripe is available via connected app, but ECC lacks a billing-operator skill" +- "Google Drive is connected, but there is no ECC-native Google Workspace operator workflow" + +### Phase 2: Benchmark Against Official and Installed Surfaces + +Compare the workspace against: + +- official Claude plugins that overlap with setup, review, docs, design, or workflow quality +- locally installed plugins in Claude or Codex +- the user's currently connected app surfaces + +Do not just list names. For each comparison, answer: + +1. what they actually do +2. whether ECC already has parity +3. whether ECC only has primitives +4. whether ECC is missing the workflow entirely + +### Phase 3: Turn Gaps Into ECC Decisions + +For every real gap, recommend the correct ECC-native shape: + +| Gap Type | Preferred ECC Shape | +|----------|---------------------| +| Repeatable operator workflow | Skill | +| Automatic enforcement or side-effect | Hook | +| Specialized delegated role | Agent | +| External tool bridge | MCP server or connector | +| Install/bootstrap guidance | Setup or audit skill | + +Default to user-facing skills that orchestrate existing tools when the need is operational rather than infrastructural. + +## Output Format + +Return five sections in this order: + +1. **Current surface** + - what is already usable right now +2. **Parity** + - where ECC already matches or exceeds the benchmark +3. **Primitive-only gaps** + - tools exist, but ECC lacks a clean operator skill +4. **Missing integrations** + - capability not available yet +5. **Top 3-5 next moves** + - concrete ECC-native additions, ordered by impact + +## Recommendation Rules + +- Recommend at most 1-2 highest-value ideas per category. +- Favor skills with obvious user intent and business value: + - setup audit + - billing/customer ops + - issue/program ops + - Google Workspace ops + - deployment/ops control +- If a connector is company-specific, recommend it only when it is genuinely available or clearly useful to the user's workflow. +- If ECC already has a strong primitive, propose a wrapper skill instead of inventing a brand-new subsystem. + +## Good Outcomes + +- The user can immediately see what is connected, what is missing, and what ECC should own next. +- Recommendations are specific enough to implement in the repo without another discovery pass. +- The final answer is organized around workflows, not API brands.