api-patterns
3CX's native PBX MCP server: the per-PBX endpoint shape (every PBX is its own FQDN and its own OAuth authorization server — there is no shared mcp.3cx.com),…
Phishing-simulation campaign analysis: click-rate trend direction across campaigns, repeat-clicker identification with remedial-training cross-reference, and optional enrichment that correlates simulated failures with real-world phishing incidents from a connected email-security
$ npx -y skills add wyre-technology/msp-claude-plugins --skill phishing-simulation-analysis --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/phishing-simulation-analysisContext preview
The summary Claude sees to decide when to auto-load this skill.
Phishing-simulation campaign analysis: click-rate trend direction across campaigns, repeat-clicker identification with remedial-training cross-reference, and optional enrichment that correlates simulated failures with real-world phishing incidents from a connected email-security
name: "Phishing Simulation Analysis" description: > Phishing-simulation campaign analysis: click-rate trend direction across campaigns, repeat-clicker identification with remedial-training cross-reference, and optional enrichment that correlates simulated failures with real-world phishing incidents from a connected email-security tool as a compounding risk signal. when_to_use: >- When reviewing phishing simulation results, click-rate trends, or identifying repeat clickers. Use when: phishing simulation results, click rate, repeat clickers, phishing test analysis, who keeps clicking phishing tests, simulation trend, phishing campaign performance.
A phishing-simulation campaign is only as useful as the trend and pattern analysis built on top of its raw click data. A single campaign's click rate tells you almost nothing on its own; the trend across campaigns, and which specific users click repeatedly, are what actually drive training prioritization. This skill covers how to build that analysis across whatever simulation platform is connected, and how to optionally enrich it with real-world phishing-incident data when a technical security tool is also available — treating that enrichment as a bonus, never a requirement.
recipient tracking, and phish-prone percentage are the vendor's surface; use `knowbe4-phishing`.
Attacked People reports and attack-index scoring describe genuine inbound campaigns; use `proofpoint-people`. This skill reasons about controlled tests, and never merges the two into one click rate.
Call `conduit__search_tools` for phishing-simulation and click-data tools before assuming a specific vendor. KnowBe4 is the primary simulation platform in this marketplace. Proofpoint (`proofpoint__list_vap_users` and related tools) and Checkpoint Avanan (`avanan__list_threats` and related tools) both carry phishing-click or "Very Attacked Person" style signal alongside their core email-security function — where connected, they are secondary/optional sources of real-world click and attack-targeting data, not replacements for a dedicated simulation platform's controlled test results. Simulated-click data (from a simulation platform) and real-click data (from an email-security tool) are different things; never merge them into one number without labeling which is which.
Pull click rate per campaign, ordered chronologically, and report the trend direction (improving, flat, worsening) rather than a single snapshot number. A 12% click rate is meaningless without knowing whether last quarter's was 8% or 20%. Where the platform supports it, break the trend down by org and by training-module topic (e.g. invoice fraud vs. credential harvest) — a flat overall trend can hide a specific topic that's getting worse.
A repeat clicker is a user who has clicked (or otherwise failed — entered credentials, opened an attachment) more than one simulated-phishing campaign, especially across consecutive campaigns or within a short window. Repeat clickers are the highest-value population for this skill to surface: they represent concentrated risk that a blended org-level click rate dilutes into invisibility. Report:
consequence of prior failures (cross-reference with `training-completion-tracking` — a repeat clicker who also hasn't completed remedial training is a distinct, higher-priority case from one who clicked but did complete the follow-up training)
Where a technical email-security or incident-response tool is connected (e.g. via secops-pack's stack — Proofpoint, Avanan, Mimecast, Abnormal, Ironscales, SpamTitan, or CIPP for M365 sign-in/mailbox-rule signals), check whether any repeat clicker also appears in real-world phishing-related findings: an actual credential-harvest click, a BEC-pattern indicator, or an account-compromise signal tied to the same user. A user who repeatedly clicks simulated phishing *and* has a real security incident on record is a compounding risk signal worth flagging distinctly and prominently — but this correlation step is enrichment, not a requirement. Do not treat the absence of a connected incident-response tool as a reason to skip or degrade the core simulation analysis; simply note that real-incident correlation wasn't available. This skill does not perform incident response itself — if a real incident is found during this correlation step, hand off detection/response detail to secops-pack's `bec-response` or `containment-playbooks` skills where that pack is installed, rather than duplicating that logic here.
1. Discover the connected simulation platform(s) via `conduit__search_tools`. 2. Pull campaign history per client, ordered chronologically, with per-org click/fail rate. 3. Compute trend direction per client (improving / flat / worsening) across at least the last 3 campaigns where available; note when fewer than 3 campaigns exist and the trend is therefore low-confidence. 4. Rank clients by worst current click rate and by worsening trend separately — a client with a low but worsening rate deserves different attention than one with a high but improving rate.
1. Pull per-user click/fail history across all available campaigns for the client or portfolio in scope. 2. Identify users with 2+ failures, sorted by failure count then recency. 3. Cross-reference remedial-training compl
One command to supercharge Claude Code for MSP workflows. Then restart Claude Code. That's it. Documentation: mcp.wyre.ai
Repo: wyre-technology/msp-claude-plugins
3CX's native PBX MCP server: the per-PBX endpoint shape (every PBX is its own FQDN and its own OAuth authorization server — there is no shared mcp.3cx.com),…
3CX's live-operations surface: read-only visibility into active calls, recordings, voicemail, department and queue membership, and forwarding/presence…
3CX's read-only directory surface: resolving a caller by email or by exact extension, searching the PBX's own phonebooks, searching contacts synced from an…
3CX's system-and-configuration surface: server time, PBX event log and application log search, service status, database schema and the read-only SELECT-only…
Abnormal Security abuse mailbox cases: user-reported email submissions, case statuses and judgments, the case lifecycle, bulk and remediation actions, and…
Abnormal Security message analysis: message retrieval, email header inspection, attachments, sender reputation, delivery context, and SPF/DKIM/DMARC…