Claude Skills by WYRE-AI

Running NetSuite's standard and custom reports and saved searches, plus the filter-lookup helpers (accounting books, accounting contexts, nexuses, subsidiaries) many of them need. Read-only — running existing reports and searches, not building or editing them.

Running read-only SuiteQL queries against NetSuite data and discovering queryable fields and joins via SuiteQL metadata. The flexible ad-hoc query surface for questions no existing report or saved search already answers.

NinjaOne alerts and the conditions behind them: retrieving device alerts, dismissing individual alerts and bulk resets, alert summaries, severity and priority levels, common hardware/service/security/connectivity alert types and thresholds, alert webhooks, and triage workflows.

NinjaOne Public API fundamentals shared by every other NinjaOne skill: regional base URLs, OAuth 2.0 client-credentials auth and scopes, request shapes, cursor-based pagination, rate-limit headers and 429 handling, HTTP status codes and error response format, and webhook configuration.

NinjaOne device management: device details and updates, Windows service control, inventory, maintenance windows, reboot modes, and health-check workflows for Windows, Mac, and Linux endpoints running the NinjaRMM agent.

NinjaOne organizations — the top-level container for devices, representing MSP clients: creation and listing, locations, node approval modes, policy mappings and node role IDs, custom fields, tags, cursor pagination, and error codes.

NinjaOne's built-in ticketing system, which integrates with device monitoring: ticket creation and updates, core/status/metadata fields, status and priority values with SLA targets, log entry types, device linkage, tagging patterns, and error codes.

Nutanix MCP fundamentals: the discovery-driven tool surface (4 discovery tools plus one `<namespace>_execute` tool per v4 API namespace — not per-entity CRUD tools), the listOperations → getOperationSchema → execute workflow, Conduit gateway credential configuration for Prism Central, OData query parameters, the read-only enforcement mode, and namespace availability rules.

Working the clustermgmt namespace through `clustermgmt_execute` — cluster and host inventory, configuration and health state — plus the adjacent read surfaces: `prism_execute` for Prism Central tasks and categories, and `lifecycle_execute` for LCM upgrade inventory and recommendations.

The Nutanix operational-intelligence read surface: `monitoring_execute` for alerts, alert policies, events, and audit logs, and `aiops_execute` for capacity planning, VM rightsizing recommendations, and workload performance analysis — the namespaces behind health checks and capacity reports.

The Nutanix networking read surface: `networking_execute` for AHV network configuration (subnets, VPCs, vSwitch, BGP — coverage varies by artifact set, down to a minimal capabilities/AWS-VPC slice) and `microseg_execute` for Flow Network Security policies, service groups, and address groups.

The Nutanix storage read surface across four namespaces: `storage_execute` for storage containers and volume groups, `volumes_execute` for iSCSI / NVMe-TCP volume group attachment state, `objects_execute` for the S3-compatible object store, and `files_execute` for virtual file servers and NFS/SMB shares — capacity, configuration, and attachment queries.

Working the vmm namespace through `vmm_execute`: VM inventory and lookup on AHV clusters, resolving names to extId UUIDs, reading VM configuration (disks, NICs, GPUs, power state), OData filters for VM queries, and the read-only boundaries around VM lifecycle actions.

Board-wide ticket maintenance, distinct from working any single ticket: stale-ticket detection with per-status staleness thresholds, the Waiting-on-Client rot case and its three valid resolutions, duplicate/related-ticket detection signals and safe linking, and technician queue-balance assessment weighted by more than raw ticket count.

Priority scoring and assignment for an unassigned PSA ticket queue: the scoring factors (SLA proximity, client tier, ticket age, technician load, skill/category match), how to combine them into an explainable ranked order rather than a black-box formula, and the tool-discovery pattern for finding which PSA and RMM connectors are actually live before calling any vendor's tools.

A cross-PSA escalation framework for SLA pressure: how each PSA family (Autotask, HaloPSA, ConnectWise Manage, Syncro, Kaseya BMS) models SLA/priority state and where breach risk lives in each, a normalized breach-risk state model (healthy, at risk, breached-response, breached-resolution) with the default escalation action per state, how notification audience shifts by contract tier, and the evidence to gather before paging anyone.

PagerDuty alerts: the alert-vs-incident model, alert statuses, grouping modes, event rules for routing and suppression, dedup_key deduplication, and the Events API v2 trigger/acknowledge/resolve payloads.

PagerDuty Analytics: MTTA/MTTR/MTTE/MTTS definitions, incident and interruption counts, aggregation levels (account, service, team, escalation policy), time-range constraints, and benchmark tables for interpreting the numbers.

PagerDuty API and hosted MCP fundamentals: US/EU MCP endpoints, the `Token token=` auth header and token types, the complete 66-tool reference across 13 categories (incidents, on-call, schedules, escalation policies, services, event orchestrations, status pages, teams, users, and more), offset pagination, common filter parameters, rate limits, and error codes.

PagerDuty incident lifecycle (triggered/acknowledged/resolved), urgency vs. priority, alerts-to-incident grouping, the 14 incident MCP tools, incident fields, notes, log entries, past-incident similarity search, merge and snooze semantics, and cross-vendor PSA ticket correlation for MSPs.

PagerDuty on-call model: schedules with rotation layers, restrictions, the computed final schedule, and overrides; escalation policy tiers and timeouts; on-call entry fields; and the schedule, escalation policy, and team MCP tools.

PagerDuty service catalog: service statuses, integrations and integration keys as event sources, alert grouping modes, upstream/downstream service dependencies, and maintenance windows.

PandaDoc hosted MCP server and API fundamentals: API-key authentication and which operations work without a key, the complete MCP tool catalog (documents, templates, recipients, docs search, code samples), page-based pagination, document and template filters, rate limits per plan, and error codes.

PandaDoc document lifecycle end to end: creating documents from templates, sending for e-signature, status checks and PDF downloads, the full document status enum, MSP document types, content tokens, pricing-table structure, document and recipient fields, and status-transition errors.

MSP proposal workflows in PandaDoc: proposal types and typical values (MSA, SOW, hardware quote, project proposal, security assessment, cloud migration), the standard MSP content-token set, managed-services and hardware pricing-table structures, mapping document statuses to sales-pipeline stages, and pipeline and stale-proposal tracking.

PandaDoc recipients and e-signature mechanics: recipient roles (signer, approver, viewer, CC), signing-order behavior, multi-party MSP signing scenarios, completion tracking via `has_completed`, recipient fields, and the document statuses that restrict adding or changing recipients.

PandaDoc template library and structure: layout, content blocks, tokens, interactive fields, signature fields, pricing tables, and recipient roles, plus the MSP template set (MSAs, SOWs, proposals, quotes, NDAs, change orders, QBRs), template versioning, tags, and the template field reference.

Pax8 MCP fundamentals: the official hosted MCP server connection, all 15 Pax8 MCP tools and their parameters, pagination, sorting, filtering, response shapes, rate limiting, and error handling.

Pax8 companies (MSP clients): company records and fields, contact management, billing and order-approval settings, and cross-referencing companies with subscriptions and orders.

Pax8 invoices and billing: invoice retrieval, invoice line items, usage-based billing summaries, the MSP billing cycle, and reconciling Pax8 costs against client charges.

Pax8 orders: order retrieval, order line items, provisioning status and timelines, billing terms, and the order-to-subscription workflow.

The Pax8 product catalog: cloud software SKUs, vendors, pricing tiers and margins, and provisioning details across Microsoft 365, Azure, security tools, and backup products.

Pax8 subscriptions: license and seat counts, the full subscription lifecycle and its states, change history, filtering by company or product, and quantity management for license optimization.

PostHog API fundamentals for this plugin: personal API key auth brokered through Conduit (no local key), the resource:action scope model, generic REST error handling, and why this plugin's read-only posture rests on the key's own scopes alone — Conduit has no gateway-side fallback for this vendor.

PostHog cohorts (saved user/group segments), raw analytics events, and timeline annotations. Read-only lookups — listing and retrieving existing records, not defining new segments or emitting events.

Read-only lookups of PostHog early-access feature flags and experiments — rollout status, targeting, and configuration. Does not create, update, or delete flags or experiments.

PostHog saved insights (trends, funnels, retention, and similar analytics queries) and the dashboards that group them into a single view. Read-only: running and retrieving existing insights and dashboards, not authoring them.

QuickBooks Online API fundamentals: OAuth2 authentication and token lifecycle, REST structure and base URLs, the Intuit query language, pagination, minor version headers, SyncToken optimistic locking, rate limits, webhooks, and the Fault error object format.

QuickBooks Online Customer entity: the parent/sub-customer (job) hierarchy, contact, address, billing and hierarchy fields, payment terms, balance and BalanceWithJobs tracking, sparse updates, deactivation, query syntax, error codes, and PSA cross-referencing patterns for MSP client records.

QuickBooks Online expense entities: Purchase (check, cash, credit card), Bill for accounts payable, BillPayment, and Vendor. Covers account-based vs item-based expense lines, per-client cost allocation via CustomerRef and BillableStatus, expense categorization, query syntax, error codes, and MSP profitability analysis patterns.

QuickBooks Online Invoice entity: invoice lifecycle and statuses, line item detail types, service items, payment terms, email delivery and PDF retrieval, invoice numbering, void vs delete semantics, query syntax, error codes, and MSP billing patterns such as monthly managed services, project, and time-and-materials invoicing.

QuickBooks Online payment handling: recording customer payments and applying them to invoices, partial and multi-invoice application, unapplied amounts and overpayments, credit memos and refund receipts, payment methods, deposit accounts, voiding, and reconciliation.

QuickBooks Online financial reporting: the report catalog (Profit & Loss, Balance Sheet, A/R and A/P Aging, General Ledger, Customer Sales, Cash Flow, Tax Summary), report parameters, date macros, column customization, the nested row response structure, and MSP analysis patterns like client profitability and aged receivables for collections.

Rootly's alerting layer between monitoring tools and incident management: alert sources and integrations (Datadog, PagerDuty, New Relic, Grafana), routing rules, escalation policies and their acknowledgement windows, suppression, and the conditions under which an alert auto-creates an incident.

The Rootly hosted MCP server and the JSON:API REST surface behind it: Global vs. Team token types and how the gateway injects credentials, the catalog of 25 dynamically generated tools by category, page-number pagination and relationship includes, filter syntax, rate limits, and error handling.

Incidents, Rootly's primary resource: the incident lifecycle and status transitions, severity levels, the incident field reference, AI-assisted analysis via find_related_incidents and suggest_solutions, action items, alert attachment, and cross-vendor PSA ticket correlation.

Rootly on-call visibility built on the get_oncall_handoff_summary, get_oncall_shift_metrics, get_shift_incidents, and check_oncall_health_risk tools: schedule and rotation coverage, structured shift handoffs, per-shift incident scoping, shift metric fields, and the burnout risk signals.

Rootly postmortems as structured post-incident retrospectives: the postmortem lifecycle, templates and automatic timeline import, action item creation and tracking through to project-management tools, and the blameless review practices Rootly's model assumes.

The Rootly service catalog: tier classification by business criticality, the ownership attributes attached to each service (team, Slack channel, escalation policy, runbooks), upstream/downstream dependency modeling for blast-radius analysis, service CRUD, and how services link back to incidents and alerts.

Rootly's incident-response automation model: the trigger / condition / action structure, the full catalog of trigger, action, and condition types, workflow CRUD and enable/disable, and the failure modes behind stale, over-firing, or circularly chained workflows.