Harrison Halperin

Provider integration case file

Connect Layer

Integration diligence as structured, queryable specs

Prototype

A Cursor plugin that runs OAuth diligence (cited ToS and pricing research, registration checklist, verification plan) before any integration code is written.

RoleDesigner & builderOpenedJun 2026

Harrison Halperin

Project brief

Prototype

Problem

Agent tools become hard to trust when connectors expose inconsistent contracts and permissions.

Outcome

A Cursor plugin that runs the diligence phase of a third-party OAuth integration (cited Terms-of-Service and pricing research, a registration checklist, a verification plan) before any code is written. A Python ingest step folds the results into a schema-validated, queryable provider registry.

Evidence

  • The project separates a declarative authoring layer (a Cursor slash command, five phase skills, and a sandboxed background research agent) from a data layer of three Python scripts, about 628 lines total, that ingest the resulting Markdown into a JSON-Schema-validated provider registry.
  • The ingest function is the graph's clear hub, with a battery of regex parsers lifting prose tables into 19 required schema fields before validation.
  • Confidence is tied to whether the required web-search tool actually ran, not to how findings read, a self-review caught a case where that rule was violated and logged a fix.

Key decisions

  • Authoring layer: A slash command and five phase skills orchestrate intake, diligence, registration, and verification behind human checkpoints.
  • Background research agent: Runs sandboxed with a tools allowlist; treats fetched web content as untrusted and never reads secrets or fabricates citations.
  • Target project artifacts: Diligence findings are written as Markdown into the project being integrated, not into the plugin's own repo.
  • Data layer: Three Python scripts parse, validate against a JSON Schema, and write a queryable per-provider spec registry.

Case file opened

Agent tools become hard to trust when connectors expose inconsistent contracts and permissions.

Diligence finishes before any OAuth integration code is written.

The record

I built a Cursor plugin that finishes diligence before any OAuth integration code gets written. A slash command, five phase skills, and a sandboxed background research agent produce cited Terms-of-Service and pricing research, a registration checklist, and a verification plan as Markdown in the target project. Three Python scripts ingest that Markdown into a JSON-Schema-validated provider registry. A registry-first rule lets a later run query prior diligence instead of re-researching it. Confidence is tied to whether the required web-search tool actually ran, not to how findings read. The research agent cannot read secrets, trust instructions embedded in fetched web content, or invent citations. v1 stops at research and checklists; code generation is deferred. Calendly and OpenTable dry-runs each produced 40+ cited claims and a go/no-go recommendation. One service layer, many surfaces is the essay form. MeTime is the personal-app version of the same thin-surface pattern.

How the registry gets built

The plugin separates a Cursor-side authoring pipeline that produces diligence artifacts from a Python data layer that parses, validates, and indexes them into a queryable registry.

Fig. 01

Authoring pipeline to validated registry

01
Developer request/connect-provider <name or goal>, run inside the IDE
02
Phased skill orchestrationintake -> diligence -> registration -> verifydiligence hands off to a sandboxed background research agent; each phase stops at a human checkpoint
03
Diligence artifactsMarkdown written into the target project being integrated
04
Schema-validated ingestregex parsers assemble a spec, validated against a JSON SchemaGate
05
Queryable registryper-provider spec plus a regenerated indexlater runs query this before re-researching a provider

A slash command drives phased skills and a sandboxed background agent to produce diligence artifacts, which a Python ingest step turns into a schema-validated, queryable spec.

Fig. 02

Markdown-to-spec ingest loop

1
Load schemaJSON Schema, Draft 2020-12
2
Parse provider markdownsingle-purpose regex parsers per field
3
Assemble spec
4
Validateschema errors empty?
5
Write spec, next providerloops to the next slug; index regenerated once all slugs finish
loops to the next slug

For each provider slug, parsers lift prose tables into a spec, which is schema-validated before being written and the registry index is regenerated.

Registry fields

Authoring layerA slash command and five phase skills orchestrate intake, diligence, registration, and verification behind human checkpoints.
Background research agentRuns sandboxed with a tools allowlist; treats fetched web content as untrusted and never reads secrets or fabricates citations.
Target project artifactsDiligence findings are written as Markdown into the project being integrated, not into the plugin's own repo.
Data layerThree Python scripts parse, validate against a JSON Schema, and write a queryable per-provider spec registry.
Confidence gatingA spec is flagged reduced-confidence whenever the required search tool did not actually run, independent of how polished the output reads.

Trust boundary

  • The research agent cannot read secrets, trust instructions embedded in fetched web content, or invent citations.
  • The research agent cannot read secrets, trust fetched instructions, or invent citations.
  • Confidence is tied to whether web-search actually ran, not to how findings read.

Two dry runs

Calendly and OpenTable dry-runs each produced 40+ cited claims and a go/no-go recommendation.

Calendly
Cited claims40+
OutputGo/no-go recommendation
OpenTable
Cited claims40+
OutputGo/no-go recommendation
  • The project separates a declarative authoring layer (a Cursor slash command, five phase skills, and a sandboxed background research agent) from a data layer of three Python scripts, about 628 lines total, that ingest the resulting Markdown into a JSON-Schema-validated provider registry.
  • The ingest function is the graph's clear hub, with a battery of regex parsers lifting prose tables into 19 required schema fields before validation.
  • Confidence is tied to whether the required web-search tool actually ran, not to how findings read, a self-review caught a case where that rule was violated and logged a fix.

v1 stops at research and checklists; code generation is deferred.

Capabilities ledger

01Python

Three Python scripts ingest diligence Markdown into a JSON-Schema provider registry.

02Agentic

A sandboxed research agent drafts cited findings; humans own go/no-go.

03Agent orchestration

Five phase skills plus a slash command sequence the diligence packet before code.

04Schemas

Regex parsers lift prose tables into 19 required fields, then validate against JSON Schema.

05Agent guardrails

The research agent cannot read secrets, trust fetched instructions, or invent citations.

06Security

Confidence is tied to whether web-search actually ran, not to how findings read.

07CLI

Slash command and scripts are the operator path into the diligence packet.

08OAuth

Connect Layer uses OAuth flows with explicit scopes for delegated access.

09API integration

Connect Layer integrates external services through stable auth and payload contracts.

10Cursor SDK

Ships as a Cursor plugin surface that wires connect-layer tools into the host agent.

Trace the registry in the graph

Portfolio graph

Hover nodes · click empty canvas to zoom/pan

Maps how the work here connects. Open the Portfolio graph →

  • Professional
  • Personal
  • Skill
  • Writing

Related work

MeTime →

Related writing

One service layer, many surfaces →Agents deserve a real context format →