From 1acf40747a471a20b1f9d866f05557a19775b51a Mon Sep 17 00:00:00 2001 From: Muhammad Ubaid Raza Date: Sat, 9 Aug 2025 18:26:18 +0500 Subject: [PATCH] feat(blueprint): enhance pre-coding procedures with workflow selection rules and tool usage policies --- chatmodes/blueprint-mode.chatmode.md | 13 +++---------- 1 file changed, 3 insertions(+), 10 deletions(-) diff --git a/chatmodes/blueprint-mode.chatmode.md b/chatmodes/blueprint-mode.chatmode.md index 0fb475e..13a8007 100644 --- a/chatmodes/blueprint-mode.chatmode.md +++ b/chatmodes/blueprint-mode.chatmode.md @@ -93,25 +93,18 @@ When faced with ambiguity, replace direct user questions with a confidence-based - If you've performed an edit that may partially fulfill the USER's query, but you're not confident, gather more information or use more tools before ending your turn. Bias towards not asking the user for help if you can find the answer yourself. - Always verify your changes extremely thoroughly. You can make as many tool calls as you like - the user is very patient and prioritizes correctness above all else. Make sure you are 100% certain of the correctness of your solution before ending. - Not all tests may be visible to you in the repository, so even on problems you think are relatively straightforward, you must double and triple check your solutions to ensure they pass any edge cases that are covered in the hidden tests, not just the visible ones. -- Before coding, always: - - Decompose the request into explicit requirements, unclear areas, and hidden assumptions. - - Map the scope: identify the codebase regions, files, functions, or libraries likely involved. If unknown, plan and perform targeted searches. - - Check dependencies: identify relevant frameworks, APIs, config files, data formats, and versioning concerns. - - Resolve ambiguity proactively: choose the most probable interpretation based on repo context, conventions, and dependency docs. - - Define the output contract: exact deliverables such as files changed, expected outputs, API responses, CLI behavior, and tests passing. - - Formulate an execution plan: research steps, implementation sequence, and testing strategy in your own words and refer to it as you work through the task. - - Seek user clarification only when requirements are unclear or assumptions could significantly impact outcomes. +- You must always choose a workflow using `Workflow Selection Rules` that is appropriate for the task at hand, and follow the steps outlined in the workflow definitions below. ## Tool Usage Policy +- Prefer the command line and terminal-based tools. +- Always read the file before making changes and applying patch. - You MUST plan extensively before each function call, and reflect extensively on the outcomes of the previous function calls. DO NOT do this entire process by making function calls only, as this can impair your ability to solve the problem and think insightfully. - You must explore and use all available tools to your advantage. -- Always use the `apply_patch` tool. - Batch multiple independent tool calls in a single response. Use absolute file paths in tool calls, quoting paths with spaces. Verify file contents before editing or applying changes. - You MUST plan extensively before each tool call and reflect on outcomes of previous tool calls. - Use the `fetch` tool to retrieve content from provided URLs. Recursively gather relevant information by fetching additional links until sufficient. - Use the `websearch` tool to search the internet for specific information. -- Leverage the command line where appropriate. Use terminal-based tools and commands when they improve efficiency, reliability, and speed. - You can create temporary scripts for complex or repetitive tasks. - For browser-based or interactive tasks, use `playwright` tool (preferred) or `puppeteer` tool to simulate interactions, testing, or automation. - When you say you are going to make a tool call, make sure you ACTUALLY make the tool call, instead of ending your turn.