Meta: review Claude-scoped adaptor issues and define an "Adaptor Scoping" Claude Skill #1814

Context

I've been working with Claude to scope new adaptors using our GitHub "New Adaptor" template. Claude does the research (API docs, auth, sandboxes, rate limits, prior art) and fills in the template with what I understand you need to deliver an adaptor.

I'd like to turn this into a reusable Claude Skill. Even though my team would use it, the Skill's purpose is to give the people building the adaptor the best possible information (and help them estimate). So I think it should be owned by a technical person, not by Growth.

Before we build it, this issue is to review the issues scoped so far: how helpful, annoying or "Claude-y" are they?

Claude-scoped issues to review

#	Adaptor	Type	Driver / deadline	Label
#1806	OpenG2P	New	Social protection DPG; no sandbox	P2
#1807	Copper CRM	New	Copper + lemlist use case	P2
#1808	lemlist	New	Sibling of #1807	P2
#1810	Eclipse OIE (Mirth)	New	NovaMap joint demo	P2
#1811	OpenStreetMap	New	SotM LATAM talk, v1 by ~23 Oct	none
#1812	mWater	New	WASH use case, end Dec	none
#1813	mtn-momo Disbursement	Extension	Payments use case, end Dec	none

Things I noticed going back through them:

• Format drift. New adaptor: OpenG2P #1806–New adaptor: OpenStreetMap (Overpass, OSM API, Nominatim) #1811 follow the template (Request / Credentials / Sample Code / Resources). New adaptor: mWater #1812 and mtn-momo: add Disbursement helpers (transfer, status, balance, account validation) #1813 use a different shape (Summary / Proposed functions / Acceptance criteria / Open questions).
• Scope vs. intent. Several list 10–14 requirements (full paging, retries, rate-limit handling, mocks for every operation) even where the real goal is a demo. New adaptor: OpenStreetMap (Overpass, OSM API, Nominatim) #1811 is needed for a live talk in under three weeks.
• Test environments vary a lot: free trials that expire after 14 days (New adaptor: Copper CRM #1807, New adaptor: lemlist #1808), a partner-hosted dev instance (New adaptor: Eclipse Open Integration Engine (OIE) #1810), public sandboxes (New adaptor: OpenStreetMap (Overpass, OSM API, Nominatim) #1811, mtn-momo: add Disbursement helpers (transfer, status, balance, account validation) #1813), and a 16 vCPU / 64 GB self-install with no public sandbox (New adaptor: OpenG2P #1806).
• Priority labels are inconsistent: four are P2, three have none, and only New adaptor: OpenG2P #1806 has an assignee.

What I'd like from reviewers

For each issue (or a sample), a quick reaction on:

1. Helpful: what saved you time? (e.g. auth gotchas, sandbox links, sample code)
2. Annoying / noise: what would you cut? Is anything over-specified or too prescriptive about function names?
3. Wrong or unverifiable: anything Claude stated confidently that turned out to be wrong?
4. Missing: what do you always need that isn't there? (e.g. effort estimate, which existing adaptor to copy from, credential schema)
5. Estimate: a rough size (S/M/L) so we can calibrate future scoping.

Proposed Skill design (for discussion)

Decision point 1: how mature does this adaptor need to be?

The Skill should walk the requester through this question up front and scope accordingly:

• (a) Demo-ware. As minimal as possible: auth, a generic request(), and the 1–3 operations the demo needs. Should not require a fully functional test environment. Mocked tests and a recorded happy path may be enough.
• (b) Production / specific goals. Defined use cases that must be tested and working. Should require a real test environment (sandbox, trial or partner instance) with credentials stored before work starts, plus acceptance criteria.

Open question: is there a middle tier, or does (a) just become (b) later via a follow-up issue?

Decision point 2: P1 vs P2

We need a shared definition the Skill can apply (and explain) rather than guess. Strawman for engineers to correct:

• P1: a committed delivery (contract, live client, dated demo or event) is blocked without it.
• P2: strategic or pipeline value, no hard date.

Other things the Skill could standardise

• One output format (the template, plus an Acceptance criteria and Open questions section).
• A clear "out of scope for v1" list.
• Credentials: where to get them and the LastPass naming convention, never the values.
• Flag what's verified vs. inferred from docs.

Proposed next steps

• Reviewers leave feedback on the issues above (comment here or on each issue)
• Agree the maturity tiers (a/b) and what each requires for testing
• Agree the P1 / P2 definitions
• Nominate a technical owner for the Skill
• Owner drafts the Skill; Jack tests it on the next adaptor request