File a thread under Planning when a message asks for a plan - #4
Merged
Merged
Conversation
The v0.2.0 release bumped its package.json without regenerating the lockfile, so every install rewrote the workspace entry. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Filing is the agent's job: it reads the stage table and runs `bb stages set`. Plan mode is the one moment it cannot, because that is a mutating shell call, so a thread started with /plan sat in Inbox through its whole planning session and was only filed once the plan was approved, by which point the honest stage is Building. No event or thread field says a turn is a plan. The message does: bb's plan action is a provider-declared slash command, carried on the send as a structured command mention. So a message.dispatch hook watches for that mention opening the message and files the thread under planStageId. It always proceeds, decides synchronously and moves off the pass, because the hook is fail-closed and holds a server-wide lock. Command names come from each provider's composer actions on a background refresh, falling back to "plan". Matching the mention rather than the text matters: over 400 recorded prompts it caught all four plan sends with no false positives, where a text match on "/plan" flagged 43 messages that only discussed it. This trigger ships on, unlike the other three. They guess a stage from a thread's runtime; asking for a plan is the user saying what comes next. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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
1 participant
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.
Threads started with
/plansat in Inbox for their whole planning session. Filing is the agent's job, and in plan mode it can't do it:bb stages setis a mutating call, and plan mode doesn't allow those.What changed
server.ts: amessage.dispatchhook files the thread underplanStageIdwhen a send opens with the provider's plan command mention. It always returnsproceed, decides synchronously and does the move after the hook returns, because the hook is fail-closed and holds a server-wide lock. Plan command names come fromproviders.list()on a background refresh, falling back to"plan".stages.ts: newplanStageIdconfig key, default"planning". No migration needed, since an absent key falls through to the default.app.tsx, README, PLUGIN_OVERVIEW, SKILL.md: the new trigger, and why it's the only one that ships on.Verification
npm run checkpasses.source: "skill"drops it to 0/4. A plain text match on/plangives 43 false positives.start === 0guard never changed an outcome in that corpus, so real data doesn't prove it./planfiling a thread has not been tested yet.Not in this PR
🤖 Generated with Claude Code