{
  "manifest": {
    "id": "business-ops",
    "name": "Business Operations",
    "description": "Customer billing operations, automation auditing, unified notifications, and Google Workspace integration patterns",
    "version": "1.0.0",
    "author": "Adiuvo",
    "tags": [
      "billing",
      "automation",
      "notifications",
      "workspace",
      "ops"
    ],
    "icon": "",
    "created_at": "2026-06-11T01:40:46Z",
    "updated_at": "2026-06-11T01:40:46Z",
    "category": "",
    "pack_type": "operator",
    "required_mcp_servers": [],
    "optional_mcp_servers": [],
    "on_install": null,
    "procedure_count": 0,
    "context_file_count": 4,
    "always_loaded": false
  },
  "index": "# Business Operations\n\nBusiness operations patterns covering billing, automation, notifications, and workspace integration.\n\n## What's Included\n\n- **Customer Billing Ops** -- Customer billing workflows, invoice management, payment processing, and billing automation\n- **Automation Audit Ops** -- Automation system auditing, workflow verification, and operational compliance\n- **Unified Notifications Ops** -- Multi-channel notification delivery, template management, and notification preference handling\n- **Google Workspace Ops** -- Google Workspace API integration, Drive, Calendar, Gmail automation, and admin operations\n\n## When to Use\n\nActivate this pack when:\n- Building customer billing and invoicing systems\n- Auditing automation workflows for compliance\n- Implementing multi-channel notification systems\n- Integrating with Google Workspace APIs\n",
  "procedures": [],
  "commands": [],
  "context_files": [
    {
      "filename": "automation-audit-ops.md",
      "content": "---\nname: automation-audit-ops\ndescription: 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.\norigin: ECC\n---\n\n# Automation Audit Ops\n\nUse 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.\n\nThis 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.\n\n## Skill Stack\n\nPull these ECC-native skills into the workflow when relevant:\n\n- `workspace-surface-audit` for connector, MCP, hook, and app inventory\n- `knowledge-ops` when the audit needs to reconcile live repo truth with durable context\n- `github-ops` when the answer depends on CI, scheduled workflows, issues, or PR automation\n- `ecc-tools-cost-audit` when the real problem is webhook fanout, queued jobs, or billing burn in the sibling app repo\n- `research-ops` when local inventory must be compared against current platform support or public docs\n- `verification-loop` for proving post-fix state instead of relying on assumed recovery\n\n## When to Use\n\n- user asks \"what automations do I have\", \"what is live\", \"what is broken\", or \"what overlaps\"\n- the task spans cron jobs, GitHub Actions, local hooks, MCP servers, connectors, wrappers, or app integrations\n- the user wants to know what was ported from another agent system and what still needs to be rebuilt inside ECC\n- the workspace has accumulated multiple ways to do the same thing and the user wants one canonical lane\n\n## Guardrails\n\n- start read-only unless the user explicitly asked for fixes\n- separate:\n  - configured\n  - authenticated\n  - recently verified\n  - stale or broken\n  - missing entirely\n- do not claim a tool is live just because a skill or config references it\n- do not merge or delete overlapping surfaces until the evidence table exists\n\n## Workflow\n\n### 1. Inventory the real surface\n\nRead the current live surface before theorizing:\n\n- repo hooks and local hook scripts\n- GitHub Actions and scheduled workflows\n- MCP configs and enabled servers\n- connector- or app-backed integrations\n- wrapper scripts and repo-specific automation entrypoints\n\nGroup them by surface:\n\n- local runtime\n- repo CI / automation\n- connected external systems\n- messaging / notifications\n- billing / customer operations\n- research / monitoring\n\n### 2. Classify each item by live state\n\nFor every surfaced automation, mark:\n\n- configured\n- authenticated\n- recently verified\n- stale or broken\n- missing\n\nThen classify the problem type:\n\n- active breakage\n- auth outage\n- stale status\n- overlap or redundancy\n- missing capability\n\n### 3. Trace the proof path\n\nBack every important claim with a concrete source:\n\n- file path\n- workflow run\n- hook log\n- config entry\n- recent command output\n- exact failure signature\n\nIf the current state is ambiguous, say so directly instead of pretending the audit is complete.\n\n### 4. End with keep / merge / cut / fix-next\n\nFor each overlapping or suspect surface, return one call:\n\n- keep\n- merge\n- cut\n- fix next\n\nThe value is in collapsing noisy automation into one canonical ECC lane, not in preserving every historical path.\n\n## Output Format\n\n```text\nCURRENT SURFACE\n- automation\n- source\n- live state\n- proof\n\nFINDINGS\n- active breakage\n- overlap\n- stale status\n- missing capability\n\nRECOMMENDATION\n- keep\n- merge\n- cut\n- fix next\n\nNEXT ECC MOVE\n- exact skill / hook / workflow / app lane to strengthen\n```\n\n## Pitfalls\n\n- do not answer from memory when the live inventory can be read\n- do not treat \"present in config\" as \"working\"\n- do not fix lower-value redundancy before naming the broken high-signal path\n- do not widen the task into a repo rewrite if the user asked for inventory first\n\n## Verification\n\n- important claims cite a live proof path\n- each surfaced automation is labeled with a clear live-state category\n- the final recommendation distinguishes keep / merge / cut / fix-next\n"
    },
    {
      "filename": "customer-billing-ops.md",
      "content": "---\nname: customer-billing-ops\ndescription: 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.\norigin: ECC\n---\n\n# Customer Billing Ops\n\nUse this skill for real customer operations, not generic payment API design.\n\nThe 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?\n\n## When to Use\n\n- Customer says billing is broken, they want a refund, or they cannot cancel\n- Investigating duplicate subscriptions, accidental charges, failed renewals, or churn risk\n- Reviewing plan mix, active subscriptions, yearly vs monthly conversion, or team-seat confusion\n- Creating or validating a billing portal flow\n- Auditing support complaints that touch subscriptions, invoices, refunds, or payment methods\n\n## Preferred Tool Surface\n\n- Use connected billing tools such as Stripe first\n- Use email, GitHub, or issue trackers only as supporting evidence\n- Prefer hosted billing/customer portals over custom account-management code when the platform already provides the needed controls\n\n## Guardrails\n\n- Never expose secret keys, full card details, or unnecessary customer PII in the response\n- Do not refund blindly; first classify the issue\n- Distinguish among:\n  - accidental duplicate purchase\n  - deliberate multi-seat or team purchase\n  - broken product / unmet value\n  - failed or incomplete checkout\n  - cancellation due to missing self-serve controls\n- For annual plans, team plans, and prorated states, verify the contract shape before taking action\n\n## Workflow\n\n### 1. Identify the customer cleanly\n\nStart from the strongest identifier available:\n\n- customer email\n- Stripe customer ID\n- subscription ID\n- invoice ID\n- GitHub username or support email if it is known to map back to billing\n\nReturn a concise identity summary:\n\n- customer\n- active subscriptions\n- canceled subscriptions\n- invoices\n- obvious anomalies such as duplicate active subscriptions\n\n### 2. Classify the issue\n\nPut the case into one bucket before acting:\n\n| Case | Typical action |\n|------|----------------|\n| Duplicate personal subscription | cancel extras, consider refund |\n| Real multi-seat/team intent | preserve seats, clarify billing model |\n| Failed payment / incomplete checkout | recover via portal or update payment method |\n| Missing self-serve controls | provide portal, cancellation path, or invoice access |\n| Product failure or trust break | refund, apologize, log product issue |\n\n### 3. Take the safest reversible action first\n\nPreferred order:\n\n1. restore self-serve management\n2. fix duplicate or broken billing state\n3. refund only the affected charge or duplicate\n4. document the reason\n5. send a short customer follow-up\n\nIf the fix requires product work, separate:\n\n- customer remediation now\n- product bug / workflow gap for backlog\n\n### 4. Check operator-side product gaps\n\nIf the customer pain comes from a missing operator surface, call it out explicitly. Common examples:\n\n- no billing portal\n- no usage/rate-limit visibility\n- no plan/seat explanation\n- no cancellation flow\n- no duplicate-subscription guard\n\nTreat those as ECC or website follow-up items, not just support incidents.\n\n### 5. Produce the operator handoff\n\nEnd with:\n\n- customer state summary\n- action taken\n- revenue impact\n- follow-up text to send\n- product or backlog issue to create\n\n## Output Format\n\nUse this structure:\n\n```text\nCUSTOMER\n- name / email\n- relevant account identifiers\n\nBILLING STATE\n- active subscriptions\n- invoice or renewal state\n- anomalies\n\nDECISION\n- issue classification\n- why this action is correct\n\nACTION TAKEN\n- refund / cancel / portal / no-op\n\nFOLLOW-UP\n- short customer message\n\nPRODUCT GAP\n- what should be fixed in the product or website\n```\n\n## Examples of Good Recommendations\n\n- \"The right fix is a billing portal, not a custom dashboard yet\"\n- \"This looks like duplicate personal checkout, not a real team-seat purchase\"\n- \"Refund one duplicate charge, keep the remaining active subscription, then convert the customer to org billing later if needed\"\n"
    },
    {
      "filename": "google-workspace-ops.md",
      "content": "---\nname: google-workspace-ops\ndescription: 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.\norigin: ECC\n---\n\n# Google Workspace Ops\n\nThis skill is for operating shared docs, spreadsheets, and decks as working systems, not just editing one file in isolation.\n\n## When to Use\n\n- User needs to find a doc, sheet, or deck and update it in place\n- Consolidating plans, trackers, notes, or customer lists stored in Google Drive\n- Cleaning or restructuring a shared spreadsheet\n- Importing, repairing, or reformatting a Google Slides deck\n- Producing summaries from Docs, Sheets, or Slides for decision-making\n\n## Preferred Tool Surface\n\nUse Google Drive as the entry point, then switch to the right specialist:\n\n- Google Docs for text-heavy docs\n- Google Sheets for tabular work, formulas, and charts\n- Google Slides for decks, imports, template migration, and cleanup\n\nDo not guess structure from filenames alone. Inspect first.\n\n## Workflow\n\n### 1. Find the asset\n\nStart with the Drive search surface to locate:\n\n- the exact file\n- sibling assets\n- likely duplicates\n- recently modified versions\n\nIf several documents look similar, confirm by title, owner, modified time, or folder.\n\n### 2. Inspect before editing\n\nBefore making changes:\n\n- summarize current structure\n- identify tabs, headings, or slide count\n- detect whether the task is local cleanup or structural surgery\n\nPick the smallest tool that can safely perform the work.\n\n### 3. Edit with precision\n\n- For Docs: use index-aware edits, not vague rewrites\n- For Sheets: operate on explicit tabs and ranges\n- For Slides: distinguish content edits from visual cleanup or template migration\n\nIf the requested work is visual or layout-sensitive, iterate with inspection and verification instead of one giant blind update.\n\n### 4. Keep the working system clean\n\nWhen the file is part of a larger workflow, also surface:\n\n- duplicate trackers\n- outdated decks\n- stale docs vs canonical docs\n- whether the asset should be archived, merged, or renamed\n\n## Output Format\n\nUse:\n\n```text\nASSET\n- file name\n- type\n- why this is the right file\n\nCURRENT STATE\n- structure summary\n- key problems or blockers\n\nACTION\n- edits made or recommended\n\nFOLLOW-UPS\n- archive / merge / duplicate cleanup / next file to update\n```\n\n## Good Use Cases\n\n- \"Find the active planning doc and condense it\"\n- \"Clean up this customer spreadsheet and show me the churn-risk rows\"\n- \"Import this deck into Slides and make it presentable\"\n- \"Find the current tracker, not the stale duplicate\"\n"
    },
    {
      "filename": "unified-notifications-ops.md",
      "content": "---\nname: unified-notifications-ops\ndescription: Operate notifications as one ECC-native workflow across GitHub, Linear, desktop alerts, hooks, and connected communication surfaces. Use when the real problem is alert routing, deduplication, escalation, or inbox collapse.\norigin: ECC\n---\n\n# Unified Notifications Ops\n\nUse this skill when the real problem is not a missing ping. The real problem is a fragmented notification system.\n\nThe job is to turn scattered events into one operator surface with:\n- clear severity\n- clear ownership\n- clear routing\n- clear follow-up action\n\n## When to Use\n\n- the user wants a unified notification lane across GitHub, Linear, local hooks, desktop alerts, chat, or email\n- CI failures, review requests, issue updates, and operator events are arriving in disconnected places\n- the current setup creates noise instead of action\n- the user wants to consolidate overlapping notification branches or backlog proposals into one ECC-native lane\n- the workspace already has hooks, MCPs, or connected tools, but no coherent notification policy\n\n## Preferred Surface\n\nStart from what already exists:\n- GitHub issues, PRs, reviews, comments, and CI\n- Linear issue/project movement\n- local hook events and session lifecycle signals\n- desktop notification primitives\n- connected email/chat surfaces when they actually exist\n\nPrefer ECC-native orchestration over telling the user to adopt a separate notification product.\n\n## Non-Negotiable Rules\n\n- never expose tokens, secrets, webhook secrets, or internal identifiers\n- separate:\n  - event source\n  - severity\n  - routing channel\n  - operator action\n- default to digest-first when interruption cost is unclear\n- do not fan out every event to every channel\n- if the real fix is better issue triage, hook policy, or project flow, say so explicitly\n\n## Event Pipeline\n\nTreat the lane as:\n\n1. **Capture** the event\n2. **Classify** urgency and owner\n3. **Route** to the correct channel\n4. **Collapse** duplicates and low-signal churn\n5. **Attach** the next operator action\n\nThe goal is fewer, better notifications.\n\n## Default Severity Model\n\n| Class | Examples | Default handling |\n| --- | --- | --- |\n| Critical | broken default-branch CI, security issue, blocked release, failed deploy | interrupt now |\n| High | review requested, failing PR, owner-blocking handoff | same-day alert |\n| Medium | issue state changes, notable comments, backlog movement | digest or queue |\n| Low | repeat successes, routine churn, redundant lifecycle markers | suppress or fold |\n\nIf the workspace has no severity model, build one before proposing automation.\n\n## Workflow\n\n### 1. Inventory the current surface\n\nList:\n- event sources\n- current channels\n- existing hooks/scripts that emit alerts\n- duplicate paths for the same event\n- silent failure cases where important things are not being surfaced\n\nCall out what ECC already owns.\n\n### 2. Decide what deserves interruption\n\nFor each event family, answer:\n- who needs to know?\n- how fast do they need to know?\n- should this interrupt, batch, or just log?\n\nUse these defaults:\n- interrupt for release, CI, security, and owner-blocking events\n- digest for medium-signal updates\n- log-only for telemetry and low-signal lifecycle markers\n\n### 3. Collapse duplicates before adding channels\n\nLook for:\n- the same PR event appearing in GitHub, Linear, and local logs\n- repeated hook notifications for the same failure\n- comments or status churn that should be summarized instead of forwarded raw\n- channels that duplicate each other without adding a better action path\n\nPrefer:\n- one canonical summary\n- one owner\n- one primary channel\n- one fallback path\n\n### 4. Design the ECC-native workflow\n\nFor each real notification need, define:\n- **source**\n- **gate**\n- **shape**: immediate alert, digest, queue, or dashboard-only\n- **channel**\n- **action**\n\nIf ECC already has the primitive, prefer:\n- a skill for operator triage\n- a hook for automatic emission/enforcement\n- an agent for delegated classification\n- an MCP/connector only when a real bridge is missing\n\n### 5. Return an action-biased design\n\nEnd with:\n- what to keep\n- what to suppress\n- what to merge\n- what ECC should wrap next\n\n## Output Format\n\n```text\nCURRENT SURFACE\n- sources\n- channels\n- duplicates\n- gaps\n\nEVENT MODEL\n- critical\n- high\n- medium\n- low\n\nROUTING PLAN\n- source -> channel\n- why\n- operator owner\n\nCONSOLIDATION\n- suppress\n- merge\n- canonical summaries\n\nNEXT ECC MOVE\n- skill / hook / agent / MCP\n- exact workflow to build next\n```\n\n## Recommendation Rules\n\n- prefer one strong lane over many weak ones\n- prefer digests for medium and low-signal updates\n- prefer hooks when the signal should emit automatically\n- prefer operator skills when the work is triage, routing, and review-first decision-making\n- prefer `project-flow-ops` when the root cause is backlog / PR coordination rather than alerts\n- prefer `workspace-surface-audit` when the user first needs a source inventory\n- if desktop notifications are enough, do not invent an unnecessary external bridge\n\n## Good Use Cases\n\n- \"We have GitHub, Linear, and local hook alerts, but no single operator flow\"\n- \"Our CI failures are noisy and people ignore them\"\n- \"I want one notification policy across Claude, OpenCode, and Codex surfaces\"\n- \"Figure out what should interrupt versus land in a digest\"\n- \"Collapse overlapping notification PR ideas into one canonical ECC lane\"\n\n## Related Skills\n\n- `workspace-surface-audit`\n- `project-flow-ops`\n- `github-ops`\n- `knowledge-ops`\n- `customer-billing-ops` when the notification pain is billing/customer operations rather than engineering\n"
    }
  ]
}