ref: Migrate next-steps to manifest-driven templates#216
Merged
cameroncooke merged 10 commits intomainfrom Feb 17, 2026
Merged
Conversation
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
commit: |
Move next-step definitions from inline tool logic into YAML manifests
using a new nextStepTemplates system. Templates support static params,
${arg} substitution, and runtime merging with dynamic response params.
Removes hardcoded next-step construction from individual tool handlers.
Move list_schemes back to manifest-driven next steps while preserving\nmainline guidance improvements for run intent and compile-only flows.\n\nUpdate the manifest ordering/labels, return dynamic nextStepParams from\nthe tool, align tests, and regenerate tool docs so rendered guidance\nmatches runtime behavior. Co-Authored-By: Claude <noreply@anthropic.com>
cameroncooke
force-pushed
the
refactor/manifest-driven-next-steps
branch
from
7c062ae to
a4c15cc
Compare
Apply dynamic next-step params even when manifest templates already define\nparams so scaffold follow-up actions resolve placeholders correctly.\n\nAlign testing docs and pattern checks with the canonical policy:\nuse executor/filesystem DI for external boundaries and allow Vitest\nmocking for internal collaborators. Co-Authored-By: Claude <noreply@anthropic.com>
Route simulator destination string creation through constructDestinationString in\nget_sim_app_path and build_run_sim to keep formatting and behavior\nconsistent across tools and reduce drift risk. Co-Authored-By: Claude <noreply@anthropic.com>
Run MCP tool responses through the same template/nextStepParams post-processing used by CLI so migrated tools continue emitting next-step suggestions for LLM clients. Also remove the dead arch parameter from get_sim_app_path now that the schema is simulator-only. Co-Authored-By: Claude <noreply@anthropic.com>
Stop resolving manifest next-step params from raw invocation args and rely on tool-provided nextStepParams for canonical runtime values. Replace YAML arg placeholders with static defaults and update snapshot_ui to return dynamic params for all templated follow-up actions. Co-Authored-By: Claude <noreply@anthropic.com>
Always render manifest-defined next steps when templates exist. Remove\ntool-level nextSteps fallback behavior and keep dynamic injection\nlimited to nextStepParams overlays on manifest params. Refs #216 Co-Authored-By: Claude <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 2 potential issues.
Bugbot Autofix is OFF. To automatically fix reported issues with Cloud Agents, enable Autofix in the Cursor dashboard.
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.
Move next-step definitions out of individual tool handlers and into YAML
manifests, introducing a declarative
nextStepsarray on each toolmanifest entry.
Previously every tool handler constructed its own
nextStepsarrayinline, duplicating structure and coupling presentation logic to tool
business logic. This made it hard to audit which tools suggest which
follow-up actions and required code changes to adjust next-step wording
or ordering.
The new system works in three layers:
Manifest templates (
manifests/tools/*.yaml) declare staticnext-step entries with a
label, optionaltoolId, optionalparams(supporting${arg}substitution from the invocationargs), and optional
priority.Template builder (
buildTemplateNextSteps) resolves templatesat invocation time, looking up target tools in the catalog and
substituting params.
Merge layer (
mergeTemplateAndResponseNextSteps) combinestemplate-driven steps with any dynamic
nextStepParamsthe toolhandler returns at runtime, so tools can still provide
context-dependent param values without owning the full next-step
structure.
Tool handlers now return only
nextStepParams(a map of toolId toparam values) when they need dynamic data, rather than constructing
entire
NextStepobjects. Most tools no longer touch next-steps at all.Includes a
NEXT_STEPS_MIGRATION_TODO.mdtracking remaining tools tomigrate and shared test helpers in
src/test-utils/next-step-assertions.ts.