Merge pull request #237 from PostHog/tom/self-driving-jira-source

feat(self-driving): add Jira as a connected-tool inbox source

Author: Gilbert09

context/skills/self-driving/description.md

@@ -17,7 +17,7 @@ Each step file points to the next. Run them in order. **Start by reading `refere
 - **Trust the setup report.** `./posthog-setup-report.md` is ground truth for what is instrumented. Scan the codebase only for what the report won't cover.
 - **Every write must be idempotent.** List before you create. A duplicate `inbox-source-configs-create` returns 400 — recover by finding the existing row's `id` and calling `inbox-source-configs-partial-update` with `enabled: true`.
 - **Never disable a source the user already enabled.** You only switch things on (and tune scouts off); existing enabled rows are someone's deliberate choice.
-- **Never enable a connected-tool source the user hasn't confirmed they use.** GitHub Issues, Linear, Zendesk, and pganalyze are ask-then-connect, never blind.
+- **Never enable a connected-tool source the user hasn't confirmed they use.** GitHub Issues, Linear, Zendesk, pganalyze, and Jira are ask-then-connect, never blind.
 - **Stay off the internal surfaces.** Don't call `signals-scout-emit-signal` or any scratchpad-write tool, and don't change a scout's `emit` flag or `run_interval_minutes` — on configs, this skill only flips `enabled`. **Built-in scout bodies are never edited.** New scout skills are created in exactly one place: step 6b, and only ones the user approved there.
 - **Keep the scout troop small.** Every enabled scout is a recurring LLM spend. Step 6 enables only `signals-scout-general` plus the **one or two** specialists for the products this project uses most — never error tracking or session replay (those reach the inbox as native sources) — and step 6b adds **at most two** custom scouts. Everything else stays disabled.
 - **Batch your questions.** `wizard_ask` has a small per-run budget; one multi-select beats four yes/nos. Don't skip a step or drop a connector (e.g. Linear) or custom scouts setup to save calls.

context/skills/self-driving/references/2-read-context.md

@@ -38,7 +38,7 @@ Load the local tools via `ToolSearch select:Read,Glob,Grep`. Reach the PostHog t
    - **Logs**: is the PostHog logs product in use (per the profile)?
    - **CSP**: is a Content-Security-Policy with PostHog CSP reporting configured?
    - **Support**: does the team use PostHog support/conversations (per the profile)?
-   - **Issue trackers**: any hints of Linear, Zendesk, or pganalyze (you will still ask in step 5 — hints only shape the question, they never authorize enabling).
+   - **Issue trackers**: any hints of Linear, Zendesk, pganalyze, or Jira (you will still ask in step 5 — hints only shape the question, they never authorize enabling).
 
    Do NOT crawl the whole source tree. If a question can't be answered cheaply, record "unknown" and move on — unknowns default to asking the user about sources; for scouts, an unconfirmed surface won't rank among the most-used products, so step 6 won't enable its scout.
 

context/skills/self-driving/references/4-sources.md

@@ -40,6 +40,6 @@ Reach the source-config tools through the PostHog `exec` tool — `info` then `c
 - `llm_analytics` (internal-only, not a user-facing responder)
 - `logs` (not a v1 responder)
 - Anything with `source_type` `evaluation` or `alert_state_change`
-- The connected-tool sources (`github`, `linear`, `zendesk`, `pganalyze`) — those are step 5, ask-first.
+- The connected-tool sources (`github`, `linear`, `zendesk`, `pganalyze`, `jira`) — those are step 5, ask-first.
 
 Record every enable/skip decision with its reason — the report needs them.

context/skills/self-driving/references/5-connected-tools.md

@@ -4,9 +4,9 @@ next_step: 6-scouts.md
 
 # Step 5 — Connected-tool sources (ask, then connect)
 
-External tools can feed the inbox too: GitHub Issues, Linear, Zendesk, and pganalyze. Each needs a **data warehouse source** before its signal source produces anything — a source row without the warehouse connection is dormant: harmless, but silent until the source syncs. Never enable one the user hasn't confirmed.
+External tools can feed the inbox too: GitHub Issues, Linear, Zendesk, pganalyze, and Jira. Each needs a **data warehouse source** before its signal source produces anything — a source row without the warehouse connection is dormant: harmless, but silent until the source syncs. Never enable one the user hasn't confirmed.
 
-Two of these the run can connect **itself**: GitHub Issues, and Linear via a one-click OAuth link (dedicated connector files below). The other two — Zendesk and pganalyze — need API credentials this run never collects, so the run does **not** send the user to the UI and does **not** check whether they connected: it just arms the dormant responder and records a follow-up. The user finishes those later (a downstream reminder prompts them).
+Two of these the run can connect **itself**: GitHub Issues, and Linear via a one-click OAuth link (dedicated connector files below). The other three — Zendesk, pganalyze, and Jira — need API credentials this run never collects, so the run does **not** send the user to the UI and does **not** check whether they connected: it just arms the dormant responder and records a follow-up. The user finishes those later (a downstream reminder prompts them). (Jira's warehouse source authenticates with an Atlassian API token, not the `kind=jira` OAuth integration, so there is no one-click link to hand over — treat it exactly like Zendesk.)
 
 ## Status
 
@@ -34,29 +34,31 @@ Load `wizard_ask` via `ToolSearch select:mcp__wizard-tools__wizard_ask`. Reach `
     { label: "GitHub Issues", value: "github-issues" },
     { label: "Linear", value: "linear" },
     { label: "Zendesk", value: "zendesk" },
-    { label: "pganalyze", value: "pganalyze" }
+    { label: "pganalyze", value: "pganalyze" },
+    { label: "Jira", value: "jira" }
   ]
 }
 ```
 
-2. Call `external-data-sources-list` once (step 2's project profile also lists warehouse sources when it exists). For each picked tool whose source already exists (`source_type` `Github` / `Linear` / `Zendesk` / `PgAnalyze`): record "already connected" — no connector flow needed, just enable its responder row (step 4 below).
+2. Call `external-data-sources-list` once (step 2's project profile also lists warehouse sources when it exists). For each picked tool whose source already exists (`source_type` `Github` / `Linear` / `Zendesk` / `PgAnalyze` / `Jira`): record "already connected" — no connector flow needed, just enable its responder row (step 4 below).
 
 3. Dispatch each picked tool that's still missing:
 
    - **GitHub Issues** → read `references/5a-github.md` and follow it.
    - **Linear** → read `references/5b-linear.md` and follow it.
-   - **Zendesk / pganalyze** → this run can't create their sources (it never collects the API credentials they need), so **don't ask the user to connect them and don't verify**. Just enable the dormant responder (step 4 below) and record "picked but not connected" with a follow-up. A downstream reminder prompts the user to add the warehouse source later; the responder stays dormant (harmless) and starts emitting once that source syncs.
+   - **Zendesk / pganalyze / Jira** → this run can't create their sources (it never collects the API credentials they need — Jira wants an Atlassian subdomain, email, and API token), so **don't ask the user to connect them and don't verify**. Just enable the dormant responder (step 4 below) and record "picked but not connected" with a follow-up. A downstream reminder prompts the user to add the warehouse source later; the responder stays dormant (harmless) and starts emitting once that source syncs.
 
 4. Enable the source row (step 4's write recipe) for every tool the user picked — created, verified, and picked-but-not-connected alike (a dormant row is harmless and saves a later trip):
 
    - GitHub Issues → `github` / `issue`
    - Linear → `linear` / `issue`
    - Zendesk → `zendesk` / `ticket`
    - pganalyze → `pganalyze` / `issue`
+   - Jira → `jira` / `issue`
 
 5. Record each picked tool's final class honestly — the report consumes these verbatim:
 
    - **connected by this setup** — the connector flow created the source (you have its id; the first sync starts automatically)
    - **already connected** / **verified connected** — the source row was seen in `external-data-sources-list`
-   - **picked but not connected** — the user picked the tool but no live warehouse source exists: Zendesk / pganalyze (never connected in-run), Linear when its integration didn't land, or a GitHub Issues fallback the user skipped. **Enable the dormant responder and add a "Connect <tool>…" follow-up** — this is harmless, because a responder only emits once its warehouse source actually syncs, so a dormant row just saves the user a later trip. Record it honestly — never write that the user "confirmed connecting" and never "not used". Phrase it as "you selected <tool>, but no warehouse source was detected — the responder is enabled and stays dormant until you add the source and it starts syncing", plus the follow-up with the new-warehouse-source URL
+   - **picked but not connected** — the user picked the tool but no live warehouse source exists: Zendesk / pganalyze / Jira (never connected in-run), Linear when its integration didn't land, or a GitHub Issues fallback the user skipped. **Enable the dormant responder and add a "Connect <tool>…" follow-up** — this is harmless, because a responder only emits once its warehouse source actually syncs, so a dormant row just saves the user a later trip. Record it honestly — never write that the user "confirmed connecting" and never "not used". Phrase it as "you selected <tool>, but no warehouse source was detected — the responder is enabled and stays dormant until you add the source and it starts syncing", plus the follow-up with the new-warehouse-source URL
    - **not used** — the tool was **not picked** in the connected-tools multi-select. No responder, no follow-up; record "skipped (not used)".