Addie: resume pending GitHub issue draft after user connects GitHub

[bokelley]

Problem

A first-time member asks Addie to file a bug. create_github_issue returns the "not connected" message with a Connect link (PR #2967, #2979). The user clicks the link, completes the WorkOS Pipes → GitHub OAuth flow, and lands back at `/member-hub?connected=github`. But the original draft — the title/body they described to Addie — is lost. They have to come back to the Addie conversation and re-ask.

This is the biggest retention gap in the new GitHub-issue flow. The hardest part of the user's work (articulating the bug) already happened; we're making them do it twice.

Desired behaviour

When a user asks Addie to file an issue and hits the not-connected path:

1. Addie stashes the pending draft (title, body, optional labels) against the current conversation, keyed by a short opaque token.
2. Addie's Connect URL includes that token (as a query param on `return_to`, e.g. `/member-hub?connected=github&resume=`).
3. The member-hub page detects `?resume=` after a successful connect, and deep-links the user back to the Addie conversation with a hint that triggers Addie to call `create_github_issue` with the stashed payload — or surfaces a one-click "Want me to file that bug now?" button.
4. On success, Addie posts the issue URL.

Out of scope

• Any cross-channel persistence (Slack thread → web). The first iteration can be web-only and keyed by conversation ID.
• Arbitrary deferred tool calls. This is specifically for GitHub issue drafts.

Related

• feat(addie): file GitHub issues as the member via WorkOS Pipes #2967 — Pipes-based `create_github_issue` (merged)
• fix(addie): keep github issue tools reachable across Slack routing #2979 — always-available hint + connect-copy (pending merge)

Acceptance

• Draft survives a cold OAuth round-trip.
• Token expires after 15 minutes.
• Test covers the stash → connect → resume path (mocked WorkOS + GitHub).
• No cross-user contamination — token is scoped to the original `workos_user_id`.

[bokelley]

Triage

Classification: Feature request
Bucket(s): addie
Status: ready-for-human

What the experts said:

• prompt-engineer: Must-fix: in-memory draft stash silently breaks on multi-instance Fly.io — a DB table is required if going server-side. The design also conflates two implementation paths (auto-fallback vs. stash-and-resume) that need a conscious choice before any code is written. One immediately shippable improvement needs no architecture decision: update the create_github_issue tool description to co-call draft_github_issue in the same turn so the user always gets a pre-filled fallback link.
• user-engagement-expert: Clear win; chat.html's existing checkQueryPrompt (?prompt=) already auto-fires messages; recommends DB stash keyed to (workos_user_id, conversation_id) with 30-min TTL; auto-file without re-confirming (user already approved the draft before clicking Connect).
• internal-tools-strategist: Simpler alternative — URL-encode the draft directly into return_to as /chat?prompt=...; no server storage at all. URL length is the only risk for long issue bodies.

My take: The pain is real and the fix is non-breaking, but experts surfaced a hard blocker (in-memory stash fails silently on multi-instance Fly.io) and two distinct implementation strategies that need an explicit decision. The tool-description change (member-tools.ts:1179 — instruct Claude to co-call draft_github_issue in the same turn as the "not connected" message) is an immediately executable quick-win that ships regardless of which path you choose for the full feature.

@bokelley, your call: (A) ship the tool-description quick-win now and defer stash-and-resume, or (B) go straight to the full feature — and if B: URL-encode draft into return_to (simpler, URL-length caveat on long bodies) or DB table (robust)?

---

Triaged by Claude Code. Session: https://claude.ai/code/session_01YCu9tCDvTBRgBFvTdfGKr7

---

Generated by Claude Code