Channel CONTEXT.md: agent generation + inject into task prompts (local & cloud)#2627
Merged
Conversation
Adds a one-shot background agent to the per-channel CONTEXT.md empty state. The agent explores a selected local repo (read-only) plus PostHog data via the PostHog MCP for things related to the folder name, then publishes CONTEXT.md itself through the MCP (desktop-file-system-instructions-partial-update). - New ContextGenService (host-router), mirroring CanvasGenService: real repoPath, denies file-write/shell/network tools, keeps MCP enabled, streams prose + tool activity. Bound as a singleton with a BindingMap entry. - Core schemas + identifier + service interface; one-line tRPC router registered in both host-router and apps/code aggregators. - UI: folder picker (existing registered repos), context-gen store + stream subscription, GeneratingPanel reusing MarkdownRenderer, done -> refetch + render. v1 is local-repo only; cloud/GitHub-sandbox mode is a follow-up. Generated-By: PostHog Code Task-Id: 8b4fb28f-6761-49c4-9b2f-dc62f2305ca2
When a task is created from a channel, that channel's CONTEXT.md is appended to the agent's initial prompt as optional background — framed as reference material, not instructions, so the agent can use it as a starting point without being limited to it. Threads an optional channelContext string from WebsiteNewTask (fetched via useFolderInstructions) through TaskInput -> useTaskCreation -> prepareTaskInput -> TaskCreationInput, and appends it as a labeled <channel_context> block to the initial prompt in TaskCreationSaga. Empty/missing instructions inject nothing. Generated-By: PostHog Code Task-Id: 8b4fb28f-6761-49c4-9b2f-dc62f2305ca2
Three related changes to how a channel's CONTEXT.md flows through tasks: - New-task input: when a channel has a CONTEXT.md, show a dismissable "Using: #channel CONTEXT.md" chip; dismissing drops it from the prompt. - Conversation: the injected <channel_context> block renders as a clickable "#channel CONTEXT.md" tag instead of inline text; clicking opens the exact snapshot that was sent as a real file tab in the split (not a fetched/live copy), via a new "context" panel tab type. - Generation: replace the bespoke streaming generator with a normal task in the channel's repo that publishes CONTEXT.md via the PostHog MCP. The view tracks that task — a centered "Generating" state with a View task button while its session runs, and a re-generate path if it stops before producing a file. Removes ContextGenService, its router/schemas/store/subscriptions, and the CONTEXT_GEN_SERVICE DI wiring. Generated-By: PostHog Code Task-Id: 8b4fb28f-6761-49c4-9b2f-dc62f2305ca2
…n tracking
- Channel-context injection now reaches cloud tasks: split buildChannelContextText
out of buildChannelContextBlock and fold it into the cloud task's
pendingUserMessage (local still appends a block to initialPrompt). The shared
conversation tag parser renders both identically; task titles stay clean.
- CONTEXT.md generation works for cloud: the generate picker has a Local/Cloud
toggle reusing FolderPicker / GitHubRepoPicker + useUserRepositoryIntegration;
useGenerateContext builds a local or cloud TaskCreationInput. The "generating"
status is now environment-aware (cloud uses cloudStatus/latest_run.status,
local uses the live session).
- Generation tracking moved off fragile local electronStorage to a server-side,
project-shared association keyed on the folder (works before any instructions
exist): new api-client get/setDesktopFolderGenerationTask + useFolderGenerationTask
hook. Deleted contextGenTaskStore.
Requires a PostHog cloud backend change (separate repo) to add the
GET/PUT .../desktop_file_system/{id}/context_generation/ endpoints; until then the
client no-ops gracefully (generation runs and the file renders on publish, only
the shared in-progress indicator is dormant).
Generated-By: PostHog Code
Task-Id: 8b4fb28f-6761-49c4-9b2f-dc62f2305ca2
|
React Doctor could not complete this scan.
Reviewed by React Doctor for commit |
Contributor
Prompt To Fix All With AIFix the following 2 code review issues. Work through them one at a time, proposing concise fixes.
---
### Issue 1 of 2
packages/core/src/editor/prompt-builder.test.ts:7-11
The null/empty cases for both `buildChannelContextText` and `buildChannelContextBlock` are tested with multiple assertions inside a single `it` block. The team rule is to always prefer parameterised tests (`it.each`), which would also give a clear label per failing input if one regresses.
```suggestion
describe("buildChannelContextText", () => {
it.each([
[undefined],
[" \n "],
] as const)("returns null for empty or whitespace content (%s)", (input) => {
expect(buildChannelContextText(input)).toBeNull();
});
```
### Issue 2 of 2
packages/core/src/editor/prompt-builder.test.ts:29-35
Same pattern — four inputs collapsed into one `it` block. Each would be a separate row in an `it.each` table, making it immediately obvious which specific input fails.
```suggestion
describe("buildChannelContextBlock", () => {
it.each([
[undefined],
[null],
[""],
[" \n "],
] as const)("returns null for empty or whitespace content (%s)", (input) => {
expect(buildChannelContextBlock(input)).toBeNull();
});
```
Reviews (1): Last reviewed commit: "feat(canvas): cloud support for channel ..." | Re-trigger Greptile |
Generated-By: PostHog Code Task-Id: d89a5150-3b8e-47f3-8241-4b92fac42e0c
Convert the multi-assertion null/whitespace cases for buildChannelContextText and buildChannelContextBlock to it.each rows per team test convention, addressing PR review feedback. Generated-By: PostHog Code Task-Id: c88e812d-c756-4cc4-b503-069237cc8fe3
Contributor
|
Reviews (2): Last reviewed commit: "test(editor): parameterise channel-conte..." | Re-trigger Greptile |
The clickable #channel CONTEXT.md tag + split file tab in the conversation is the one CONTEXT.md surface that renders outside the canvas /website space (which is already redirect-gated on project-bluebird). Gate the tag/tab behind the flag too. The block is still stripped from the prompt when the flag is off so the raw <channel_context> XML never leaks to flag-off viewers. Generated-By: PostHog Code Task-Id: c88e812d-c756-4cc4-b503-069237cc8fe3
adamleithp
approved these changes
Jun 15, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Builds out the per-channel
CONTEXT.md(folder instructions) feature across three areas, for both local and cloud runs:1. Generate CONTEXT.md with an agent
FolderPicker/GitHubRepoPicker+useUserRepositoryIntegration).desktop-file-system-instructions-partial-update).cloudStatus/latest_run.status, local live session).2. Channel CONTEXT.md injected into task prompts
Using: #channel CONTEXT.mdchip (dismiss drops it from the prompt).3. Conversation rendering
<channel_context>block renders as a clickable#channel CONTEXT.mdtag instead of inline text; clicking opens the exact snapshot that was sent as a real file tab in the split (a newcontextpanel-tab type), not a live re-fetch.Shared, server-side generation tracking
electronStorage. New api-clientget/setDesktopFolderGenerationTask+useFolderGenerationTaskhook.The shared generation indicator depends on new endpoints that must be added in the PostHog cloud repo:
plus auto-clear of the association when a new folder-instructions version is published.
Until that lands, the client no-ops gracefully: generation still runs and the file still renders on publish — only the project-shared in-progress indicator is dormant. (Everything else in this PR works without backend changes.)
Testing
pnpm typecheck(22/22),pnpm lint,node scripts/check-host-boundaries.mjs— all green.prompt-builder.test.ts(channel-context block/text),channelContext.test.ts(conversation tag parser).Created with PostHog Code