We build with AI, in the open

Software Brain

The engine behind everything on this page.

A conversation-first, memory-bearing, tool-using AI architecture modeled on neurological principles, built as a TypeScript monorepo and reachable at brain.xl.net. A handful of services sit over a shared core of orchestrator, memory, providers and auth, with SDKs for callers in other repositories. Every other exhibit below either runs on it or was built with it, and on the days it has taken one of them down, the incident is written into the same documents as the design.

A release is not done when the code works. A layered QA harness runs from unit checks up through browser and restart runs, the security scan has to come back with zero findings straight after it, and the written definition of done carries a clause most specifications do not: the document must not overstate guarantees relative to the code. Nothing a visitor reads is assembled, either: no canned replies, no pattern-matched answers, no template acknowledgements anywhere in the response path. It also strips em dashes from its own writing, twice over, because someone here objects to them.

TypeScript monorepo · scoped memory with validity dates · Deepgram in, spoken reply out · one rebuild-ready master document · doc-before-code enforced at commit · layered QA, then a clean security scan · brain.xl.net

ai.xl.net

The site you're reading right now: our maximum-oversight deployment.

This page, the chat widget in the corner, and the number and mailbox Tron Netter answers on are one application on one VM behind a Cloudflare tunnel. No load balancer, no container runtime, no managed cloud database: a web server, a process manager, Postgres and the tunnel. What is worth showing is not the stack but the constraints, which are written down as invariants a rebuild may not drop, beside the note of the day one of them turned out to be only half true.

Memory follows the same posture. An anonymous conversation is not stored at all, what a signed-in or phone-verified person tells it stays private to them, and a sweep runs before and after every remembering turn to invalidate any fact that tried to write itself public, because a stranger planting a memory every visitor could read is the interesting failure here. Texting the word FORGET erases that number's memories outright. The exhibits on this page are written into the application itself, so an unreachable database costs the cards submitted by the team and nothing else. Try it: chat, text, email, or call Tron Netter on this page.

human copy on every outbound email · tools disabled fail-closed · nightly crawl, replaced not appended · anonymous turns unstored · FORGET erases a number · one VM behind a Cloudflare tunnel

IT Support Chicago

A ranking site that runs itself, published by a firm that appears on its own list.

itsupportchicago.net ranks Chicago managed IT providers against a scoring formula it publishes in full, built from third-party data, with the worked arithmetic and the evidence shown on every vendor page. It is free, nothing on it can be bought, and it is almost entirely operated by AI agents: collection, scoring, drafting and review run without a person in the chair. Maximum oversight on this site, near-total delegation on that one. We run both on purpose, because the question worth answering is where the line falls.

The sandbox is built to let all of that fail safely. Its own cloud project, a confidential virtual machine with encrypted memory and verified boot, no external address, and a firewall that denies inbound traffic outright: visitors arrive through a tunnel the box opens from the inside. A watchdog checks the services every minute and restarts what died, security patches land unattended overnight, and the backups are not taken on faith. They are restored into a scratch database on a schedule and counted, on the principle its documentation states plainly: a backup that cannot be restored is not a backup.

published formula, shown arithmetic · common ownership disclosed on the site · frozen copy no agent may touch · outreach drafted, a person sends · confidential VM, deny-all inbound · restore-tested backups

Leo Netter

A teammate in Slack, with most of what it could reach deliberately switched off.

Leo Netter is a conversation-first, memory-bearing assistant for the XL.net team, built on the Software Brain and described by its own documents as the slow and deliberate successor to the sales assistant it replaced. That handover is finished and it answers in Slack every working day. The part worth exhibiting is the restraint around it: nearly every lane this thing could speak on is built, tested, and dark until a person names what it may touch.

Memory is classified one turn at a time into private to the person, shared with the team, or public, and anything short of a confident call files the fact as private, because over-scoping is the mistake you can recover from. Two people's private memories cannot surface in each other's conversations, and a channel writes nothing durable at all. The test list works like the architecture: a defect becomes a numbered entry before anyone writes the fix, and a closed one is marked resolved rather than deleted, so what went wrong stays in the document that specifies what replaced it.

Slack first, every other lane dark by default · read-only business tools · two steps and a human click to send mail · over-scope to private when unsure · doc before code, enforced at commit · append-only test list

Your AI Roadmap

A company's own roadmap, from a governance document on file to a scorecard of its builders.

A client company gets its own private corner of ai.xl.net, free, keyed to the domain of its work email. The steps sit on one line, from an AI governance document on file through the work its own people build to the platform, data and tools it gives them. No step is locked behind another, and one company sees nothing of any other.

The governance step takes a governance document a company already has, or one written in the AI Governance Writer and attached as a snapshot of the moment it was attached, which stands on its own once the source project reaches the end of its own 30-day life. The scorecard counts published cards only, never drafts or attempts, per person in the directory, under a disclosure that stays on screen; a person with none stays on the board rather than disappearing from it.

no step locked · one workspace per work-email domain · proof at sign-in or no company data · company cards never appear on this page · published work only on the scorecard · free

QBR Machine

A client name in, a complete quarterly review package out.

The AI teammate working alongside our XL.net Technology Officers. Not a chatbot bolted onto a form: Claude Code running purpose-built, git-versioned skills that produce the actual deliverables XL.net presents to clients every quarter, sourced from live systems, with every number traceable to where it came from.

Every provider connection runs through XL Lakehouse, our scoped and audited access layer. No provider API keys ever live in the AI's workspace. Its memory persists, too: client context, feedback, and working agreements carry forward quarter to quarter instead of resetting every conversation.

Claude Code · git-versioned skills · template-locked deliverables · validate, approve, self-test · Lakehouse-scoped access

XLing

XLing is XL.net's internal system of record for service desk and account teams. It covers customer master data, service tickets, tasks, time entries, projects, sales opportunities, KPIs, IT processes, assets, users, and documents. External developers built the software, while XL.net's team consolidated, audited, and documented this source archive.

Staff use XLing through a single-page web app built with React UI components and a schema-driven form and table builder. Its server library provides a configuration-driven GraphQL CRUD engine backed by a document store, with entity schemas generated at runtime. Integrations use the same generic create, update, and migration resolvers as the GraphQL API.

The AI layer defines ticket analyzers, ticket-review summarizers, a knowledge base search assistant, and sales roleplay agents through the OpenAI Responses API. Ticket-facing AI operations write their output to the platform and consume API budget. The archive supports understanding, interfacing with, and rebuilding the platform. Its GraphQL reference documents 250 Query fields, 977 Mutation fields, and 103 object types.

React single-page app · GraphQL API · 250 Query fields · 977 Mutation fields · Google IAP · submitted by the XL.net team

Client Site Rescue Mirror

This repository was a temporary production stand-in for a Chicago-area clinic that lost access to its WordPress hosting. It combined a static mirror of the public site with crawl and transformation scripts, a contact relay, QA checks, and blue/green deployment configuration. Traffic passed through Cloudflare and a dedicated tunnel to a localhost nginx listener serving timestamped releases.

The rebuild pipeline used a sitemap-seeded wget crawl without link conversion. Additional scripts fetched responsive images, lazy-loaded files, CSS-referenced assets, Elementor lazy chunks, and assets embedded in encoded settings. Transformation rebuilt contact form 1243 to post to a local contact endpoint, converted other forms to calls to action, removed GTM, GA4, hCaptcha, and LeadConnector integrations, decoded Cloudflare-obfuscated email addresses, and generated contact success and error pages.

The zero-dependency contact relay validated submissions, tagged spam without dropping it, deduplicated messages, sent mail through msmtp, spooled failures, and exposed a health endpoint. Testing included 21 automated relay gates plus QA checks for form behavior, tracking removal, challenge pages, sitemap coverage, and live 200, 301, and 404 behavior. Deployment used release directories, a symlink flip, and a health gate. The static copy omitted blog search, comments, WordPress administration, feeds, and WordPress JSON endpoints. Its content was frozen as of July 21, 2026.

The README described the build and deployment. · The relay test defined 21 gates. · nginx listened on localhost. · Content was frozen on July 21, 2026. · submitted by the XL.net team

XL API Gateway

Your cloud, your keys, one governed front door.

What XL Lakehouse does inside XL.net, the Gateway does inside each client's own cloud: one local proxy that Cursor workspaces, internal tools, and developer VMs call instead of holding provider keys themselves. Operators onboard a client once, provision a site from the console, and wire who may reach which upstream API from a single place. The console is live; client gateways are deploying now.

Secrets never sit in the console database or in developer workspaces: they are fetched from the client's vault only when a permitted request needs them, verified before go-live, and cut off the moment a grant or credential is revoked. Fleet alerts and scheduled updates keep sites current; no API keys get mailed around.

per-client isolation · vault-backed credentials · grant-checked proxy · audited fleet operations

Beacon

The channel assistant that answers "has someone already built this?" before anyone builds it twice.

Our own Slack, one channel: #claude-teamhub, where the team talks about what it wants to build next. Beacon sits in that conversation, built for a problem that grows with every automation a team ships: the same thing getting built twice because there was no quick way to ask whether it already exists.

Beacon holds no SweetProcess credential of its own. Every governance search and permission check is brokered through XL Lakehouse, scoped read-only and audited, against a library of roughly 5,755 procedures and 255 policies refreshed on a 24-hour cycle. Slack connects directly because realtime events have no broker equivalent, and Google Drive connects directly because the tool registry and interaction log live in Google Docs, which Lakehouse's Google integration does not yet cover. The pipeline is built and tested, module by module, against real production data; what remains is the Slack app itself and a short list of setup steps before the channel gets its first reply.

Node.js · Slack Bolt (Socket Mode) · Claude tool-use loop · SweetProcess via Lakehouse (read-only) · 5,755 procedures / 255 policies, 24-hour refresh · owner-reaction commit, 72-hour expiry

Autotask CI Intake

This Claude Skill turns device details from photos, screenshots, or pasted text into Autotask Configuration Items. It determines the category and type, extracts visible fields, flags uncertain values, and requests missing information in one consolidated message. For each device, it produces a field block in Autotask form order and appends captured data to an XLSX workbook organized by category.

The skill handles Physical Server, Virtual Server, Storage, Network Devices, and Vendor records. From asset labels, it can read the manufacturer, model, serial number, and MAC address. From management screens, it can capture names, IP addresses, firmware or operating system versions, and host or cluster relationships. It merges images of the same device into one capture and treats distinct devices as separate Configuration Items.

Unreadable values remain unconfirmed rather than being completed with invented characters. When the device type is ambiguous, the skill provides a provisional classification and asks the user to confirm it. It also asks whether dependent equipment links to an existing Configuration Item or requires a separate record. Status defaults to Active, while Installed By defaults to Steven Hanlon unless the user supplies another name.

Autotask CI intake · Consolidated field prompts · Unconfirmed value flags · XLSX category tabs · submitted by the XL.net team

Ticket Notes

Ticket Notes turns raw Microsoft 365 and Exchange Online troubleshooting activity into internal ticket notes, handoffs, and escalation drafts. It organizes findings into labeled blocks and marks claims as confirmed, inferred, or hypothesis. The format separates reported issues, eliminated causes, confirmed or suspected causes, separate findings, applied fixes, and pending actions.

A ticket note records what happened, organized by finding. Available labels are Issue, Ruled out, Root cause, Hypothesis, Separate finding, Fix applied, and Next. The skill includes only blocks with content. If a request is ambiguous, it asks whether the user wants a note or a handoff rather than choosing one. If both are requested, it writes and labels the note first, followed by the handoff.

The skill sorts raw input into the appropriate blocks and preserves the order of checks within each block. It compresses transcript-style details into sentences and extracts exact values from pasted output. Missing times, names, and values are left out rather than estimated, while information gaps are stated explicitly. Values that appear incorrect or contradictory are raised with the user instead of being silently reconciled. The completed note or handoff is returned in a plain code block for copying into a ticket or message.

Time saved · 10 hours a month, reported by the submitter

SKILL.md · 1 skill file · 7 block labels · handoffs end with Next · submitted by the XL.net team

Microsoft 365 Security Assessment

A read-only Microsoft 365 security assessment toolkit pairs a PowerShell script with a local browser portal. It queries tenant configuration, collects results, and turns the uploaded result folder into a formatted executive summary. The portal has no server or network calls, so uploaded files remain on the user’s computer.

The browser portal guides the user through obtaining the script, signing in, and uploading assessment results. Running the script against a tenant can open two or three sign-in prompts for Microsoft Graph, Exchange Online, and Security & Compliance. The assessment requires a Global Administrator or Global Reader account. Checks can fail or be skipped if the user is not fully signed in with a Global Administrator account at each prompt.

Results are saved as a timestamped folder in Downloads. Dragging the complete folder onto the portal’s upload area generates the executive summary, which includes options to print or save as a PDF. The script only queries configuration and does not change the client tenant.

Read-only assessment · PowerShell collection · Local browser portal · Executive summary PDF · submitted by the XL.net team

System Monitoring AR

System Monitoring AR retrieves the current audit checklist from a user-identified website, maps questions to their evidence sources, and gathers findings through logged-in browser access or approved server checks. It records unavailable evidence as a gap and creates a dated PDF report in the configured local recommendations folder.

Checklist guidance, including How To and Notes fields, determines which tool or site supports each question. Questions are grouped by source before evidence collection. When dashboard evidence is insufficient, PowerShell checks can inspect Certificate Authority roles, Certificate Services, installed certificate stores, running services, server roles, and installed applications with the user's approval.

For critical-service coverage, the skill compares a server service inventory with Kaseya monitor assignments and names specific missing monitor sets. The PDF presents the client name, audit date, question text, direct answer, and a flag for missing or ambiguous data. A short chat summary highlights standout findings without reproducing the full audit.

Time saved · 6 hours a month, reported by the submitter

Claude Skill · PDF audit report · Browser and server evidence · 2 PowerShell references · submitted by the XL.net team

Client Thread Archive Capture

Client Thread Archive Capture is a Claude Code Skill that captures directly named Slack threads and finds SaveConvo-tagged threads through an invoked sweep. It files each capture in a searchable Markdown archive organized by client, with an index for lookup. Slack reads pass through XL Lakehouse using the slack:read scope. Retrieval searches files on disk without contacting Slack or Lakehouse.

A person selects the conversations to preserve. The tool handles finding, reading, dating, and filing them. Client identification uses channel conventions and an alias map. An internal thread with no named client goes to the unfiled folder. For an ambiguous or new client, the skill asks for the canonical folder name instead of guessing.

The implementation resides in the Skill instruction file and runs when invoked, with no standalone script or schedule. It holds no Slack token of its own and uses a shared workspace bot credential through Lakehouse. Direct messages are outside the bot's reach, and archived threads do not receive change detection when new replies appear.

Time saved · 10 hours a month, reported by the submitter

Claude Code Skill · slack:read scope · indexed Markdown files · 30-day sweep limit · submitted by Chris

Leslie's Weekday Brief

Morning Brief generates a fresh weekday HTML report that combines the day's calendar, open email and Slack threads, overnight closures, and preparation items for tomorrow. Connected tool roles are optional, so unavailable sources are skipped and the page adapts. Gathered items are sorted into Needs attention or Resolved, or omitted from the report. Calendar data also shapes the headline and terrain visualization.

Google Calendar supplies today's events for the terrain and tomorrow's events for preparation checks. Gmail looks for direct questions awaiting a reply, with unread threads from the last two days as a fallback. Slack looks for recent mentions and direct messages ending in an unanswered question. Searches gather roughly eight candidates from message and thread snippets rather than full bodies.

The page presents a date line, one line serif headline, SVG terrain strip, three time blocks, and lists for Needs attention and Resolved. List entries use a linked title and a sentence that names the source in prose. The self-contained output is designed to be read in under 30 seconds.

Weekday report · Single HTML file · Optional connected sources · Headless Chromium check · submitted by the XL.net team

SD Shift Report

SD Shift Report pulls five ticket counts from Autotask through XL Lakehouse, formats them in the service desk's established wording, and posts the report to Slack. Four posting windows control the report name and dates. A person confirms that the shift is finished and starts each run.

The five metric definitions mirror existing Autotask dashboard widgets and queue filters. They reside in a configuration register so service desk engineers can review data changes when a widget changes. The command line and web UI share the reporting logic. In the UI, the browser submits a date, window, and operator, while the server retrieves the counts and builds the message when the operator submits the request.

The tool runs locally through a command or local web page. The UI validates the selected operator against a register, but it has no authentication, so anyone who can reach the page can select a listed identity. Slack delivery confirmation relies on the write response because the tool does not hold Slack read access.

Time saved · 15 hours a month, reported by the submitter

Five Autotask counts · Four posting windows · Human initiated posting · Local command or web page · submitted by Ian

Closure Composer

Closure Composer is a Claude Code skill for the XL Service Desk. Given an Autotask ticket number, it reads ticket notes and time entries through XL Lakehouse, orders activity by when the work occurred, and assesses whether the ticket is ready to close. For a ready ticket, it prepares a closing email for engineer review.

The skill compares the original ticket request with the documented work. It marks a ticket ready if the customer says the issue is resolved or can be closed, or if the record documents a resolution matching the original issue and establishes that the resolution works through customer confirmation or engineer verification. Work awaiting testing and unanswered requests for confirmation produce a not ready result. Zero time entries combined with no substantive technician notes also produces a not ready result and no draft. Each conclusion cites its supporting note or time entry and the actual work timestamp.

For a ready ticket, Closure Composer shows the conclusion and draft in chat. The engineer must confirm before the skill posts the draft as an internal Autotask note. The skill does not send customer email or change ticket status.

Runs in Claude Code · Reviews Autotask tickets · Routes access through XL Lakehouse · Requires engineer confirmation · submitted by the XL.net team

M365 Service Health

M365 Service Health is a Claude Skill that reads four public Microsoft status endpoints and reports the result to the M365 service health Slack channel. It surfaces unhealthy states, identifies unreadable product families as unknown, and posts an all-clear only from data it reads. Coverage includes admin center reachability, Azure, and consumer services, not proof that a client's commercial Microsoft 365 services are healthy.

The skill fetches four independent JSON endpoints in one batch. Endpoint reads require no authentication, browser, or Microsoft tenant. It retries a failed endpoint one time and names any remaining data gap in the report. It evaluates the Microsoft 365 and Power Platform admin center feeds by Status, treats the Azure Message field as meaningful health information, and checks each consumer service entry. States other than Available or Operational are reportable.

During an incident, the Microsoft 365 admin center endpoint can provide impact details for named commercial services. The skill sends results to the M365 service health Slack channel. If the day's root post exists, it adds a thread reply for a material change in service names or statuses. If the asserted state is unchanged, it does not add an update. A Python service implements these rules and has 152 offline tests.

Claude Skill · 4 public endpoints · 152 offline tests · 8 AM Central · Slack reporting · submitted by the XL.net team

PA Tools

PA Tools is a locally run internal dashboard that consolidates workflows otherwise handled as separate Claude Code skills or manual processes. AT Contacts Audit identifies active contacts who have lost Autotask support coverage, groups them by license status, and provides a 12-month ticket-volume breakdown from four uploaded CSV or XLSX exports.

The audit matches the Contacts List to a Sync Group export, preferring email addresses and falling back to names while detecting ambiguous matches. It separates results into Licensed, Unlicensed, and Needs Review groups, renders results in the browser, and provides a styled workbook for download. Its ported deterministic logic is verified against 39 hand-traced test cases covering every branch.

PA Tools uses a React and Vite frontend with a plain Node HTTP server. The packaged server binds to the local machine at 127.0.0.1 on port 5175 by default and serves the built frontend and API from one process. XLSX reading and writing use ExcelJS.

In development · Local desktop launch · Styled XLSX output · submitted by the XL.net team

QuickBooks Export Workbook Merger

XL Financial Consolidator combines multiple QuickBooks Online .xlsx and .csv statement exports into one Excel workbook. Users review and correct the detected entity, statement type, and period before consolidation. Processing takes place inside the browser without uploading financial data. The output can include an opening Totals tab, separate statement tabs, and a Summary tab.

Statement tabs group columns by period, present entity detail when selected, and add calculated totals. The Totals tab shows consolidated figures without entity columns. The Summary tab inventories source columns with the file, sheet, entity, statement, period, value count, inclusion status, and notes. Users can exclude detected data columns before creating the workbook.

For Profit and Loss and Cash Flow statements, the tool sums entities within each period and adds a grand total across periods. For Balance Sheets, Trial Balances, and aging reports, it sums entities within each date without adding balances across dates. QuickBooks Online Total columns are excluded and totals are recomputed. The tool checks whether Total Assets equals Total Liabilities and Equity in each Balance Sheet column. Account matching uses account names, and intercompany eliminations are not applied.

Self-contained HTML · .xlsx and .csv input · .xlsx workbook output · submitted by the XL.net team

W250 Case Study Interview Questions

This Claude Skill researches a client through Salesforce, selected Google Drive documents, the client’s website, and recent public information. It creates five to eight customized questions for a W250 case study interview, using a 65-question reference bank to check coverage while narrowing and rewriting the material for the client.

The research reviews firmographics, relationship history, contracted services, opportunities, cases, and recent activity. It checks for an existing case study and examines relevant planning documents, QBR notes, project records, and meeting notes. The resulting summary identifies interview angles, sensitive topics, and unresolved gaps, cites the source of significant claims, and distinguishes inferences from documented facts.

The question set covers the client’s prior situation, the service provider’s work, resulting changes, and the reason for choosing the provider. One question seeks a quantitative result, while another asks for a specific story or moment. Each question includes its purpose and a follow-up probe. A closing checklist reminds the interviewer to secure a number, a quote, and permission to use the client’s name and logo.

Time saved · 3 hours a month, reported by the submitter

Client-specific preparation · 65-question reference bank · Live interview probes · submitted by the XL.net team

XL.net-Branded Microsoft Cloud Audit Toolkit Builder

A self-contained Claude Skill for building XL.net-branded audit and troubleshooting toolkits across Microsoft 365 and Azure services. It combines a service-specific workflow with documentation standards, script conventions, Microsoft guidance research, severity ratings, reporting requirements, version management, and release QA. The toolkit structure adapts to the architecture and administration model of each cloud service.

The core deliverables are a printable checklist, troubleshooting quick reference, administrator guide, README, and SweetProcess procedure draft. The workflow can also produce manual check instructions, Service Desk guidance, branded Word documents, and service-appropriate audit scripts. Script layouts can follow tenant and endpoint, resource and guest, host pool and session host, or subscription-wide boundaries rather than forcing one structure onto every service.

For services beyond the existing Intune, Entra ID or M365 Core, and Exchange Online examples, the skill requires current Microsoft guidance before drafting checks. Each finding identifies the detected configuration, assigns severity through an Impact by Likelihood scale, and provides a specific corrective action. Scripts use parameterized or prompted connections, keep audit activity read-only and idempotent, and account for pagination and API throttling. Reports use HTML, CSV, and PDF formats. Release QA covers remediation coverage, script behavior, permissions, connection dependencies, rendered outputs, document consistency, branding, citations, audience fit, and required archive contents.

Claude Skill · Microsoft 365 and Azure · Branded audit toolkit workflow · Versioned releases · submitted by the XL.net team

PB Contact Email Drafts

This XL.net inside sales skill accepts a contact email address or phone number, looks up the contact in PhoneBurner, and creates a plain-text Gmail draft from a standard follow-up template. It uses call notes to select the template wording and leaves the message unsent for the representative to review.

The skill requires a Zapier MCP connection with Gmail and PhoneBurner enabled. Its PhoneBurner search prefers the newest phone match and excludes trashed contacts. It captures the contact's first name, email, company, and notes. When the company field is empty, it can derive a readable company name from the email domain. It retains company or industry placeholders when those details cannot be inferred from the contact fields or domain.

For a recorded post-conversation follow-up, the skill defaults to Main follow-up #1. An explicit request for a chill, casual, or soft tone enables the Chill follow-up for that context. If the notes show that no conversation occurred, the skill selects the Sorry I missed you template and avoids a thanks for chatting opening. Each draft introduces XL.net CEO Adam Radulovic and includes his configured calendar link.

Time saved · 3 hours 30 minutes a month, reported by the submitter

Inside sales · PhoneBurner lookup · Gmail draft · Review before sending · submitted by the XL.net team

Monthly Ticket Review

Monthly Ticket Review combines selected per-client Autotask CSV exports into a concise Markdown report for an MSP helpdesk review run. It presents client statistics, recurring issue themes, representative tickets, top-line observations, and recommendations aimed at preventing repeat support demand. The result gives readers a single view of problem areas across the clients included in the run.

The analyzer calculates ticket counts, resolution-time statistics, top issue types, priority breakdowns, top requesters, weekly volume, and open tickets older than 14 days. The report uses created, completed, open, aging, and priority figures from the analysis and adds two to four observations for each client.

The report ranks up to five recurring themes by ticket count. Each qualifying theme includes two or three representative ticket numbers and titles. Its recommendation names a root cause and a preventive fix intended to stop recurrence. One-off issues can appear in the observations with a preventive note in case they recur.

Claude Skill · Autotask CSV input · Single Markdown report · Saved to local Recommendations folder · submitted by the XL.net team

Log Analyzer

Log Analyzer is a Claude Skill for investigating incidents and symptoms across Windows, syslog, network device, virtualization, backup, web server, application, and generic text logs. It normalizes larger files, connects related activity across sources, and researches identified errors. The result is a structured findings report that separates current concerns from historical activity and presents evidence and recommended actions.

For each file, the skill identifies the log type before analysis. Its bundled Python parser extracts timestamps, severity, and messages where possible, groups near duplicate messages into signatures, and records counts plus first and last observed times. For unrecognized formats, the workflow uses targeted filtering around error terms or the reported symptom. It then clusters entries by timing and context, separates anomalies from expected reboots, scheduled jobs, and informational events, and flags severe findings outside the stated symptom.

Reports include targeted timestamps, event IDs, excerpts, and knowledge base citations rather than a raw log dump. Findings distinguish active concerns from resolved or transient activity, and open questions remain explicit when context or evidence is inconclusive. The skill is intended for investigation and diagnosis, not real time monitoring, log shipping configuration, or format conversion without an investigative purpose.

Environment context checklist · Log format guide · Vendor source guide · Report template · submitted by the XL.net team

Kaseya AP Builder

Kaseya AP Builder turns plain English automation requirements into import-ready Kaseya VSA 9 agent procedure XML and a numbered process description for procedure bodies and runbooks. The skill reads and writes text without connecting to Kaseya or executing procedures against a live VSA.

The skill creates a ScExport XML document for the Kaseya Agent Procedure editor. Its guidance covers XML attribute escaping, short descriptions and inline commands, operating system tags, procedure logging, managed variable checks, installation detection, temporary file cleanup, and 64-bit execution. Environment-specific placeholders, managed variable names, install paths, and tree paths must be confirmed before import.

Four patterns support guarded agent installation, scan-first application deployment, reporting to a custom column, and orchestration through procedure calls. Installation checks can use services, registry keys, or files as appropriate to the selected pattern. Installers can be retrieved from an S3 bucket, a vanity address, a vendor source, or Kaseya's managed share. Report procedures can run a detection script, read its result file, update a custom column, and remove the staged files.

Time saved · 6 hours a month, reported by the submitter

Kaseya VSA 9 · 2 output types · 4 procedure patterns · Windows and macOS · submitted by the XL.net team

Autotask Ticket Summaries

Autotask Ticket Summaries is a Claude Skill designed to review a user's open Autotask service tickets in Chrome and create a concise rundown of the issue, actions recorded so far, and stated next steps. It supports requested inclusion or exclusion filters based on queue. The workflow is read-only and prohibits editing tickets, saving notes, logging time, or completing tickets.

The workflow uses JavaScript to access Autotask's script-rendered ticket grid inside an iframe. It extracts each ticket's number, queue, and internal row key, applies the requested filters, and navigates within the same tab to each corresponding detail page. This avoids opening ticket windows outside the controllable tab group.

Use requires a connected Claude in Chrome extension, an authenticated Autotask session with the open-tickets view available, and the ticket-list tab inside the MCP tab group. If the extension is disconnected, the instructions direct the user to install or sign in to it. If the tab is outside the group, the user can move it or provide the list address for opening in a controlled tab.

One skill file · Open-ticket workflow · Script-rendered Autotask pages · Queue-aware selection · submitted by the XL.net team

SD Documentation Audit

SD Documentation Audit automates data gathering for the monthly Service Desk documentation audit. It pulls 90 days of client tickets from the Reactive and Service Requests queues, selects issue rows for review, searches SweetProcess for client-owned procedures, and queries Autotask Configuration Items for hardware context. Issue labels and ticket counts are final, while Hit or Miss decisions, analysis, and documentation links remain drafts for human review.

The tool groups tickets by the combined Issue: Sub Issue label and sorts rows by count, then label. It includes every sub-issue type with at least five tickets and adds the next highest counts until it reaches ten rows. If the boundary falls within a tie, every type at that count is included. If fewer than ten distinct types exist, the tool includes all of them.

SweetProcess results pass a client-ownership gate before topic matching. The search uses explicit client aliases, excludes archived procedures, prioritizes tags over procedure names, and consults an explicit house-wide register when client-scoped documentation does not match. Configuration Items provide named hardware details for the analysis rather than serving as documentation. Retrieved documentation links come from the SweetProcess API response instead of being constructed or carried forward from an earlier audit.

Time saved · 2 hours a month, reported by the submitter

Node.js runtime · 90-day ticket window · Google Sheets output · Run end to end for two live clients · submitted by Ian

SOW to Project Plan

SOW to Project Plan converts PDF or DOCX Statements of Work into structured delivery plans. Work is organized into phases, workstreams, and tasks, with acceptance criteria, effort estimates, roles, dependencies, and supporting quotations from the source. A three-pass server pipeline drafts, reviews, and revises the plan while preserving a critique log for inspection.

The three passes build the work breakdown structure, review it for uncovered scope, overlooked constraints, sequencing problems, weak acceptance criteria, and unsupported additions, then accept or reject each finding with a recorded rationale. Ambiguities are placed in open questions rather than filled with invented details. Each review finding cites evidence, and the critique log presents its severity, category, evidence, revision outcome, and rationale.

The single-page interface provides drag-and-drop and file-picker upload controls, live progress through Server-Sent Events, a collapsible work breakdown structure, and project and phase totals. The final view also includes deliverables, assumptions, exclusions, and open questions. Plans can be downloaded as Markdown or JSON without another server request.

Next.js 16 · TypeScript · PDF and DOCX · Server-Sent Events · Markdown and JSON export · submitted by the XL.net team

Call Summary Service

A self-hosted web app turns service desk call recordings into structured MSP ticket documentation and a plain-text export. Users review the generated summary beside a timestamped transcript, then download the notes in the house format. Stored transcripts can be summarized again without repeating the transcription step, which supports prompt tuning without another transcription provider request.

The pipeline probes and prepares each recording, transcribes the audio, merges transcript segments, summarizes the dialogue, and renders the export. With multichannel processing enabled, stereo recordings are split into mono channels for speaker attribution. Transcript metadata identifies whether attribution comes from channel separation, provider diarization, or neither. Providers with upload limits trigger automatic audio chunking, with offsets added back to segment timestamps.

The structured output includes participants, call purpose, troubleshooting performed, findings, actions taken, resolution status, next steps, commitments, and operational flags. A fixed schema validates the summary, retries invalid output once, and fails the job after a second invalid result. Provider implementations are selected through configuration. Built-in mock providers support the upload, review, and download flow without API keys or vendor charges. SQLite stores call metadata, transcripts, and summaries, while recordings and exports remain on the filesystem. The documented deployment has no built-in login and requires added authentication before broader exposure.

Python 3.12+ · ffmpeg and ffprobe required · SQLite WAL mode · Plain-text export · submitted by the XL.net team

Printer Port Reconfiguration Utility

Printer Port Reconfiguration Utility is a portable Windows PowerShell tool for moving printer queues from WSD ports to Standard TCP/IP ports. It supports graphical and unattended operation, logs each run, and creates a JSON rollback file when it makes a change. Printer drivers stay unchanged, and the package runs without installation from a USB drive, network share, or RMM payload.

In graphical mode, the utility lists printers that use WSD ports and marks addresses it cannot resolve for manual entry. Users select queues for conversion and can choose to remove the old WSD port. For each selected queue, the tool creates a port named with the IP_ prefix followed by the address and redirects the queue to it. New ports use RAW 9100 with SNMP disabled.

Windows PowerShell 5.1 · Windows 10 and 11 · Graphical and unattended modes · Portable package · submitted by the XL.net team

Tracking Form Triage

Tracking Form Triage reviews client-facing XL.net SA Visit Summary PDFs against the Systems Analysts Tracking Form SOP. It combines Python checks for mechanically decidable defects with a Claude judgment layer for cross-section contradictions and wording issues. Results are available as CLI text, JSON, or a self-contained interactive HTML triage report.

An SA supplies a PDF, and the tool organizes findings by severity. Each finding links to the relevant SweetProcess rule. The HTML report lists clients alphabetically, opens the client with the most critical findings, and groups recurring problems by severity while reporting affected clients and forms separately.

The tool retains no state between runs, uploads no input, and uses no database. Missing rows that may be hidden by the Internal flag are assigned to the Verify tier rather than treated as absent from XLing. Real client fixtures and the customer export remain within the team, while shared copies use invented sample clients.

Python CLI · Claude judgment layer · Text, JSON, and HTML output · Stateless PDF processing · submitted by the XL.net team

Service Desk Shift Relay

Service Desk Shift Relay is an AWS Lambda automation for scheduled handoffs between three Service Desk shifts. EventBridge Scheduler invokes it at shift end, and the service incorporates Autotask ticket data and recent Slack context before posting to the incoming shift's channel. It replaces a handoff process that requires a person to run the source Claude skill in chat.

Runtime settings come from environment variables, with an AWS Secrets Manager JSON secret merged at Lambda cold start. Deployment schedules use the configured timezone and follow daylight saving time. Slack context collection is best effort by default, while a configuration option can require it and skip the run after a context read failure.

Ticket notes provide status and completed outcome text. A configured Autotask user-defined field supplies a next step. Without that field, the formatter omits the line rather than generating one. Individual mentions require a configured shift roster and an assignee match. Tests cover shift resolution, post-midnight reporting, classification, P1 detection, and message formatting.

Time saved · 11 hours a month, reported by the submitter

AWS Lambda · EventBridge Scheduler · Autotask and Slack · pytest coverage · submitted by Froilan

Provider Status Lookup Skill

Provider Status Lookup Skill checks live internet outage status for a named ISP and location by calling the project's dedicated checker service. The service handles source selection and parsing, allowing the skill to return location-aware findings with supporting context rather than derive an answer through generic web search.

The checker service queries its configured outage sources directly. The skill presents findings in plain language, supports each status with a verdict or failure reason, includes a source reference and check time when supplied, and keeps an unsuccessful lookup distinct from a finding of no known outage.

A provider outside the documented roster is reported as unsupported rather than sent to the API. For multi-provider checks, the skill groups findings by status so reported outages, successful checks, and lookup failures remain distinct.

Time saved · 27 hours a month, reported by the submitter

FastAPI service · Two outage sources · Port 8001 convention · submitted by the XL.net team

WSD Queue Port Migrator

WSD Queue Port Migrator moves local print queues from WSD ports to Standard TCP/IP ports that use RAW port 9100 and the printer's IPv4 address. Technicians can run it through a WinForms interface or use Auto mode for unattended conversion. The PowerShell utility supports rollback and keeps each queue's driver, name, security, and preferences unchanged.

The utility runs on Windows 10, Windows 11, and Windows Server 2016 or later with the in-box Windows PowerShell 5.1 engine. It requires local administrator privileges and can relaunch itself through a UAC prompt. All work uses the local print spooler, registry, and PnP state, with no network calls, internet access, telemetry, or dependency installation.

In the interface, a technician reviews detected queues, edits IPv4 address cells, and selects conversions. Auto mode converts queues with resolved addresses and logs and skips those without one. For each selected queue, the utility creates a TCP/IP port, changes the queue's binding, reads the queue back to confirm the result, and records a rollback entry.

Windows PowerShell 5.1 · RAW port 9100 · Local administrator · Local processing · submitted by the XL.net team

HR Onboarding Dated Task Tracker

Built from XL's 27-step internal HR onboarding procedure, the tool produced a dated task tracker and a set of drafted HR emails for each hire. It collected 14 inputs in one round, applied 5 branching conditionals against those answers, and turned relative offsets into calendar dates, skipping weekends for anything requiring the hire to act. Excluded steps were listed with their reason. The package included a Windows batch launcher and a PowerShell generator script alongside the skill files.

Branching ran off the answers collected up front. Steps 24 and 25, the Manager Training Roadmap and the Ninety accountability chart, were included only for hires flagged as managers, and step 10, the 401k advisor introduction, was gated to US-based hires. Hires outside Chicago who were not on the Leadership Team received the reduced invite list rather than all company events, and the EOS book source differed between US and PH hires. Filtered-out steps appeared, marked as not applicable with a reason. The holiday file moved a due date off a listed closure the same way a weekend was handled. When the start date had passed, the tracker was rebuilt from the current date with overdue items marked.

The tool drafted 6 emails: the welcome letter, the 401k advisor intro, 2 InfoSec reminders, the Ruby Receptionist directory update, and the company-wide intro blast. The welcome letter used XL-approved copy near-verbatim, with the name swapped in. The skill was barred from inventing a policy detail, vendor, link, or deadline not already recorded in it; where something was missing, it asked. The intro blast was held rather than drafted when the hire's intro answers or photo were not in hand. Tasks waiting on another person, such as the CISO security access form or the hire's photo, were flagged as blocked instead of ordinary pending work. The 30-day InfoSec deadline was surfaced as the one hard compliance date.

installable skill bundle · PowerShell generator script · markdown tracker, optional .xlsx · source: internal HR procedure PDF · submitted by the XL.net team

SA ticket review Dashboard (Cassandra)

Ticket Review Dashboard is a local workspace for XL.net Solutions Architects. It combines read-only Autotask PSA and XLing data to present client tickets, open CCPs, history scans, and project impact analysis. Review state stays in the browser, and the application does not write data back to either source system.

The dashboard presents a rolling 30-day view of tickets worked for each client, with AI-written work summaries, review checkboxes, and notes. Its Open CCPs view includes AI-distilled hold reasons. Six-month history scans chart recurrence by ticket type and recommend permanent remediation. The single-page interface includes sortable tables and project impact charts with week-level drill-down.

Project impact analysis identifies whether a project coincides with a change in ticket activity. It assigns one of four verdicts: increased ticket rate, no change, decreased ticket rate, or insufficient data. It also provides changes by ticket type and an AI assessment that grades potentially associated tickets by confidence. The server listens on localhost and runs pulls and analyses on background threads. XL Lakehouse enforces read-only provider scopes and records calls with the acting user. AI output follows an enforced schema, while truncated responses prompt another request.

Local web application · 30-day ticket window · Read-only source access · Project impact analysis · submitted by the XL.net team

EA Scheduling Queue

This single-tenant FastAPI application supports one Executive Assistant through the monthly Engagement Call cycle and related client correspondence. SQLite stores workflow state across long-running threads. Human approval gates client-facing actions, and each proposed call time requires the President's explicit confirmation before finalization.

The application builds the monthly invite list, drafts personalized outreach, interprets client availability, supports alternatives after a rejected time, and surfaces stalled threads. The Executive Assistant asks the President directly about a proposed slot and records his response in the interface. A confirmed call becomes a calendar event containing the agenda, with the connection link added afterward by the Executive Assistant.

Skill markdown loads at request time as a runtime asset for the Anthropic-powered reasoning layer, which produces drafts and proposed actions without direct access to Google services. Structured parsing captures candidate times, timezones, and confidence. LearnedFact rows retain answers to prior questions, while an append-only audit log records proposals, approvals, executions, and external calls. Fake adapters support offline development and testing, including an end-to-end twelve-client cycle test.

FastAPI + SQLite · Monthly EC workflow · Offline fake mode · Append-only audit log · submitted by the XL.net team

Client Ticket Pattern Brief

AT Ticket Analysis converts a single client's 30-day Autotask PSA ticket history into a prioritized pattern analysis, a Markdown report, and a formatted Excel workbook. A shared engine serves its CLI and local web app. Deterministic rules assign High, Medium, or Low priority with a one-line reason, while per-ticket flags and cross-category clustering surface items for point-of-contact discussion.

The analysis identifies reporters from ticket text without substituting assigned technicians. It examines dominant themes, repeat reporters, recurring hosts, time clustering, and same-day patterns across categories. CSV, TSV, and XLSX uploads run without provider credentials. Missing source fields are disclosed in the output rather than imputed.

The Markdown report places the point-of-contact priority callout first, followed by category findings and data limitations. The Excel workbook contains Summary and Tickets sheets with live formulas for ticket counts and hours. Results and artifact paths are recorded in local SQLite run history.

Interfaces: CLI and local web app · Inputs: Autotask, CSV, TSV, and XLSX · Storage: local SQLite run history · submitted by Jazer

Tenant Docs: Automated MS365 Hardening Documentation

Tenant Docs captures live Microsoft 365 configuration and turns it into SweetProcess-ready documentation. Two PowerShell collectors cover Entra settings and Defender for Office 365 and Exchange Online Protection policies. Claude Code prepares a tenant-specific hardening reference and troubleshooting SOP, while technicians review drafts before approved documents are created as private SweetProcess procedures through the XL Lakehouse proxy.

The Entra collector requests read-only Microsoft Graph scopes and captures Conditional Access, authentication methods, tenant settings, registration summaries, and access review definitions. It resolves referenced users, groups, roles, and applications to display names. The Defender collector retrieves threat policy configuration through Exchange Online PowerShell and imports only the required Get cmdlets as a defense-in-depth measure. Each run writes timestamped JSON snapshots that preserve earlier files. Folder identity is keyed by tenant GUID, while an optional client-name override must match across both collectors.

Claude Code drafts a hardening reference with exact policy names, enforcement states, scope, exclusions, and user-visible effects. It also drafts a symptom-driven troubleshooting SOP based on controls enforced in the tenant. Drafts remain in a gitignored output directory for technician review. The publisher converts approved drafts to SweetProcess step objects and creates private procedures through the audited proxy. The tool stores no SweetProcess credential, and writes are attributed to the operator identity. A reviewer checks the rendered procedure before making it visible.

Two PowerShell 7 collectors · Timestamped JSON snapshots · Technician-reviewed drafts · Private SweetProcess review · submitted by the XL.net team

XLgov

XLgov is XL.net's internal governance platform for policy, procedure, and strategy content across the organization. It represents content as linked, owned, addressable database records and provides workflows for imported policy review, strategy alignment, field-level revisions, and approvals from impacted owners.

The policy onboarding queue lets assignees and executives confirm or correct ownership, then approve imported policies from Draft to Active. Strategy pages cover objectives, pillars, and links between pillars and policies suggested manually or by AI. Procedure records exist in the schema but are not yet imported.

The application uses Next.js 16, TypeScript, React 19, PostgreSQL 16, and Prisma 7. The internal preview runs in Next.js development mode, without automated tests or process supervision. Its policy importer is re-runnable but creates duplicates when a policy is imported again.

Internal governance platform · Next.js 16 · PostgreSQL 16 · VPN only · submitted by the XL.net team

Domain Controller Decommission Discovery

Domain Controller Decommission Discovery reports which systems depend on a domain controller and which dependencies have to change before it is demoted. It is a single PowerShell 5.1 file with a click-through window and a headless mode, run on the DC being retired. Ten independent read-only checks each write their own CSV and feed a summary graded BLOCKER, ACTION, REVIEW and INFO. The tool makes no changes to the environment and writes files only inside the selected results folder.

The tool covers the pre-decommission planning phase of the XL.net Domain Controller Server Decommission checklist SP and adds areas the checklist does not list. Check 1 records the five FSMO roles and co-hosted roles including ADCS, NPS, WSUS, KMS, WDS and ADFS. Check 2 covers replication and SYSVOL health. Check 3 queries every enabled AD computer for static DNS and WINS entries and writes a Not Reached row for anything that does not answer. Check 6 reads Security events 4624, 4625, 4768, 4769 and 4776. Check 10 generates a worksheet for systems the tool does not query, including firewall LDAP, VPN, RADIUS, hypervisor identity sources, NAS domain joins, MFP address books, VoIP, badge systems, camera NVRs and backup appliances.

A check whose prerequisites are missing is marked Unavailable, is not run and writes no CSV. Every worker emits exactly one row, with the reason in a Notes column, so a failed host still appears in the output. The tool requires local Administrator rights to read the Security event log, plus Domain Admin or equivalent read rights. WinRM is needed only to reach other servers; local domain controller queries run in process. Each run creates its own timestamped output folder, so repeat runs do not overwrite each other. For a 500-machine estate, the reference gives 15 to 45 minutes for all ten checks. The tool does not perform the demotion. It produces the plan for it.

dc-decom-discovery/SKILL.md · powershell 5.1, single file · ten read-only checks, ten csvs · gui plus -nogui headless mode · submitted by the XL.net team

TCA Compliance APP

The TCA Compliance App is a locally run web application for XL.net's Secure+ endpoint coverage audit. It turns console exports into classified endpoint coverage, compliance metrics, and reviewable findings. The workflow replaces spreadsheet-based review with persisted analyst decisions. A parity test runs the vendored original and ported reconciliation engine over the same inputs and compares coverage flags, match statuses, penetration tables, and gap sets.

SentinelOne is expected on every VSA9 endpoint. RocketCyber applies to selected clients, while DNSFilter applies to selected clients' workstations. Entitlement is a human decision because deployment data cannot distinguish a client with no entitlement from an entitled client with no deployment. Until the workbook importer is built, clients start as Undecided for RocketCyber and DNSFilter, and scope falls back to drafted penetration buckets.

The interface includes Dashboard, New Run, Gap Review, Clients and Entitlement, and Exceptions screens. The application was verified end to end against an export set containing 3,588 endpoints across 86 clients and producing 628 open findings. The workbook importer, Data Quality screen, exact-layout workbook regeneration, and hostability pass remain unbuilt. The run-level Security Metric is not authoritative until existing entitlement and exception data is imported.

Backend uses FastAPI, SQLAlchemy, and SQLite · Frontend uses Vite, React, TypeScript, and Tailwind · Client inventory remains on the workstation · submitted by the XL.net team

A Stand alone app ticket Categorizer for Autotask

Autotask Ticket Categorizer proposes Issue Type and Sub-Issue Type values for uncategorized tickets in a configured support queue. It combines the Claude API with active Autotask picklist values, presents proposals through a Google Workspace authenticated web interface, and writes approved categorizations back through the Autotask REST API.

Scheduled, command-line, and web initiated runs share one pipeline. Each run resolves the Autotask zone, fetches the current picklist, discovers candidate tickets, and sends each ticket title and description to the categorization engine. Human review is the default. If auto-apply is enabled, high-confidence matches can proceed directly, while needs-review, picklist-gap, and engine-error results remain queued for a reviewer.

The app checks each proposed category pair against active picklist values and confirms that the Sub-Issue Type belongs to the selected Issue Type. Autotask rate-limit responses receive exponential backoff, while other request errors become hard failures for that ticket. SQLite stores pending proposals and an append-only audit log. Each write attempt records the ticket ID, previous and proposed values, timestamp, and approving person or policy.

FastAPI interface · Claude API engine · SQLite storage · Docker deployment · submitted by the XL.net team

Active Directory Health Check & Audit Toolkit

A self-contained PowerShell CLI assesses Active Directory health, configuration, and security across forest, domain, replication, DNS, sites, domain controllers, privileged access, Group Policy, backup, capacity, and monitoring. It produces HTML, flat findings JSON, separate inventory JSON, and optional CSV. A source scan checks for forbidden commands before Active Directory access, while errors inside wrapped checks become Inconclusive results.

Each result uses a normalized Pass, Fail, AtRisk, NotApplicable, Inconclusive, or Manual status and includes evidence, severity, criteria, benchmark, recommendation, target, and collection time. The first substantive HTML section presents collected configuration details such as FSMO holders, domain controllers, sites, subnets, trusts, privileged group membership, Group Policy objects, DNS zones, replication summaries, and dcdiag results. Available details depend on the selected scope, modules, permissions, and successful collection.

The tool reports remediation as text and provides no mode that applies fixes. Missing optional DnsServer, GroupPolicy, or LAPS modules cause dependent checks to return Inconclusive or Manual results. The ActiveDirectory module is required. With operator approval or an explicit unattended option, the script can install missing RSAT modules on the computer running it; a separate option disables installation. It supports Windows PowerShell 5.1+ and PowerShell 7+.

Invoke-ADHealthCheck.ps1 · Version 1.3.0 · PowerShell 5.1+ and 7+ · HTML, JSON, optional CSV · submitted by Ljubodrag

SD ScoreCard Daily Fill

SD ScoreCard Daily Fill is a spreadsheet-bound Google Apps Script with a time-driven trigger in the midnight hour Central. It reads two scheduled Autotask CSV attachments from Gmail and places Combined Tickets, Tickets Closed, Documentation Closed, and Time Spent for each engineer in the SD ScoreCard column matching the reports’ date.

The report date determines the destination column, allowing late reports and backfills to reach the corresponding scorecard date. A write proceeds when both the Tickets and Time reports are present, carry the same date, and resolve to one daily column. Incomplete pairs, date mismatches, missing or ambiguous date columns, and summary-column matches stop the write. Manual on-demand attachments marked with the Immediate_ prefix are skipped because they contain partial-day counts.

Missing source values remain blank so they do not count as worked days in scorecard averages. Weekend is added to a blank status cell when an engineer is outside rostered days and has no data. Existing status choices remain unchanged, and suspected weekday holidays are flagged with no status entry. Formulas remain untouched. Each run emails a summary covering filled dates, dates not written, blank reports, cell changes, matching values, and blank metrics.

Time saved · 35 hours a month, reported by the submitter

Google Apps Script automation · Two Autotask CSV inputs · Gmail to scorecard workflow · Midnight Central trigger · submitted by the XL.net team

Slack Tag Digest

Slack Tag Digest turns Slack activity from the trailing 24 hours into an action-focused catch-up. It covers direct mentions, here and channel broadcasts in joined channels, direct messages, and replies in threads the user started or participated in, with emphasis on messages that may require a response.

The skill deduplicates messages that match multiple collection categories, resolves user IDs to display names, and fetches enough thread context to identify what is being asked without reproducing complete conversations. It prefers Slack activity or search tools when available and otherwise checks recent conversation history.

Results are grouped into Needs a reply, FYI, and Noise, with empty sections omitted. Needs a reply and FYI items identify the sender and channel, lead with the request or change, include a Slack permalink, and note explicit deadlines or blockers. Items are ordered by urgency and then recency, while Noise receives a single count line.

Slack catch-up · Reply triage · Thread-aware context · Weekday scheduling · submitted by the XL.net team

Slack Thread Archiver

Slack Thread Archiver is a Service Desk skill that collects Slack threads marked with #SaveConvo during a requested sweep. It stores searchable Markdown records by client, with transcripts, summaries, participants, ticket numbers when present, and open gaps. The archive supports later retrieval by client or topic and produces formatted text for manual entry into Autotask.

Slack is read through the Claude for Chrome extension without the Slack API. An active session and an open Slack tab are required, and the desktop application is not readable. The tag serves as a bookmark rather than an archive action. Background monitoring and detection of replies added after capture are outside the first version.

Client identification uses channel conventions and a local alias map. Threads with no identifiable client go to an unfiled folder, while a new or ambiguous client prompts a request for the canonical folder name. Before writing, the skill replaces credentials, healthcare identifiers, and specified legal matter identifiers with redaction markers. Internal hostnames, IP addresses, usernames, and IT staff names remain in the record.

Slack is read in Chrome · Records are stored as local Markdown · The Slack API is not used · submitted by the XL.net team

Ticket Precedent Search

This read-only skill helps escalations engineers find earlier Autotask tickets describing the same or a related problem. Using the Claude in Chrome extension and the user’s active Autotask session, it reviews a source ticket, searches for candidate cases, assesses their relevance, and reports useful ticket and resolution details in chat.

The skill accepts an Autotask ticket link or ticket number and works through the Autotask web interface because no API connector is configured for the account. For a ticket number, it can request a link or search within the Service Desk view. It reviews the title, description, issue type, sub-issue type, queue, category, status, priority, and available resolution details. It then selects three to six distinctive error codes, product names, or symptom phrases while excluding generic search terms.

The search starts with one or two specific keywords and can use issue type or queue filters when the relevant search view is available. It excludes the source ticket and adjusts keyword combinations when results are too broad or narrow, with a goal of gathering up to eight candidate tickets. Each candidate is checked for a matching symptom or root cause, not just a shared title word. Results include the ticket number and title, Autotask link, status, relevance explanation, and available resolution summary. If no relevant tickets are found, the response states that outcome and identifies the terms searched. The skill does not edit, comment on, close, or reassign tickets.

Autotask ticket search skill · Read-only · Active Chrome session required · Up to eight candidates · submitted by the XL.net team

Ticket Trend Analysis

Ticket Trend Analysis turns a PSA ticket export into a client-ready reduction analysis. It finds recurring problems, compares how their counts change across the available history, and grounds root-cause findings in ticket descriptions and resolution notes. It prioritizes issues using both trend and volume, scopes actions to non-project work, and produces a Markdown report with a formatted Excel workbook.

The skill accepts a directory containing a CSV or exported XLSX file and maps varied PSA column names. A usable created or opened date is required. Its default target is three months unless the user requests another period. If the file contains fewer than three months of records, it uses the available date range. If the newest ticket is more than a few days old, it anchors the window to that ticket rather than the current date. It omits trend claims when the history yields a single bucket.

Analysis begins with issue and sub-issue tag counts, then examines titles, descriptions, and resolutions for repeated hosts, users, vendors, systems, and error strings. Candidate clusters use ticket numbers, dates, and available text as evidence. Onboarding, change-control submissions, and internal documentation or administration are listed as excluded service work. The two deliverables are saved in a client-named subfolder, with copies placed in a second directory when the user names one.

CSV or XLSX input · Three-month default target · Markdown and Excel deliverables · Client-named output folder · submitted by the XL.net team

Queuebot

Queuebot is a Claude Skill that posts its owner’s Autotask queue summary in Slack on request. It reads the open queue and ticket details through the owner’s signed-in browser session, then presents each ticket as a concise line with the contact, client, current position, status, and due date.

Queuebot scans the last 20 messages in its configured Slack channel for the most recent case-insensitive queuebot trigger from its configured owner. It proceeds when the message is less than 90 minutes old and no owner-specific Queuebot summary appears after it. Without a qualifying trigger, it posts nothing and does not open the browser. This owner check lets multiple service desk members run separate instances in the same channel.

After a qualifying trigger, Queuebot reads the owner’s queue through Autotask MVC pages and opens each ticket detail page. It uses the Contact field for the person’s name and synthesizes the description with recent human notes to explain where work stands. Tickets are ordered by due date, soonest first. The summary excludes ticket identifiers, links, hours worked, queue names, credentials, and personal contact details. If the queue is empty, it reports that nothing is open. If a valid request cannot produce a summary, Queuebot replies in the trigger thread with a brief explanation.

SKILL.md · Slack connector · Claude in Chrome · Owner-configured instance · submitted by the XL.net team

Infrastructure Gap Analysis

Infrastructure Gap Analysis produces a standard Excel workbook that scores a client’s security, network, server, and workstation infrastructure against XL.net best practices. The skill uses XLing as the primary source for findings and severity, with Autotask, Gmail, and Google Drive providing corroborating context. A validator and approval gate precede workbook generation from a fixed template.

The workflow scopes the client and review period, looks for a prior workbook in Google Drive, and gathers current findings. Existing findings can be carried forward, remediated items can move to Normal, and new findings can be added. Wording starts from an approved content library and is adapted with supported client details, including device names, dates, counts, and costs. Confirmed healthy categories are retained with a green Normal status.

Before generation, the validator checks category names, status values, required sections, numeric budgets, unresolved placeholders, and topics excluded by the approved strategic brief. Its review packet includes the status mix, proposed budget, findings, warnings, and categories that the engine will strip. Noel’s explicit approval is required before the formatting script populates the fixed workbook template. Final verification covers the template layout, status colors, placeholders, budget total, and approved category list.

Excel workbook output · Four infrastructure sections · Seven workbook columns · Three status colors · submitted by the XL.net team

Incident Report Automation

Incident Report Automation is a Claude Skill designed to complete XL.net's standard Corrective Action Request, also called an incident report, from a fixed Word template and field guide. It conducts fresh research and root-cause reasoning for each incident, fills CAR Information and Root Cause Analysis, and leaves Action Verification and Validation or Review of Effectiveness blank for human sign-off. It can return an edited Word file or field-labeled text.

The skill reads the supplied CAR before drafting, retains supported prefilled content, and identifies the fields that need work. It resolves ticket details, timelines, systems, client contacts, and internal roles from available records. Report language is plain and factual, with accountability assigned to the documented role and process step.

Long-term actions connect a concrete procedure, checklist, or template change to an issue on the appropriate Projects or Service Delivery IDS.

Fixed CAR template · Fresh RCA research · Evidence-qualified wording · Word or field text · submitted by the XL.net team

SOQL / Report Request Translator

This Claude Skill converts plain-English Salesforce data requests into SOQL queries or report specifications. It draws on the org's documented object model, exact API names, relationships, report types, query conventions, and governor-limit guidance, then explains assumptions and material ambiguities before presenting the deliverable.

The skill maps business terms to Salesforce objects, filters, and fields required for the requested output. It restates the interpreted request in plain language, resolves clear details, and surfaces an assumption or question when ambiguity changes the result. It uses API names from the object-model references. If a required object or field is absent, it requests confirmation instead of inventing a name.

For reports, the skill defines the report type, format, primary object, filters, groupings, columns, sorting, and scope or date range. It compares the request with the report types documented in its reference. When those documented types do not cover the required object combination, it describes the custom report type and relationships that an administrator would need to configure. Bundled scripts re-export the Salesforce schema and regenerate the object-model index, while custom report types require manual review in the separate report-types reference.

Claude Skill · SOQL and report specifications · 20 custom business objects · 15 standard objects · submitted by Mario

Asset Lifecycle Workbook Builder

This tool builds a standard Excel workbook that inventories client hardware, software licenses, cloud services, and service providers. It turns confirmed asset data into a forward-looking lifecycle plan covering replacement, renewal, retirement, monitoring, timing, and projected cost. A guided process gathers evidence, derives proposed actions, validates the asset data, and populates the fixed workbook template.

Designed for client owners and executives, the workbook emphasizes business planning rather than part numbers or infrastructure scoring. Its 12 columns record asset identity, vendor, serial number, description, purchase and support dates, end of life, action, price, timeframe, and comments. Four sections appear in a fixed order for network infrastructure, software licenses, cloud and SaaS software, and service providers. Empty section bands remain visible to show where no assets are tracked.

Autotask configuration items provide the primary inventory data, including models, serial numbers, vendors, purchase dates, and warranty or end of life dates. Active opportunities can inform the action, timeframe, and cost when replacement or renewal work is in progress. XLing, Gmail, and Drive corroborate deployment and lifecycle details. The workflow requires Noel’s explicit approval of the review packet before generation. The formatter then populates the fixed Excel template without changing its columns or section order.

Standard .xlsx deliverable · Executive lifecycle planning · Autotask led inventory · Fixed template output · submitted by the XL.net team

Key Takeaway

This automation searches recent Gmail threads for Zoom transcript content and creates one reviewable email draft per qualifying meeting. Each digest focuses on decisions, action items, owners, dates, risks, blockers, and open questions stated in the transcript. A processing label and draft-subject check help prevent duplicate drafts.

The search covers about 48 hours unless the user requests another range. Candidate threads are opened to inspect their full content. Messages with transcript text qualify for summarization, while unrelated notices and recording notifications that contain only a transcript link do not produce drafts.

Draft subjects include the meeting topic and date. The body presents a concise bullet list in plain text and HTML, with guidance to use four to eight bullets and fewer for a short call. The automation writes drafts for review and editing but does not send email.

SKILL.md · 48-hour inbox window · Takeaways-Processed label · Drafts only · submitted by the XL.net team

Azure VM Audit Skill

Azure VM Audit Skill builds and maintains a single-file PowerShell and Windows Forms desktop tool for auditing Azure virtual machines. The tool supports Azure sign-in, enabled subscription selection, parallel VM inventory, BIOS serial number queries for running VMs, live result display, and UTF-8 CSV export. It also defines the interface, architecture, column set, permissions, troubleshooting guidance, and delivery checks.

The desktop interface provides sign-in, subscription selection, Run Audit, Stop, Export Report, Clear, progress, activity log, and results controls. A reduced column view appears by default, with a checkbox for displaying the full set. CSV exports contain every column, including placement, state, size, operating system, image, security, disk, network, identity, extension, backup, tag, and reference data.

The audit uses a separate runspace pool for each subscription and processes subscriptions in sequence. A 300 millisecond Windows Forms timer transfers logs and result rows to the interface while Azure operations run outside the UI thread. Each VM worker produces one row and records errors in AuditNotes. Reader access supports inventory collection. Serial number collection also requires the virtual machine Run Command action, while backup data requires Backup Reader access on the vault.

One PS1 file · UTF-8 CSV export · Thread range: 1 to 32 · UI refresh interval: 300 milliseconds · submitted by the XL.net team

Daily Status Report Generator

It converts meeting notes, standup notes, call transcripts, and dictated shorthand into a formatted daily status report. The skill reads pasted text or supported files, edits the material into professional prose, organizes it into four report sections, and produces a Word document while retaining source details and avoiding unsupported additions.

Inputs can be pasted text or TXT, Markdown, DOCX, and Zoom VTT file paths. For VTT transcripts, the skill strips timestamps and speaker cues before processing. It routes substantive material among Completed Tasks, In Progress, Next Steps, and Action Items, in that order, and omits empty sections. Completed work that also requires follow-up creates separate entries for the work and the follow-up.

The skill corrects grammar, spelling, punctuation, tense, and transcription artifacts. It expands shorthand when the meaning is clear and preserves ticket IDs, service names, version numbers, error codes, environment names, endpoints, metrics, and table or branch names. It does not add facts, statuses, percentages, dates, owners, or causes absent from the notes. Ambiguous material stays close to the source, appears in the closest section, and receives a confirmation flag.

Claude Skill · Output is a DOCX report · Inputs include text and supported document files · The report uses four ordered sections · submitted by the XL.net team

Autotask Contacts Audit

This Claude Skill cross-references four Autotask and Microsoft 365 or Entra ID exports to find active contacts without support coverage. It separates verified contacts by license status, routes unverifiable or blocked records within the active and unsupported population to Needs Review, and reports 12 months of ticket activity in a versioned workbook.

The audit joins each Contacts List name to the Sync Group displayName, then joins the resulting user principal name to the Active Users List for license and sign-in status. A contact is unsupported when No Support equals 1. The audited population requires the contact record to equal Active and the Block credential value to equal False. A Licenses value of Unlicensed is classified as unlicensed, while any other value is classified as licensed.

The workbook contains Summary, Licensed, Unlicensed, Needs Review, and Ticket Count sheets. Needs Review includes active, unsupported contacts that cannot be verified or are blocked from signing in, with a reason for review. Ticket Count presents the most recent 12 calendar months from newest to oldest, includes a running total, and sorts contacts by total ticket volume. Sheets with no records receive a green banner describing the completed check and empty result. Sheets containing records receive a yellow review banner. Output filenames use an incrementing version number to preserve earlier workbooks.

Four required exports · Five core sheets · 12 calendar months · Versioned XLSX output · submitted by the XL.net team

Autotask Ticket Analysis

Autotask Ticket Analysis examines a named client’s support tickets from the previous 30 days. It analyzes tickets pulled from the client-filtered AD Ticket Review dashboard or supplied in an uploaded file, identifies patterns within and across categories, and assigns High, Medium, or Low priorities for point-of-contact discussion. It produces a written analysis and an Excel workbook for documentation.

The workflow reviews each displayed Top Sub Issue Type row, including additional rows created by ties and separate categories that share the same label. For each ticket, it captures the number, title, status, assigned resource, created and due dates, worked and billed hours, and description. Category analysis covers common threads, ticket volume, total and average effort, business impact, and suggested actions. A cross-category date check identifies clusters that could indicate a shared incident.

The written report opens with High-priority items and provides a reason for each priority assignment. Its category sections include ticket details, pattern findings, impact metrics, actions, and point-of-contact relevance. The Excel workbook contains a Summary sheet for category-level findings and a Tickets sheet for ticket-level records, inferred resolutions, and individual discussion flags.

Live formulas preferred · Priority cells color-coded · Created and due dates captured · submitted by the XL.net team

Termination check

Termination check searches Slack history for records related to a named person’s termination, offboarding, separation, or departure. It reconstructs available ticket details and event sequences from AutoTask bot notifications, shift handoffs, CSAT posts, and conversations. Results remain scoped to Slack because ticket bodies, work notes, and tickets that leave no identifiable Slack trace are outside its view.

The skill searches public and private channels, direct messages, and group direct messages. It checks full and reversed names, surnames, usernames, nicknames, hyphenation variants, and generated spelling candidates. A separate keyword pass covers offboarding language. The default lookback is 12 months, and the search widens when the first pass finds no evidence. Results state when no record appears in Slack rather than concluding that no ticket exists.

Matching events are placed in date order to show opening, deactivation, activity, handoff, and closure signals. This sequence can indicate progress, delay, or offboarding activity without a matching ticket-opening notification. When a ticket appears, the response provides supported details and a ticket link for the full notes. It avoids speculation about why someone left and omits conduct or performance details.

The search uses Slack history only. · The default lookback is 12 months. · Kaseya RMM export review is optional. · submitted by the XL.net team

Rippling Mileage Entry

Rippling Mileage Entry prepares mileage reimbursement drafts in Rippling from qualifying Google Calendar events. It filters calendar locations for street addresses, supports separate round trips or a same day route with multiple stops, and leaves entries as drafts for review. Submission occurs only when the user requests it.

For a selected date range, the skill reads the user's primary Google Calendar and identifies work events whose locations include a street address with a house number. It excludes meeting links, conference room labels, non-work or social events, and place names without street addresses unless the user provides further direction. Before entry, it confirms the home address, route treatment for days with multiple destinations, and the proposed list of dates, destinations, and purposes.

In Rippling, the skill records separate home to destination to home trips or a route with stops, according to the user's choice. It confirms the mileage rate when Rippling presents multiple options, assigns the Travel category, and adds a memo containing the event, destination, and round trip description. Drafts marked as missing requirements receive a cropped route map image as a receipt. The final table lists each trip's date, destination, miles, and amount, while identifying missing addresses, ambiguous rates, and unexpected or empty drafts.

Claude Skill · Google Calendar to Rippling · Draft first workflow · Map image receipts · submitted by the XL.net team

Daily Email Digest

Daily Email Digest reviews unread Gmail threads from a rolling 24 hour window and organizes them into five triage categories. It can retrieve full thread content when a snippet is unclear or an action item needs a more precise description. It outputs the digest in the conversation and a dated Markdown file.

The workflow searches a two day window for unread threads, excludes drafts, and removes results older than the calculated cutoff. It requests sender, subject, snippet, and date through a minimal thread view. Results use a page size of 50 with pagination when the response is truncated.

Each thread goes into Action Needed, Waiting/FYI, Meetings/Calendar, Newsletters/Promotions, or Other. A July 29, 2026 digest covered four unread threads containing six messages. It identified one item needing action that day, involving one procedure review due that day and another due August 5.

SKILL.md · Gmail MCP connector required · 50 thread page size · Full thread lookup · submitted by the XL.net team

Autotask Queue Classifier

Reviews ticket titles and descriptions from a configured Autotask support queue and proposes Issue Type and Sub-Issue Type classifications. The skill works from the tenant's current taxonomy, keeps dependent category choices aligned, and can handle a queue batch or a ticket identified by internal ID. It seeks user confirmation before production changes unless automatic application has been explicitly authorized.

The workflow reads Autotask API credentials and the support queue ID from environment variables. At session initialization, it resolves the tenant's Autotask zone and reuses that zone for later requests. Its bulk query selects tickets in the configured queue with no Issue Type and status value 1. That status must be checked against the tenant's status picklist when its meaning is uncertain. A ticket supplied by internal ID can be retrieved directly.

The skill weighs the title more heavily than the description when they conflict and favors a specific category over a general option. If no category fits, it can propose a general value or flag the ticket for human review. Its proposal table includes the ticket number, title, proposed categories, and a short reason. After approval, it updates both fields through the Autotask API and reports successful changes and returned errors.

ticket-categorizer/SKILL.md · Autotask REST API · dependent picklists · reviewed classification · submitted by the XL.net team

Kickoff Agenda

Kickoff Agenda turns a technical project plan into a polished Word document for a client kickoff call. It translates internal detail into plain language and keeps the result to a short call guide rather than restating a large plan. A required project plan supplies the content, and an optional prior agenda or template can shape its presentation.

The workflow accepts a plan as a Word document, PDF, Markdown file, text file, or pasted content. It identifies the project goal, major work, client approvals or inputs, phases or timeline, and expected effects on end users. The resulting agenda covers the work, client actions, milestones framed around client impact, and information staff should receive.

When a Word template is supplied, the workflow extracts heading colors, title color, and body and heading fonts. It can also mirror the template's section structure and tone where appropriate. Without a template, it uses blue Calibri headings and Cambria body text. Structured agenda content is built into a DOCX file, rendered, and checked for visual fit, matching styles, and leftover jargon before delivery.

DOCX output · Required project plan · Optional Word template · Typical length: 2 to 3 pages · submitted by the XL.net team

Patching Visualizer

Patching Visualizer turns three client-specific Kaseya VSA 9 exports into a clear, self-contained HTML Patch Management Summary for clients. The one-page dashboard presents applied updates, fleet status, queued work, and items that merit a quick check. Its documented logic separates approved outstanding work from excluded approval states and avoids treating every outstanding patch as a failed deployment.

The build script takes a client display name and total fleet size. Fleet size is supplied separately because the exports do not contain the complete device count. The reporting month can be specified or can default to the most recent month in the Completed Patches report. The script prints figures for completed and outstanding updates, fleet status, exclusions, and machines flagged for review so they can be checked against the exports.

Output quality control includes opening or capturing the generated HTML to confirm correct rendering and identify layout overflow before delivery.

Time saved · 5 hours a month, reported by the submitter

The output is one self-contained HTML page. · The workflow supports one client and reporting month. · submitted by the XL.net team

Slack Knowledge Assistant

The Service Desk Knowledge Assistant is designed to turn an Autotask ticket number into ranked, cited SweetProcess documentation and a suggested resolution path formatted for Slack. It identifies the underlying issue, searches for existing procedures, evaluates retrieved candidates, and presents relevant results without inventing documents or unsupported steps.

The workflow retrieves the ticket from Autotask and reviews its title, description, ticket notes, user request, internal notes, company, asset, contact, category, subcategory, issue type, and available resolution history. If the ticket cannot be found, the workflow stops rather than making assumptions. It extracts multiple issue terms when needed, then searches SweetProcess with literal keywords, synonyms, related products, and ticket categories.

Candidate ranking gives priority to a client-specific procedure when one exists, followed by exact keyword or title matches, product or technology matches, issue-type matches, an approved or current document version, and prior successful use when that data is available. Results use High, Medium, or Low confidence bands grounded in retrieval signals. Low-confidence documents are labeled as potentially related, while a search with no relevant result produces a no-match notice. The Slack response includes ticket details, the detected issue, recommended documents, a suggested resolution order, and related procedures.

The workflow uses Autotask and SweetProcess. · Confidence uses three defined bands. · Output is formatted for Slack. · submitted by the XL.net team

Secure+ coverage audit

The Secure+ coverage audit reconciled Kaseya VSA9 endpoints with SentinelOne, RocketCyber, and DNSFilter exports to identify coverage gaps. It rebuilt the SecurePlus endpoint audit workbook and compliance metric, calculated CS and Security metrics, and rebuilt the Kaseya Client Endpoint Tracker keyed on VSA9 group ID.

The audit expected SentinelOne on every VSA9 endpoint. RocketCyber covered selected clients, while DNSFilter covered selected client workstations. Placeholder records that lacked OS, IP, serial, and check-in time were listed separately and excluded from gap counts. Endpoints with no check-in for more than 90 days were marked stale. SentinelOne matched by hostname or normalized serial, whereas RocketCyber and DNSFilter matched by hostname only.

Duplicate hostnames were associated with every client that owned them. Client-name mappings required at least three agreeing endpoints and a 60 percent share of matches. When the team workbook was supplied, client columns on the RocketCyber Gaps and DNSFilter Gaps sheets defined entitlement, including empty columns. Without that workbook, the audit drafted entitlement categories from observed deployment rates for staff confirmation. The refresh used exceptions and technician annotations to suppress identified gaps. The CS and Security Metrics were the means of the three deployment and three compliance rates, respectively.

Three audit scripts · 90 day stale threshold · Workbook based entitlement · VSA9 group ID tracker key · submitted by the XL.net team