RFC: feature: enable custom prompts/review-stages#188
Conversation
Add configuration structs for tool filtering and custom prompts. Add ToolsSettings, PromptsSettings, and CustomToolDefinition types. Add Settings::get_prompts_dir() helper for resolving the prompts directory path. Add [tools] and [prompts] sections to Settings.toml. Signed-off-by: derekbarbosa <derekasobrab@gmail.com>
…tion Add ToolBox::with_config constructor accepting ToolsSettings for tool filtering. Add is_tool_enabled allowlist/denylist check. Add register_custom_tools and execute_custom_tool with path validation and dangerous pattern blocking. Filter tool declarations and calls through is_tool_enabled gate. Signed-off-by: derekbarbosa <derekasobrab@gmail.com>
Add StagesConfig and StageDefinition for TOML-based stage
definitions. Add PromptRegistry::with_settings async factory
for remote prompt resolution (HTTP, git clone, local dir).
Add substitute_variables for {{variable}} template expansion.
Refactor get_stage_prompt to use fallback chain: stages.toml
config -> file-based stages -> hardcoded stages. Add stage
filtering respecting enabled flag from config. Add md5
dependency for prompt cache hashing.
Signed-off-by: derekbarbosa <derekasobrab@gmail.com>
Change Reviewer::new to async fn new() -> Result<Self>, replacing .expect() with ? for error propagation on BaselineRegistry and create_provider_cached. Update main.rs call site to match on Result. Add --prompts arg to run_review_tool using settings.get_prompts_dir(). Update src/bin/review.rs to use ToolBox::with_config, PromptRegistry::with_settings, and Option<PathBuf> for --prompts arg. Signed-off-by: derekbarbosa <derekasobrab@gmail.com>
Add custom prompts documentation, tools configuration guide, and settings reference. Add design document for custom prompts and tools RFC. Update README with tools and prompts configuration sections. Signed-off-by: derekbarbosa <derekasobrab@gmail.com>
|
V1-> V2:
|
derekbarbosa
force-pushed
the
feature/custom-prompt-config
branch
from
077f17a to
98c7243
Compare
|
I like your change, as I think it is much nicer to have each stage defined in a separate .md file, rather than hardcoded in the source. Question: If we compare with the /kseries skill in review-prompts: Would it be possible to create a similar skill for Sashiko, than could be imported directly in the agent and executed, to perform all the review stages in order, or would this not be possible because of the way Sashiko transitions between stages? Since is seems that skills are more or less compatible between agents, having a /sashiko-kseries skill would basically make a serverless standalone binary as proposed in: #134 unnecessary. |
|
Hi @floatious, sorry for the delay in reply. Sure, I can push up an experimental branch.
Maybe. I would imagine that in a long-running session, you'd get issues with some models (Claude, Gemini) compacting the "conversation context" -- potentially missing out findings. However, I don't see why that can't be circumvented by writing findings out to a file or something between stages, propagating them forward in a similar fashion. I'll hack something together up towards the end of the weekend/early-next-week, and push up a branch. Does that sounds good? In the meantime, would you mind filing an issue with a small description, just to keep it separate from the RFC? :) |
2 participants
Sashiko's review pipeline currently has a fixed structure: hardcoded stage
instructions, a static set of AI tools, and no mechanism for users to inject
domain-specific review guidance.
Those adopting sashiko for their own
kernel trees or non-kernel projects must either:
Neither option scales. Someone reviewing storage drivers needs different
guidance someone reviewing networking code, but today both run the
identical 9-stage pipeline with identical prompts.
This patch introduces a configuration-driven customization layer that sits
between the user and the review pipeline. All changes are opt-in; the default
behavior is completely unchanged when no configuration is provided.
The following features are enabled by this PR:
Custom Prompts Directory
Users can point sashiko at their own prompt files via Settings.toml or the
--prompts CLI flag. The directory can be a local path, a Git repository URL
(cloned and cached locally), or an HTTP(S) URL. The default
third_party/prompts/kernel directory continues to work unchanged.
Stage Configuration
A new stages.toml file controls the review pipeline:
This allows teams to skip irrelevant stages (e.g., disable the hardware review
stage for a pure-software project) or add domain-specific stages (e.g., a
compliance analysis stage).
Template Variables
Prompt files can contain {{variable}} placeholders that are substituted at
load time from configuration. Built-in variables include {{date}} and
{{year}}. Users define custom variables in [prompts.variables] to inject
organization names, target architectures, or other project-specific context
into prompts without modifying the prompt files themselves.
Tool Filtering
Users can allowlist or denylist which built-in AI tools are available during
review. This is useful for restricting the AI to read-only operations, or
limiting tool access in constrained environments.
Custom Tool Definitions
Users can register shell-based tools that the AI can invoke during review.
Custom tools are defined in Settings.toml with a JSON schema for parameters,
a shell command template, and an optional path allowlist for security. This
enables integration with project-specific linters, static analyzers, or other
external tools without modifying sashiko's source.
This PR: