Add Neo integrations documentation

[kramhuber]

Summary

• Adds new integrations page at /docs/ai/integrations/ documenting the integration catalog feature
• Covers available integrations (Atlassian, Datadog, Honeycomb, Linear, Notion, Sentry, Supabase), admin setup, credential storage, and usage examples
• Adds integration references to the AI landing page, settings page, and tasks page

Docs companion to the integration catalog backend work on pulumi/pulumi-service.

[pulumi-bot]

Your site preview for commit 3803d2a is ready! 🎉

http://www-testing-pulumi-docs-origin-pr-18410-3803d2ae.s3-website.us-west-2.amazonaws.com

[claude]

Docs Review — #18410

Solid new page overall — clear structure, good use of the {{% notes %}} shortcode, correctly follows the 1. ordered-list convention, and the cross-links from the landing page, settings, and tasks page are wired up consistently. A few things worth addressing before merge.

Content accuracy / consistency

1. PR description vs. page contents mismatch (content/docs/ai/integrations/_index.md lines 59–117).
The PR body lists the integrations as Atlassian, Datadog, Honeycomb, Linear, Notion, Sentry, Supabase, but the page ships with Atlassian, Datadog, Honeycomb, Linear, PagerDuty, Supabase. Notion and Sentry are missing; PagerDuty is present but not in the summary. Please confirm which set is actually launching and reconcile — if Notion/Sentry aren't shipping yet, just update the PR description; if they are, add their Configuration sections.

2. Overview categories don't cover all the shipped integrations (line 15).
The opening paragraph says Neo reads from "issue trackers, observability platforms, wikis, and databases" — but PagerDuty (incident response) doesn't fit any of those buckets, even though it gets a bullet on line 24 and a full config section. Consider adding "incident response tools" (or similar) to the list so the overview reflects what's actually in the catalog. Same applies to content/docs/ai/settings/_index.md line 149, which reuses the same three-category phrasing.

Neo integrations bring context from your existing tools into infrastructure tasks. Neo can read directly from the services your team already uses — issue trackers, observability platforms, incident response tools, wikis, and databases — and apply that context to infrastructure work.

(Also removes the repeated phrase "infrastructure tasks" twice in one sentence.)

Style / writing

3. "Credential storage" placement (lines 33–35).
This is currently an H3 under Enabling an integration, but the content (encryption at rest, per-org keys, credential lifetime, not exposing to the model) is general security information that applies regardless of enablement. Consider promoting it to its own H2 — it's the kind of detail security reviewers will want to find quickly, and they're unlikely to look for it under "Enabling an integration."

4. Honeycomb scope wording is ambiguous (line 83).
"Choose the Model Context Protocol and Environments scopes" — reads as if "Model Context Protocol" is a literal scope name in the Honeycomb UI. If it is literally a scope label, great; if it's just describing the purpose, consider rephrasing (e.g., "Select the scopes required for MCP access: MCP and Environments"). Worth verifying against the actual Honeycomb UI.

5. Settings page meta_desc capitalization (content/docs/ai/settings/_index.md line 5).
The list mixes Title Case feature names with a lowercase integrations:

Configure Neo with Custom Instructions, Repository Instructions, Slash Commands, integrations, access controls, and task modes.

If Integrations is the product-UI label (it appears capitalized elsewhere in the file, e.g. line 149 "Integrations tab"), match that casing here for consistency.

6. Datadog site identification (line 76).
"For example, datadoghq.com is us1, datadoghq.eu is eu1" — two examples is fine, but users on other sites may still have to guess. A short pointer to Datadog's "Getting Started with Sites" page (or equivalent) would make this more self-serve.

7. Linear / PagerDuty permissions guidance (lines 96, 106).
For Linear: "configure the permissions and team access for your use case" is vague — if there's a known minimum set of permissions Neo needs, spelling it out will prevent support tickets. Same for PagerDuty — no scoping guidance at all. Compare to the Honeycomb section (line 83–85), which lists exact permissions. Recommend bringing the other integrations up to that bar.

Nits

• Landing page card description (content/docs/ai/_index.md line 57) picks Datadog, Honeycomb, and Linear as examples. Jira is likely more broadly recognizable to platform-engineering readers than Honeycomb — consider swapping. Not blocking.
• "Tasks that are already running will lose access to the integration on their next tool call" (line 41) — "tool call" is accurate but internal-sounding. Consider "on their next action" or "the next time Neo tries to use it" for readers who don't know Neo uses MCP tools under the hood.

---

None of the above are blockers — #1 and #2 are the only ones I'd consider must-fix before merge. Ping @claude if you'd like another pass after revisions.