Claude Skills by WYRE-AI

Partner-level Blackpoint Cyber (CompassOne) operations: the partner-tenant hierarchy, enumerating customer tenants, sweeping detections and vulnerabilities across all of them, spotting volume anomalies, and building per-tenant scorecards.

Blackpoint Cyber (CompassOne) exposure data across four lenses: host vulnerability findings and the filters that matter (CVE, severity, patch and exploit availability), scan history, dark-web credential and data leaks, and internet-facing external exposures — plus how to combine them into a prioritized remediation view.

Blumira agents (sensors) and the devices they run on: device inventory and filtering, agent health via last-seen timestamps, and agent deployment keys.

Blumira REST API fundamentals: JWT authentication, the dual `/org/*` vs `/msp/*` path structure, suffix-based filter operators, pagination parameters and response metadata, the stateful MCP navigation tools, and HTTP error causes.

The Blumira finding lifecycle: status and severity codes, resolution types, list filtering, enriched detail retrieval, assignment, and comment threads.

Blumira's MSP path group (`/msp/*`): managed-account enumeration, cross-account and per-account finding queries, per-account device, agent-key and user management, and how MSP paths differ from org paths.

Blumira resolution types (Valid, Not Applicable, False Positive): how to choose between them, their effect on security metrics and detection tuning, and the org- and MSP-level resolve calls.

Blumira organization users: listing and filtering users, user roles, and looking up the user IDs required for finding assignment and access audits.

CIPP's read-only alerting and audit surface: the cross-tenant alert queue, tenant-scoped M365 unified audit log queries, the audit operations worth filtering on during a compromise investigation, and audit lag/retention behavior.

Tenant-scoped Entra/M365 group enumeration and creation in CIPP, the four group types (Security, Microsoft 365, Distribution, Mail-Enabled Security) and when to pick each, and the boundary where CIPP's group surface ends and Graph/M365 takes over.

Read-only M365 license visibility through CIPP: per-tenant SKU purchase vs. consumption, portfolio-wide CSP license commitments, common SKU part numbers and their friendly names, and the license-mix red flags that drive rightsizing and billing reconciliation.

The four Exchange Online mailbox operations CIPP exposes — mailbox inventory, delegate/full-access permission audit, out-of-office, and email forwarding — plus the BEC-remediation, offboarding, and leave-coverage sequences built from them.

CIPP's own operational layer rather than the tenants it manages: GDAP role definitions and pending invites, the CIPP scheduler, and the ping/version/log endpoints used to diagnose why other CIPP tools fail silently.

Read-only access to a tenant's Conditional Access policy graph and named locations through CIPP: policy state semantics, the findings that matter in a CA review, portfolio drift detection, and why CA writes are absent from the MCP surface.

CIPP's tenant-baseline enforcement model: the Report/Alert/Remediate standards modes and how to roll them out, on-demand standards evaluation, Best Practice Analyser reports, and SPF/DKIM/DMARC domain health results with their remediation actions.

The top-level CIPP scope: enumerating managed M365 tenants, retrieving tenant detail, and the accepted `tenantFilter` identifier formats (default domain, custom domain, GUID, `allTenants`). Also covers stale-cache detection and the two common tenant-resolution failure modes.

The full multi-tenant M365 user lifecycle in CIPP: create/edit/disable, password and MFA resets, session revocation, the bundled offboarding call, BEC investigation reports, MFA gap reporting, and device/group lookups — plus the ordering constraints that make each sequence correct.

Clio Manage MCP fundamentals: OAuth 2.0 Authorization Code connection via Conduit, region selection, the matters-as-hub data model, decision-tree tool navigation, pagination, and the deliberate v1 scope limits (no delete anywhere, documents metadata-only, communications/calendar/bills read-only).

Clio contacts -- the people and companies connected to matters: person vs. company contact types, and how a contact relates to the matters they are party to (client, opposing party, witness, and other roles).

Clio matters -- the case/client-file object that almost everything else in Clio hangs off of: the matter status lifecycle, linking a matter to a client contact, practice areas, custom fields, and matter numbering.

Clio time and expense activities logged against a matter: the activities domain's create-only lifecycle, the billing-read / time-entry-write split, and why billing mutations are out of scope for v1.

Right-sizing and capacity forecasting for cloud resources on whatever platforms (Azure, DigitalOcean) are connected: the per-platform over-provisioned and under-provisioned signals, growth-trend-based forecasting toward a projected exhaustion window, and the discipline that separates a genuine capacity risk from normal variance — require a trend not a spike, distinguish burst-tolerant from sustained-critical resources, and always state the observation window behind a forecast.

Cloud spend anomaly detection and reclaimable-spend hunting on whatever platforms (Azure, DigitalOcean) are connected: the signals that make a spend increase an anomaly rather than expected cost, the per-platform orphaned/idle resource catalog (unattached storage, idle load balancers, stopped-but-not-deallocated compute, idle managed databases, orphaned network resources), and how to build a monthly cost trend view — or a clearly labeled inventory-and-list-pricing estimate when a platform exp...

A normalized device and network health sweep across whatever network-monitoring tools (Auvik, Meraki, Domotz) are connected: each vendor family's data model and native status fields mapped into one Down/Degraded/Unknown/Healthy taxonomy, default interface error and utilization thresholds, topology-change detection, and why an offline Domotz collector renders its devices "unknown" rather than "down".

Tracing a compliance control (CIS, SOC 2, HIPAA, or a cyber-insurance questionnaire line item) to concrete, retrievable tool evidence: which vendor family can observe what — CIPP for live M365/Entra configuration, Liongard for point-in-time infrastructure state, IT Glue/Hudu for documentation — a representative control-to-tool-call map, and the evidentiary weights that separate Configured from Documented, Contradicted, and Unable to Verify.

Drafting tool-verified answers to cyber-insurance renewal, new-business, and underwriter security questionnaires: the standard recurring question set (MFA everywhere including privileged accounts, EDR coverage ratio, tested and immutable backups, documented and tested IR plan, security awareness training), which connected tools actually answer each one, and the evidence-backed / documented-only / unable-to-verify labeling discipline that keeps an answer defensible during a claim investigation.

Detecting configuration drift against an established baseline: CIPP standards checks and Best Practice Analyser results, Liongard change detections and inspection timelines, the three conditions that make a diff real drift rather than noise, the signals that separate intentional or authorized change from unauthorized weakening (ticket correlation, reversion pattern, direction of change), and the priority order for ranking several drift findings at once.

ConnectWise Automate alert management: alert sources (monitors, scripts, events), severity levels, lifecycle states, acknowledgment, resolution, history tracking, and PSA ticket creation from alerts.

ConnectWise Automate REST API fundamentals: integrator and user+2FA authentication, token lifecycle, pagination, OData-style filtering, rate limiting, and error handling patterns for API integration.

ConnectWise Automate client management: client CRUD, client identifiers, locations, client hierarchy, groups, extra data fields (EDFs), and client-level settings.

ConnectWise Automate computer/endpoint management: computer identifiers (ComputerID, Name, ComputerGUID, MAC), status values, OS types, hardware/software inventory, disk, patch, and antivirus status, plus remote management operations.

ConnectWise Automate monitor management: monitor types (internal, remote, agent, SNMP, script), categories, threshold configuration, templates, assignment methods (computer/group/client), and status evaluation.

ConnectWise Automate script management: script types (PowerShell, batch, VBScript, Shell), script folders, script execution on computers, parameter handling and validation, execution status polling, and result/history retrieval.

ConnectWise CPQ (Sell/Quosal) API fundamentals: three-part Basic auth built from an access key plus an API key pair, the versioned content type, the flat 25-tool `cpq_*` surface, Manage-style `conditions` filtering, `includeFields` trimming of the 200+ property views, page/pageSize paging over bare arrays, RFC 6902 JSON Patch updates, and the endpoints CPQ deliberately does not expose.

ConnectWise CPQ line items and the tabs that hold them: searching items by quote or tab, the tab requirement on every create, the pricing and margin fields, bundle and optional-line flags, recurring-revenue and PSA mapping fields, JSON Patch updates, and why there is no product catalog to search.

The ConnectWise CPQ quote lifecycle over the real tool surface: searching quotes, the GUID-vs-quoteNumber dual addressing, versions, creating quotes by copying a template (the API's only create path), patching quote fields, the per-quote customer records and payment/financing terms, tabs as the section structure, and the deletes that cascade.

ConnectWise PSA REST API fundamentals: public/private key + clientId authentication, page/pageSize pagination, the conditions query syntax, rate limiting (60/min), and error-response handling.

ConnectWise PSA company/account management: company types, statuses, sites/locations, custom fields, and company relationships. Essential for MSP account management and CRM operations in ConnectWise PSA.

ConnectWise PSA contact management: contact records, contact types, communication items (email, phone), portal access, and relationships to companies. Essential for MSP customer relationship management in ConnectWise PSA.

ConnectWise PSA product catalog: catalog items (SKUs), categories, subcategories, manufacturers, and their use on quotes, opportunities, agreements, and tickets. Covers the full catalog item field reference, common MSP workflows (hardware SKU, software license, managed service, agreement add-on), and the passthrough pattern for fields not surfaced on the MCP tool directly.

ConnectWise PSA project management: project lifecycle and status/type values, phases, templates, resource/team allocation, budgeting, billing methods, and project tickets.

ConnectWise PSA ticket management: ticket fields, service boards, statuses, priorities, SLAs, ticket notes, and workflow automation. Essential for MSP technicians handling service delivery through ConnectWise PSA.

ConnectWise PSA time entry management: charge-to types (tickets, projects, charge codes), billable vs non-billable time, work types and work roles, time sheets, and the time entry approval workflow.

Crewhu MCP fundamentals: token authentication via the `X-Crewhu-Api-Token` header and its gateway env-var mapping, the flat 18-tool surface across the surveys, users, badges, and prizes domains (only `crewhu_badges_update_contest` writes), pagination, and error codes.

Crewhu CSAT/NPS survey data: the list/search/get tools and the detractor/promoter sentiment slices, the trend, detractor-follow-up, promoter-recognition and per-tech roll-up workflows, and the edge cases that skew scores — sparse response counts, comment-only feedback, and tenant-local timestamps.

Error-budget and burn-rate assessment from whatever observability tools (Sentry, Datadog, Grafana, BetterStack) are connected: SLI, SLO, error budget, and burn rate applied practically, how to compute burn rate from available SLI data and the thresholds that make it actionable, what separates a budget-threatening trend from noise, and the fallback to raw trend reporting against a trailing baseline when no formal SLO is defined.

Assembling a blameless postmortem grounded in systems of record: timeline reconstruction merging the incident tool's event log with correlated observability anomalies (Sentry error spikes, Datadog/Grafana metric anomalies, including precursor signal that predates formal detection) and deploy history from connected platform connectors, all normalized to one stated timezone; the root-cause versus contributing-factor distinction and the test for telling them apart; and how to label a root cause ...

Assembling an on-call shift handoff from whatever incident-management tool (Rootly, PagerDuty, BetterStack) is connected, plus corroborating observability signal where available: the four handoff categories in priority order (currently paging, escalated without an owner, last-shift history, known-flaky watch list), why an empty open-incidents list is not an empty handoff, and the bar for calling an alert known-flaky rather than simply resolved.

Domotz agents (collectors/probes) as the per-site entry point for all device and network operations: agent types, lifecycle, ONLINE/OFFLINE status, the list/get tools and their license and last-seen fields, and fleet health, site inventory, and capacity-planning workflows.

Domotz alerting configuration: what an alert profile defines, the two tools that read profiles and their per-device bindings, monitoring coverage audits, and the important limit — this server exposes alert configuration only, never fired alerts.