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