Custom skill, plugin, and connector development
Lightbridge Labs builds custom Claude skills, plugins, MCP connectors, and PreToolUse hooks as production software, not prompts. Prompt engineering alone cannot satisfy a regulated buyer's security, audit, and data-protection review. Production AI needs deterministic guardrails the model cannot talk past: scoped permissions, signed version-pinned artifacts, and audit evidence the customer centrally controls.
Why custom development now
The buyers asking this question are not asking for an AI experiment. They are asking how to put a Claude capability into the hands of every authorized user in a way that satisfies the security team, the audit team, and the data-protection officer. That requires four shifts at once. Capabilities have to become signed, version-pinned artifacts rather than copied prompts. Tool access has to be scoped at the artifact level, not the prompt level. Audit evidence has to live in the customer SIEM, not in vendor logs. Deployment has to land through the existing MDM, not by emailing instructions to each user.
Each of the four shifts is a software-engineering problem. Lightbridge solves them as a service.
What we build
Custom skills
Packaged, version-pinned capability bundles (read this data set, draft this report, run this reconciliation) that the customer central plugin marketplace publishes once and every authorized team consumes the same way. Replaces ad-hoc prompt copy-paste with a reviewed, signed artifact.
Custom plugins
Plugin packages that bundle skills, hooks, agents, and MCP server declarations into one signed unit. The customer holds the signing key and the marketplace JSON; the plugin source is pinned to a commit SHA the customer security review approved.
Custom MCP connectors
Application-tier services that expose the customer own systems (NetSuite, Google Sheets, internal data warehouses) to Claude through the Model Context Protocol. Built for centralized policy enforcement, scoped audit logging, customer-managed encryption keys, and tenant isolation.
Custom hooks
PreToolUse, PostToolUse, and SessionStart shell-command hooks that enforce deterministic checks on every model invocation: secret-leak detection, path allow-lists for Write and Edit, confirm tokens on destructive operations, and structured audit-event emission.
Central marketplace setup
Private plugin marketplace stood up in the customer Git host with branch protection, signed commits, and managed-settings deployment to every workstation. A capability ships to the entire fleet by bumping a SHA in marketplace JSON.
Open-source delivery
Every artifact ships under a permissive open-source license so the customer security review can read the source before any deployment. The deployment lands inside the customer environment with no data, prompts, or credentials returning to Lightbridge.
Claude integration work that is specific to NetSuite, including SuiteScript, the financial close, and revenue recognition, is delivered by Lightbridge ERP. This page covers the general custom-artifact engineering that underpins any such integration: the skills, plugins, connectors, and hooks themselves.
The Lightbridge Google Sheets connector.
An open-source custom MCP connector with OAuth 2.1 plus PKCE, scoped Google API permissions, customer-managed KMS keys, audit logs written to a customer-owned S3 bucket with Object Lock for SOX-grade retention, and single-use HMAC confirm tokens on destructive Sheets operations.
The deployment is a one-click CloudFormation template into the customer AWS account. The customer holds the secrets, controls the IAM roles, and owns the operating evidence. The same pattern applies to any customer system the buyer needs Claude to reach.
What the worked example proves:
- OAuth scope minimization is enforced at the connector source.
- Customer-managed KMS encrypts every token at rest with user-bound encryption context.
- Refresh tokens rotate on every use and are persisted only as sha256 hashes.
- Confirm tokens are HMAC-bound to the user, the tool, and the canonical arguments.
- Audit events route to the customer SIEM with the schema the SIEM expects.
- The admin plane is segregated to an internal NLB with HMAC authentication.
- The container image is digest-pinned; mutable tag substitution is foreclosed.
- Source is open and reviewable; deployment is entirely in the customer account.
Beyond prompt engineering
Prompt engineering remains useful as a per-user practice. It does not produce auditable artifacts and it does not scale to centralized control. Custom skills, plugins, MCP connectors, and hooks are the software substrate that turns a governance policy into an enforceable control. ISO 42001 expects monitoring and audit; the EU AI Act expects human oversight and logging; SOX expects separation of duties and evidence retention; SOC 2 expects access controls and change management. Each maps directly onto a primary control inside a signed artifact and a compensating control inside a hook.
Lightbridge builds the governance framework and the software substrate side by side, so the policy and the code that enforces it ship together.
Open source. Customer-hosted. Audit-ready.
Every custom artifact ships under a permissive open-source license. The customer security review reads the source. The deployment lands in the customer environment. The customer holds every secret and owns every audit log.
Frequently asked questions about custom AI development
- Why is prompt engineering not enough for production AI?
- Prompt engineering alone is a per-user practice. It produces inconsistent results, leaves no audit trail, cannot enforce least privilege, and gives the security team nothing to review. Production AI for a regulated buyer requires deterministic guardrails the model cannot talk its way past: scoped tool permissions, signed and version-pinned plugins, PreToolUse hooks that reject malformed payloads, single-use confirm tokens on destructive operations, audit-log shapes the SIEM understands, and OAuth scope sets the data classifier can defend. These are software artifacts, not prompts.
- What is the difference between a Claude skill, plugin, MCP connector, and hook?
- A skill is a packaged capability bundle (read this data set, draft this report, run this reconciliation). A plugin bundles skills, hooks, agents, and MCP server declarations into one signed unit that a marketplace publishes. An MCP connector is an application-tier service that exposes the customer system to Claude through the Model Context Protocol. A hook is a shell command that fires on a Claude lifecycle event (PreToolUse, PostToolUse, SessionStart) and enforces a deterministic check. All four are version-pinned, security-reviewed software artifacts.
- How does central control of AI capabilities work?
- The customer holds a private plugin marketplace, typically a Git repository with a marketplace.json that names every approved plugin and pins each one to a commit SHA. Managed settings push the marketplace location and a list of allowed marketplaces to every workstation through the existing MDM (Jamf, Kandji, Intune, GPO). A capability ships to the entire fleet by adding it to marketplace.json. A capability update ships by bumping the SHA. A revocation removes the entry; the artifact is uninstalled at the next session start. Central control is not a promise; it is a deploy mechanism the customer operates.
- What kinds of deterministic guardrails can hooks enforce?
- A secret-leak hook exits non-zero on Google OAuth, PEM private-key, AWS Secrets Manager, or tenant-specific secret shapes. A path allow-list hook blocks Write and Edit outside an approved directory tree. An audit hook emits a structured event on every tool call into the customer SIEM. A confirm-token hook requires single-use HMAC tokens on destructive operations. Hooks run with the operator privilege as deterministic shell commands; their output exit code controls whether the model can proceed.
- Does Lightbridge retain customer data or prompts?
- No. Lightbridge ships every artifact under a permissive open-source license. The customer security review reads the source before any deployment. The deployment lands in the customer AWS account, NetSuite instance, or workstation fleet. No prompts, OAuth tokens, audit logs, or customer data are sent to Lightbridge. The customer holds every secret and operates every artifact.
- How does this relate to the Lightbridge Google Sheets connector?
- The Lightbridge Google Sheets connector is the worked example. It is an open-source custom MCP connector with OAuth 2.1 plus PKCE, scoped Google API permissions, customer-managed KMS keys, audit logs to a customer-owned S3 bucket with Object Lock, and single-use confirm tokens on destructive operations. The deployment is a one-click CloudFormation template into the customer AWS account. The same pattern applies to any customer system the buyer needs Claude to reach.
- What is the connection between custom development and AI governance?
- AI governance frameworks require deterministic enforcement points. ISO 42001 expects monitoring and audit; the EU AI Act expects human oversight and logging; SOX expects separation of duties and evidence retention; SOC 2 expects access controls and change management. Prompt engineering cannot deliver any of these. Custom skills, plugins, MCP connectors, and hooks are the software substrate that turns a governance policy into an enforceable control. Lightbridge builds both the policy and the substrate.
- Does Lightbridge develop only Claude artifacts, or other AI systems too?
- The current focus is the Claude product family (Claude Code, Claude.ai Enterprise, Claude Desktop, Cowork) and Amazon Bedrock. The architectural patterns (signed artifacts, central marketplace, deterministic hooks, scoped tools, customer-owned audit) generalize to other agentic AI systems. We will scope cross-platform work on request.
Take a Claude capability into production.
Start with a custom AI development scoping session. We will map the capability to the artifact types it needs, the central-control surface, the deterministic guardrails, and the open-source delivery posture.