chore(inbox): Slim down inbox Create PR prompt and auto-launch#2370
Conversation
The Create PR button on an inbox report was inlining the entire researched summary into a single prompt and dumping the user back into TaskInput so they had to read, edit and submit it themselves. The wall of text made the task feel intimidating and slowed people down enough that they often dropped off before actually kicking it off. Mirror the Discuss flow: build a short, intent-only prompt that tells the agent to fetch the report through the inbox MCP tools, then create the task directly in auto mode and jump to it - same UX shape as Discuss, just for implementation instead of conversation. - new `buildCreatePrReportPrompt` util + tests for the short prompt shape - new `useCreatePrReport` hook that mirrors `useDiscussReport`, hardcoding `executionMode: "auto"` and `cloudRunSource: "signal_report"` - `ReportDetailPane` swaps `navigateToTaskInput` for the hook, shows a spinner while the task is being created, and disables the button while in-flight Generated-By: PostHog Code Task-Id: 4884e8d3-538d-4b19-9dc9-3b76a07df269
Prompt To Fix All With AIFix the following 3 code review issues. Work through them one at a time, proposing concise fixes.
---
### Issue 1 of 3
apps/code/src/renderer/features/inbox/utils/buildCreatePrReportPrompt.test.ts:5-19
The first two tests exercise the same function with different `isDevBuild` values — a textbook candidate for a parameterised test. The project style guide prefers `it.each` / `describe.each` for cases like this to avoid repeating the setup.
```suggestion
it.each([
{ isDevBuild: false, expectedScheme: "posthog-code" },
{ isDevBuild: true, expectedScheme: "posthog-code-dev" },
])(
"uses $expectedScheme:// in builds where isDevBuild=$isDevBuild",
({ isDevBuild, expectedScheme }) => {
const prompt = buildCreatePrReportPrompt({ reportId: "abc123", isDevBuild });
expect(prompt).toContain(`${expectedScheme}://inbox/abc123`);
},
);
```
### Issue 2 of 3
apps/code/src/renderer/features/inbox/hooks/useCreatePrReport.ts:36-60
`resolveDefaultModel` is identical to the version in `useDiscussReport.ts` (only the log string differs). Extracting it to a shared utility (e.g., `utils/resolveDefaultModel.ts`) would keep it OnceAndOnlyOnce and mean future changes to the query logic only need to happen in one place.
### Issue 3 of 3
apps/code/src/renderer/features/inbox/hooks/useCreatePrReport.ts:151-160
The analytics event records `created_from: "command-menu"` even though this task is created from the inbox detail pane — the same inherited value that exists in `useDiscussReport`. Since the new hook deliberately introduces a distinct code path for inbox Create PR, this is a good opportunity to use a more accurate source label so the two flows can be distinguished in analytics.
```suggestion
track(ANALYTICS_EVENTS.TASK_CREATED, {
auto_run: true,
created_from: "inbox_report",
repository_provider: "github",
workspace_mode: "cloud",
has_branch: false,
cloud_run_source: "signal_report",
cloud_pr_authorship_mode: "user",
adapter,
});
```
Reviews (1): Last reviewed commit: "Slim down the inbox "Create PR" prompt a..." | Re-trigger Greptile |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
Address Greptile review on #2370. - Pull `resolveDefaultModel` into a shared util so the inbox Discuss and Create PR hooks aren't carrying identical copies of the preview-config lookup. Both hooks now import from `utils/resolveDefaultModel`. - Collapse the two prod/dev deeplink scheme tests for `buildCreatePrReportPrompt` into a single `it.each` block. Skipping the analytics `created_from: "command-menu"` → `"inbox_report"` suggestion: that label is a typed enum (`TaskCreatedFrom = "cli" | "command-menu"`), so adding a new value would touch the analytics schema and diverge from the Discuss flow this hook intentionally mirrors. Out of scope for the prompt-slim PR. Generated-By: PostHog Code Task-Id: 4884e8d3-538d-4b19-9dc9-3b76a07df269
andrewm4894
changed the title
The slim Create PR / Discuss prompts no longer inline the report summary, so the agent depends on the inbox MCP returning the report. Add a guard clause so it stops and reports instead of proceeding on a hallucinated understanding when the fetch fails.
…eate-pr-clean-prompt
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: fed962bda7
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| const githubUserIntegrationId = | ||
| getUserIntegrationIdForRepo(cloudRepository); | ||
| if (!githubUserIntegrationId) { | ||
| toast.error("Connect a GitHub integration to create a PR"); | ||
| return; |
There was a problem hiding this comment.
This new Create PR path treats getUserIntegrationIdForRepo(...) returning undefined as “no GitHub integration,” but that mapping is populated asynchronously by useUserRepositoryIntegration (it is built from async repository queries). If the user clicks Create PR before those queries finish, we now show a false "Connect a GitHub integration" error and abort task creation, even when the integration exists. Please gate this check on the integration-loading state (or trigger a refresh/retry) before surfacing the missing-integration toast.
Useful? React with 👍 / 👎.
| const cloudRegion = useAuthStateValue((state) => state.cloudRegion); | ||
|
|
||
| const createPrReport = useCallback(async () => { | ||
| if (isCreatingPr) return; |
There was a problem hiding this comment.
The isCreatingPr guard is state-based and is checked before setIsCreatingPr(true) runs, so two very fast triggers (e.g., double-click or key-repeat on Cmd/Ctrl+Enter) in the same render frame can both pass this check and start parallel createTask calls. That can create duplicate PR tasks for a single report. Use a synchronous in-flight ref/mutex (or set-and-check atomically) so re-entrant calls are blocked immediately.
Useful? React with 👍 / 👎.
| workspaceMode: "cloud", | ||
| executionMode: "auto", | ||
| adapter, | ||
| model, |
There was a problem hiding this comment.
This flow now always creates tasks with executionMode: "auto" while ReportDetailPane still exposes Create PR for pending_input / requires_human_input reports. In that state the user is expected to supply missing context, but bypassing TaskInput removes the pre-run input step and immediately launches an implementation run with incomplete requirements, which can lead to avoidable failed or low-quality PR tasks. Gate auto-run to immediately-actionable reports or keep a manual-input path for pending-input reports.
Useful? React with 👍 / 👎.
2 participants
Summary
The Create PR button on an inbox report was inlining the entire researched summary into a single prompt and dumping the user back into
TaskInputso they had to read, edit and submit it themselves. The wall of text made the task feel intimidating and meant people often abandoned it before kicking it off — even though the report was already actionable.This change makes Create PR behave like Discuss: a short, intent-only prompt that points the agent at the inbox MCP tools, with the task created and launched in auto mode in one click.
buildCreatePrReportPromptutil (+ tests) — short prompt that references the report by ID, links the deeplink, and tells the agent to use the inbox MCP tools to fetch summary/signals/reviewers itself.useCreatePrReporthook mirroringuseDiscussReport. HardcodesexecutionMode: "auto",cloudRunSource: "signal_report", navigates straight to the task on success.ReportDetailPaneswaps thenavigateToTaskInputwall-of-text path for the hook. The Create PR button now shows a spinner and disables while the task is being created (same UX as Discuss).Before
After
Then the task is created immediately in auto mode and the user is dropped on the task detail page — no extra click required.
Test plan