POC: runnable extension skeleton that drives @cline/sdk #2

New Issue

2026-06-10T06:14:45Z

benstull commented

2026-06-10 06:14:45 +00:00

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).

## 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).

benstull added the type/feature priority/P1 labels 2026-06-10 06:14:45 +00:00

benstull referenced this issue

2026-06-10 06:15:04 +00:00

VS Code coauthoring plugin built on Cline (@cline/sdk) #1