vscode-cowriting-plugin-content/issues/poc-extension-cline-sdk.md

Summary

A standalone VS Code extension that activates in the Extension Development Host and runs one trivial Cline interaction via @cline/sdk — proving Approach A and giving every later coauthoring feature a place to land. A walking skeleton, not a shippable product.

Problem / pain

The whole Epic rests on one unproven bet: that our own standalone extension can programmatically drive the Cline agent through @cline/sdk. Until that is demonstrated end-to-end — repo builds → F5 launches the extension → a command invokes the SDK → a result comes back — there is no skeleton to build coauthoring into and the architecture is unvalidated. Every later Feature is blocked on this foundation existing.

Who feels it

The dev team building the plugin (this de-risks the architecture and unblocks all subsequent work); ultimately the coauthoring user who benefits from a sound foundation.

Desired outcome / value

A known-good starting point: the repo builds, the extension loads, and a command invokes @cline/sdk and surfaces a result — so subsequent Features (threads, attribution, propose/accept) have a foundation, and the @cline/sdk approach is confirmed early (or we learn early that it isn't viable, while the cost of changing course is still near zero).

Acceptance — "done right"

• The repo contains a buildable VS Code extension: package.json (publisher, engines.vscode, one contributed command + activation), tsconfig.json, an esbuild bundle, ESLint, .vscode/launch.json.
• Pressing F5 launches the Extension Development Host with the extension active.
• A contributed command (e.g. "Cowriting: Hello via Cline") invokes @cline/sdk to run one trivial interaction and surfaces the result (a notification or output-channel line). If a live agent turn needs credentials not present in CI, it is acceptable for the smoke path to instantiate the SDK and confirm the integration surface (version/connectivity) instead — the point is the wiring.
• One smoke test passes in CI (build + activate/import).
• It is explicitly NOT shippable and implements no coauthoring behavior — pure proof of concept + skeleton.

Scope / non-goals

In scope: the extension scaffold; @cline/sdk declared and wired; one SDK-driven command; the build / test / run (F5) loop; a one-line README on how to run it.

Out of scope: any coauthoring (threads, attribution, diff flow); packaging / marketplace publishing; auth/secret hardening beyond what a local dev run needs; multi-file or agent choreography.

Assumptions · constraints · dependencies

• @cline/sdk is installable via npm and runs under Node ≥22.
• A local Claude credential/config is available for a live SDK turn (the dev's existing setup); no secret bytes go in this repo or issue — the SDK reads them from the environment. (Open question: exactly what @cline/sdk needs to run a turn vs. just initialize — resolved during the build.)
• Parent: #1 (the coauthoring Epic). Blocks: F2–F5 (all later Features).
• Source: this capture session.

Source / signal

Capture session vscode-cowriting-plugin-0001; parent Epic #1 (coauthoring-plugin-on-cline). Architecture lineage: ben.stull/rfc-app#48.

Priority (WSJF)

Provisional: Value medium (pure enabler) · Time-criticality high (blocks every other Feature) · Opportunity-enablement high ÷ Size small → P1, do first.

Decomposition (Feature → slice checklist)

• Scaffold the extension (package.json, tsconfig.json, esbuild, ESLint, .vscode/launch.json).
• Add @cline/sdk as a dependency and wire a minimal client.
• Contribute one command that runs a trivial @cline/sdk interaction and shows the result.
• Add one smoke test + a CI workflow (build + test).
• README: "run it with F5" note.

Solution notes (optional — NOT a design)

Keep the SDK call trivial (a one-shot prompt, or even a version/connectivity check) — the value is the wiring, not capability. If @cline/sdk's surface differs from what we expect, that discovery is the value of this POC. Use conventional npm + TypeScript + esbuild for our extension (Cline's own monorepo uses Bun/Biome, but @cline/sdk is a plain Node package npm consumes fine).