@probelabs/probe 0.6.0-rc277 → 0.6.0-rc278

package/build/agent/ProbeAgent.js

@@ -104,7 +104,6 @@ import {
   TaskManager,
   createTaskTool,
   taskSystemPrompt,
-  taskGuidancePrompt,
   createTaskCompletionBlockedMessage
 } from './tasks/index.js';
 import { z } from 'zod';
@@ -3153,14 +3152,6 @@ Follow these instructions carefully:
       // Create user message with optional image support
       let userMessage = { role: 'user', content: message.trim() };
 
-      // START CHECKPOINT: Inject task guidance if tasks are enabled
-      if (this.enableTasks) {
-        userMessage.content = userMessage.content + '\n\n' + taskGuidancePrompt;
-        if (this.debug) {
-          console.log('[DEBUG] Task guidance injected into user message');
-        }
-      }
-
       // If schema is provided, prepend JSON format requirement to user message
       if (options.schema && !options._schemaFormatted) {
         const schemaInstructions = generateSchemaInstructions(options.schema, { debug: this.debug });

package/build/agent/index.js

@@ -31932,7 +31932,7 @@ ${taskManager.formatTasksForPrompt()}`;
     }
   };
 }
-var taskItemSchema, taskSchema, taskSystemPrompt, taskGuidancePrompt;
+var taskItemSchema, taskSchema, taskSystemPrompt;
 var init_taskTool = __esm({
   "src/agent/tasks/taskTool.js"() {
     "use strict";
@@ -31993,11 +31993,6 @@ Tasks = logical units of work, not files or steps.
 - Circular dependencies are rejected
 - attempt_completion is blocked while tasks remain unresolved
 `;
-    taskGuidancePrompt = `Does this request have MULTIPLE DISTINCT GOALS?
-- "Do A AND B AND C" (multiple goals) \u2192 Create tasks for each goal
-- "Investigate/explain/find X" (single goal) \u2192 Skip tasks, just answer directly
-Multiple internal steps for ONE goal = NO tasks needed.
-If creating tasks, use the task tool with action="create" first.`;
   }
 });
 
@@ -70753,8 +70748,20 @@ If the solution is clear, you can jump to implementation right away. If not, ask
 - Check imports and existing utilities before creating new helpers \u2014 the project may already have what you need.
 
 # Task Planning
-- If the task tool is available, use it to break complex work into milestones before starting implementation.
-- Stay flexible \u2014 if your understanding changes mid-task, add, remove, or reorganize tasks as needed. The plan should serve you, not constrain you.
+When the request has **multiple distinct goals** (e.g. "Fix bug A AND add feature B"), use the task tool to track them:
+- Call the task tool with action="create" and a tasks array. Each task must have an "id" field.
+- Update task status to "in_progress" when starting and "completed" when done.
+- All tasks must be completed or cancelled before calling attempt_completion.
+- Stay flexible \u2014 add, remove, or reorganize tasks as your understanding changes.
+
+Do NOT create tasks for single-goal requests, even complex ones. Multiple internal steps for one goal (search, read, analyze, implement) do not need tasks.
+
+# Discovering Project Commands
+Before building or testing, determine the project's toolchain:
+- Check for Makefile, package.json (scripts), Cargo.toml, go.mod, pyproject.toml, or similar
+- Look for CI config (.github/workflows/, .gitlab-ci.yml) to see what commands CI runs
+- Read README for build/test instructions if the above are unclear
+- Common patterns: \`make build\`/\`make test\`, \`npm run build\`/\`npm test\`, \`cargo build\`/\`cargo test\`, \`go build ./...\`/\`go test ./...\`, \`python -m pytest\`
 
 # During Implementation
 - Always create a new branch before making changes to the codebase.
@@ -70765,12 +70772,22 @@ If the solution is clear, you can jump to implementation right away. If not, ask
 - When editing files, keep edits focused and minimal. For changes spanning more than a few lines, prefer line-targeted editing (start_line/end_line) over text replacement (old_string) \u2014 it constrains scope and prevents accidental removal of adjacent content. Never include unrelated sections in an edit operation.
 - After every significant change, verify the project still builds and passes linting. Do not wait until the end to discover breakage.
 
-# After Implementation
-- Verify the project builds successfully. If it doesn't, fix the build before moving on.
-- Run lint and typecheck commands if known for the project. Fix any new warnings or errors you introduced.
-- Add tests for any new or changed functionality. Tests must cover the main path and important edge cases.
-- Run the project's full test suite. If any tests fail (including pre-existing ones you may have broken), fix them before finishing.
-- When the task is done, respond to the user with a concise summary of what was implemented, what files were changed, and any relevant details. Include links (e.g. pull request URL) so the user has everything they need.
+# Writing Tests
+Every change must include tests. Before writing them:
+- Find existing test files for the module you changed \u2014 look in \`tests/\`, \`__tests__/\`, \`*_test.go\`, \`*.test.js\`, \`*.spec.ts\`, or co-located test modules (\`#[cfg(test)]\` in Rust).
+- Read those tests to understand the project's testing patterns: framework, assertion style, mocking approach, file naming, test organization.
+- Prefer extending an existing test file over creating a new one when your change is in the same module.
+- Write tests that cover the main path and important edge cases. Include a failing-input test when relevant.
+- When fixing a bug, write a failing test first that reproduces the bug, then fix the code to make it pass.
+
+# Verify Changes
+Before committing or creating a PR, run through this checklist:
+1. **Build** \u2014 run the project-appropriate build command (go build, npm run build, cargo build, make, etc.). Fix any compilation errors.
+2. **Lint & typecheck** \u2014 run linter/formatter if the project has one (eslint, clippy, golangci-lint, etc.). Fix any new warnings.
+3. **Test** \u2014 run the full test suite (go test ./..., npm test, cargo test, make test, pytest, etc.). Fix any failures, including pre-existing tests you may have broken.
+4. **Review** \u2014 re-read your diff. Ensure no debug code, no unrelated changes, no secrets, no missing files.
+
+Do NOT skip verification. Do NOT proceed to PR creation with a broken build or failing tests.
 
 # GitHub Integration
 - Use the \`gh\` CLI for all GitHub operations: issues, pull requests, checks, releases.
@@ -84229,12 +84246,6 @@ You are working with a workspace. Available paths: ${workspaceDesc}
           });
           const systemMessage = await this.getSystemMessage();
           let userMessage = { role: "user", content: message.trim() };
-          if (this.enableTasks) {
-            userMessage.content = userMessage.content + "\n\n" + taskGuidancePrompt;
-            if (this.debug) {
-              console.log("[DEBUG] Task guidance injected into user message");
-            }
-          }
           if (options.schema && !options._schemaFormatted) {
             const schemaInstructions = generateSchemaInstructions(options.schema, { debug: this.debug });
             userMessage.content = message.trim() + schemaInstructions;

package/build/agent/shared/prompts.js

@@ -81,8 +81,20 @@ If the solution is clear, you can jump to implementation right away. If not, ask
 - Check imports and existing utilities before creating new helpers — the project may already have what you need.
 
 # Task Planning
-- If the task tool is available, use it to break complex work into milestones before starting implementation.
-- Stay flexible — if your understanding changes mid-task, add, remove, or reorganize tasks as needed. The plan should serve you, not constrain you.
+When the request has **multiple distinct goals** (e.g. "Fix bug A AND add feature B"), use the task tool to track them:
+- Call the task tool with action="create" and a tasks array. Each task must have an "id" field.
+- Update task status to "in_progress" when starting and "completed" when done.
+- All tasks must be completed or cancelled before calling attempt_completion.
+- Stay flexible — add, remove, or reorganize tasks as your understanding changes.
+
+Do NOT create tasks for single-goal requests, even complex ones. Multiple internal steps for one goal (search, read, analyze, implement) do not need tasks.
+
+# Discovering Project Commands
+Before building or testing, determine the project's toolchain:
+- Check for Makefile, package.json (scripts), Cargo.toml, go.mod, pyproject.toml, or similar
+- Look for CI config (.github/workflows/, .gitlab-ci.yml) to see what commands CI runs
+- Read README for build/test instructions if the above are unclear
+- Common patterns: \`make build\`/\`make test\`, \`npm run build\`/\`npm test\`, \`cargo build\`/\`cargo test\`, \`go build ./...\`/\`go test ./...\`, \`python -m pytest\`
 
 # During Implementation
 - Always create a new branch before making changes to the codebase.
@@ -93,12 +105,22 @@ If the solution is clear, you can jump to implementation right away. If not, ask
 - When editing files, keep edits focused and minimal. For changes spanning more than a few lines, prefer line-targeted editing (start_line/end_line) over text replacement (old_string) — it constrains scope and prevents accidental removal of adjacent content. Never include unrelated sections in an edit operation.
 - After every significant change, verify the project still builds and passes linting. Do not wait until the end to discover breakage.
 
-# After Implementation
-- Verify the project builds successfully. If it doesn't, fix the build before moving on.
-- Run lint and typecheck commands if known for the project. Fix any new warnings or errors you introduced.
-- Add tests for any new or changed functionality. Tests must cover the main path and important edge cases.
-- Run the project's full test suite. If any tests fail (including pre-existing ones you may have broken), fix them before finishing.
-- When the task is done, respond to the user with a concise summary of what was implemented, what files were changed, and any relevant details. Include links (e.g. pull request URL) so the user has everything they need.
+# Writing Tests
+Every change must include tests. Before writing them:
+- Find existing test files for the module you changed — look in \`tests/\`, \`__tests__/\`, \`*_test.go\`, \`*.test.js\`, \`*.spec.ts\`, or co-located test modules (\`#[cfg(test)]\` in Rust).
+- Read those tests to understand the project's testing patterns: framework, assertion style, mocking approach, file naming, test organization.
+- Prefer extending an existing test file over creating a new one when your change is in the same module.
+- Write tests that cover the main path and important edge cases. Include a failing-input test when relevant.
+- When fixing a bug, write a failing test first that reproduces the bug, then fix the code to make it pass.
+
+# Verify Changes
+Before committing or creating a PR, run through this checklist:
+1. **Build** — run the project-appropriate build command (go build, npm run build, cargo build, make, etc.). Fix any compilation errors.
+2. **Lint & typecheck** — run linter/formatter if the project has one (eslint, clippy, golangci-lint, etc.). Fix any new warnings.
+3. **Test** — run the full test suite (go test ./..., npm test, cargo test, make test, pytest, etc.). Fix any failures, including pre-existing tests you may have broken.
+4. **Review** — re-read your diff. Ensure no debug code, no unrelated changes, no secrets, no missing files.
+
+Do NOT skip verification. Do NOT proceed to PR creation with a broken build or failing tests.
 
 # GitHub Integration
 - Use the \`gh\` CLI for all GitHub operations: issues, pull requests, checks, releases.

package/cjs/agent/ProbeAgent.cjs

@@ -58878,7 +58878,7 @@ ${taskManager.formatTasksForPrompt()}`;
     }
   };
 }
-var taskItemSchema, taskSchema, taskSystemPrompt, taskGuidancePrompt;
+var taskItemSchema, taskSchema, taskSystemPrompt;
 var init_taskTool = __esm({
   "src/agent/tasks/taskTool.js"() {
     "use strict";
@@ -58939,11 +58939,6 @@ Tasks = logical units of work, not files or steps.
 - Circular dependencies are rejected
 - attempt_completion is blocked while tasks remain unresolved
 `;
-    taskGuidancePrompt = `Does this request have MULTIPLE DISTINCT GOALS?
-- "Do A AND B AND C" (multiple goals) \u2192 Create tasks for each goal
-- "Investigate/explain/find X" (single goal) \u2192 Skip tasks, just answer directly
-Multiple internal steps for ONE goal = NO tasks needed.
-If creating tasks, use the task tool with action="create" first.`;
   }
 });
 
@@ -97700,8 +97695,20 @@ If the solution is clear, you can jump to implementation right away. If not, ask
 - Check imports and existing utilities before creating new helpers \u2014 the project may already have what you need.
 
 # Task Planning
-- If the task tool is available, use it to break complex work into milestones before starting implementation.
-- Stay flexible \u2014 if your understanding changes mid-task, add, remove, or reorganize tasks as needed. The plan should serve you, not constrain you.
+When the request has **multiple distinct goals** (e.g. "Fix bug A AND add feature B"), use the task tool to track them:
+- Call the task tool with action="create" and a tasks array. Each task must have an "id" field.
+- Update task status to "in_progress" when starting and "completed" when done.
+- All tasks must be completed or cancelled before calling attempt_completion.
+- Stay flexible \u2014 add, remove, or reorganize tasks as your understanding changes.
+
+Do NOT create tasks for single-goal requests, even complex ones. Multiple internal steps for one goal (search, read, analyze, implement) do not need tasks.
+
+# Discovering Project Commands
+Before building or testing, determine the project's toolchain:
+- Check for Makefile, package.json (scripts), Cargo.toml, go.mod, pyproject.toml, or similar
+- Look for CI config (.github/workflows/, .gitlab-ci.yml) to see what commands CI runs
+- Read README for build/test instructions if the above are unclear
+- Common patterns: \`make build\`/\`make test\`, \`npm run build\`/\`npm test\`, \`cargo build\`/\`cargo test\`, \`go build ./...\`/\`go test ./...\`, \`python -m pytest\`
 
 # During Implementation
 - Always create a new branch before making changes to the codebase.
@@ -97712,12 +97719,22 @@ If the solution is clear, you can jump to implementation right away. If not, ask
 - When editing files, keep edits focused and minimal. For changes spanning more than a few lines, prefer line-targeted editing (start_line/end_line) over text replacement (old_string) \u2014 it constrains scope and prevents accidental removal of adjacent content. Never include unrelated sections in an edit operation.
 - After every significant change, verify the project still builds and passes linting. Do not wait until the end to discover breakage.
 
-# After Implementation
-- Verify the project builds successfully. If it doesn't, fix the build before moving on.
-- Run lint and typecheck commands if known for the project. Fix any new warnings or errors you introduced.
-- Add tests for any new or changed functionality. Tests must cover the main path and important edge cases.
-- Run the project's full test suite. If any tests fail (including pre-existing ones you may have broken), fix them before finishing.
-- When the task is done, respond to the user with a concise summary of what was implemented, what files were changed, and any relevant details. Include links (e.g. pull request URL) so the user has everything they need.
+# Writing Tests
+Every change must include tests. Before writing them:
+- Find existing test files for the module you changed \u2014 look in \`tests/\`, \`__tests__/\`, \`*_test.go\`, \`*.test.js\`, \`*.spec.ts\`, or co-located test modules (\`#[cfg(test)]\` in Rust).
+- Read those tests to understand the project's testing patterns: framework, assertion style, mocking approach, file naming, test organization.
+- Prefer extending an existing test file over creating a new one when your change is in the same module.
+- Write tests that cover the main path and important edge cases. Include a failing-input test when relevant.
+- When fixing a bug, write a failing test first that reproduces the bug, then fix the code to make it pass.
+
+# Verify Changes
+Before committing or creating a PR, run through this checklist:
+1. **Build** \u2014 run the project-appropriate build command (go build, npm run build, cargo build, make, etc.). Fix any compilation errors.
+2. **Lint & typecheck** \u2014 run linter/formatter if the project has one (eslint, clippy, golangci-lint, etc.). Fix any new warnings.
+3. **Test** \u2014 run the full test suite (go test ./..., npm test, cargo test, make test, pytest, etc.). Fix any failures, including pre-existing tests you may have broken.
+4. **Review** \u2014 re-read your diff. Ensure no debug code, no unrelated changes, no secrets, no missing files.
+
+Do NOT skip verification. Do NOT proceed to PR creation with a broken build or failing tests.
 
 # GitHub Integration
 - Use the \`gh\` CLI for all GitHub operations: issues, pull requests, checks, releases.
@@ -111175,12 +111192,6 @@ You are working with a workspace. Available paths: ${workspaceDesc}
           });
           const systemMessage = await this.getSystemMessage();
           let userMessage = { role: "user", content: message.trim() };
-          if (this.enableTasks) {
-            userMessage.content = userMessage.content + "\n\n" + taskGuidancePrompt;
-            if (this.debug) {
-              console.log("[DEBUG] Task guidance injected into user message");
-            }
-          }
           if (options.schema && !options._schemaFormatted) {
             const schemaInstructions = generateSchemaInstructions(options.schema, { debug: this.debug });
             userMessage.content = message.trim() + schemaInstructions;

package/cjs/index.cjs

@@ -36120,7 +36120,7 @@ ${taskManager.formatTasksForPrompt()}`;
     }
   };
 }
-var taskItemSchema, taskSchema, taskSystemPrompt, taskGuidancePrompt;
+var taskItemSchema, taskSchema, taskSystemPrompt;
 var init_taskTool = __esm({
   "src/agent/tasks/taskTool.js"() {
     "use strict";
@@ -36181,11 +36181,6 @@ Tasks = logical units of work, not files or steps.
 - Circular dependencies are rejected
 - attempt_completion is blocked while tasks remain unresolved
 `;
-    taskGuidancePrompt = `Does this request have MULTIPLE DISTINCT GOALS?
-- "Do A AND B AND C" (multiple goals) \u2192 Create tasks for each goal
-- "Investigate/explain/find X" (single goal) \u2192 Skip tasks, just answer directly
-Multiple internal steps for ONE goal = NO tasks needed.
-If creating tasks, use the task tool with action="create" first.`;
   }
 });
 
@@ -82671,8 +82666,20 @@ If the solution is clear, you can jump to implementation right away. If not, ask
 - Check imports and existing utilities before creating new helpers \u2014 the project may already have what you need.
 
 # Task Planning
-- If the task tool is available, use it to break complex work into milestones before starting implementation.
-- Stay flexible \u2014 if your understanding changes mid-task, add, remove, or reorganize tasks as needed. The plan should serve you, not constrain you.
+When the request has **multiple distinct goals** (e.g. "Fix bug A AND add feature B"), use the task tool to track them:
+- Call the task tool with action="create" and a tasks array. Each task must have an "id" field.
+- Update task status to "in_progress" when starting and "completed" when done.
+- All tasks must be completed or cancelled before calling attempt_completion.
+- Stay flexible \u2014 add, remove, or reorganize tasks as your understanding changes.
+
+Do NOT create tasks for single-goal requests, even complex ones. Multiple internal steps for one goal (search, read, analyze, implement) do not need tasks.
+
+# Discovering Project Commands
+Before building or testing, determine the project's toolchain:
+- Check for Makefile, package.json (scripts), Cargo.toml, go.mod, pyproject.toml, or similar
+- Look for CI config (.github/workflows/, .gitlab-ci.yml) to see what commands CI runs
+- Read README for build/test instructions if the above are unclear
+- Common patterns: \`make build\`/\`make test\`, \`npm run build\`/\`npm test\`, \`cargo build\`/\`cargo test\`, \`go build ./...\`/\`go test ./...\`, \`python -m pytest\`
 
 # During Implementation
 - Always create a new branch before making changes to the codebase.
@@ -82683,12 +82690,22 @@ If the solution is clear, you can jump to implementation right away. If not, ask
 - When editing files, keep edits focused and minimal. For changes spanning more than a few lines, prefer line-targeted editing (start_line/end_line) over text replacement (old_string) \u2014 it constrains scope and prevents accidental removal of adjacent content. Never include unrelated sections in an edit operation.
 - After every significant change, verify the project still builds and passes linting. Do not wait until the end to discover breakage.
 
-# After Implementation
-- Verify the project builds successfully. If it doesn't, fix the build before moving on.
-- Run lint and typecheck commands if known for the project. Fix any new warnings or errors you introduced.
-- Add tests for any new or changed functionality. Tests must cover the main path and important edge cases.
-- Run the project's full test suite. If any tests fail (including pre-existing ones you may have broken), fix them before finishing.
-- When the task is done, respond to the user with a concise summary of what was implemented, what files were changed, and any relevant details. Include links (e.g. pull request URL) so the user has everything they need.
+# Writing Tests
+Every change must include tests. Before writing them:
+- Find existing test files for the module you changed \u2014 look in \`tests/\`, \`__tests__/\`, \`*_test.go\`, \`*.test.js\`, \`*.spec.ts\`, or co-located test modules (\`#[cfg(test)]\` in Rust).
+- Read those tests to understand the project's testing patterns: framework, assertion style, mocking approach, file naming, test organization.
+- Prefer extending an existing test file over creating a new one when your change is in the same module.
+- Write tests that cover the main path and important edge cases. Include a failing-input test when relevant.
+- When fixing a bug, write a failing test first that reproduces the bug, then fix the code to make it pass.
+
+# Verify Changes
+Before committing or creating a PR, run through this checklist:
+1. **Build** \u2014 run the project-appropriate build command (go build, npm run build, cargo build, make, etc.). Fix any compilation errors.
+2. **Lint & typecheck** \u2014 run linter/formatter if the project has one (eslint, clippy, golangci-lint, etc.). Fix any new warnings.
+3. **Test** \u2014 run the full test suite (go test ./..., npm test, cargo test, make test, pytest, etc.). Fix any failures, including pre-existing tests you may have broken.
+4. **Review** \u2014 re-read your diff. Ensure no debug code, no unrelated changes, no secrets, no missing files.
+
+Do NOT skip verification. Do NOT proceed to PR creation with a broken build or failing tests.
 
 # GitHub Integration
 - Use the \`gh\` CLI for all GitHub operations: issues, pull requests, checks, releases.
@@ -108426,12 +108443,6 @@ You are working with a workspace. Available paths: ${workspaceDesc}
           });
           const systemMessage = await this.getSystemMessage();
           let userMessage = { role: "user", content: message.trim() };
-          if (this.enableTasks) {
-            userMessage.content = userMessage.content + "\n\n" + taskGuidancePrompt;
-            if (this.debug) {
-              console.log("[DEBUG] Task guidance injected into user message");
-            }
-          }
           if (options.schema && !options._schemaFormatted) {
             const schemaInstructions = generateSchemaInstructions(options.schema, { debug: this.debug });
             userMessage.content = message.trim() + schemaInstructions;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@probelabs/probe",
-  "version": "0.6.0-rc277",
+  "version": "0.6.0-rc278",
   "description": "Node.js wrapper for the probe code search tool",
   "main": "src/index.js",
   "module": "src/index.js",

package/src/agent/ProbeAgent.js

@@ -104,7 +104,6 @@ import {
   TaskManager,
   createTaskTool,
   taskSystemPrompt,
-  taskGuidancePrompt,
   createTaskCompletionBlockedMessage
 } from './tasks/index.js';
 import { z } from 'zod';
@@ -3153,14 +3152,6 @@ Follow these instructions carefully:
       // Create user message with optional image support
       let userMessage = { role: 'user', content: message.trim() };
 
-      // START CHECKPOINT: Inject task guidance if tasks are enabled
-      if (this.enableTasks) {
-        userMessage.content = userMessage.content + '\n\n' + taskGuidancePrompt;
-        if (this.debug) {
-          console.log('[DEBUG] Task guidance injected into user message');
-        }
-      }
-
       // If schema is provided, prepend JSON format requirement to user message
       if (options.schema && !options._schemaFormatted) {
         const schemaInstructions = generateSchemaInstructions(options.schema, { debug: this.debug });

package/src/agent/shared/prompts.js

@@ -81,8 +81,20 @@ If the solution is clear, you can jump to implementation right away. If not, ask
 - Check imports and existing utilities before creating new helpers — the project may already have what you need.
 
 # Task Planning
-- If the task tool is available, use it to break complex work into milestones before starting implementation.
-- Stay flexible — if your understanding changes mid-task, add, remove, or reorganize tasks as needed. The plan should serve you, not constrain you.
+When the request has **multiple distinct goals** (e.g. "Fix bug A AND add feature B"), use the task tool to track them:
+- Call the task tool with action="create" and a tasks array. Each task must have an "id" field.
+- Update task status to "in_progress" when starting and "completed" when done.
+- All tasks must be completed or cancelled before calling attempt_completion.
+- Stay flexible — add, remove, or reorganize tasks as your understanding changes.
+
+Do NOT create tasks for single-goal requests, even complex ones. Multiple internal steps for one goal (search, read, analyze, implement) do not need tasks.
+
+# Discovering Project Commands
+Before building or testing, determine the project's toolchain:
+- Check for Makefile, package.json (scripts), Cargo.toml, go.mod, pyproject.toml, or similar
+- Look for CI config (.github/workflows/, .gitlab-ci.yml) to see what commands CI runs
+- Read README for build/test instructions if the above are unclear
+- Common patterns: \`make build\`/\`make test\`, \`npm run build\`/\`npm test\`, \`cargo build\`/\`cargo test\`, \`go build ./...\`/\`go test ./...\`, \`python -m pytest\`
 
 # During Implementation
 - Always create a new branch before making changes to the codebase.
@@ -93,12 +105,22 @@ If the solution is clear, you can jump to implementation right away. If not, ask
 - When editing files, keep edits focused and minimal. For changes spanning more than a few lines, prefer line-targeted editing (start_line/end_line) over text replacement (old_string) — it constrains scope and prevents accidental removal of adjacent content. Never include unrelated sections in an edit operation.
 - After every significant change, verify the project still builds and passes linting. Do not wait until the end to discover breakage.
 
-# After Implementation
-- Verify the project builds successfully. If it doesn't, fix the build before moving on.
-- Run lint and typecheck commands if known for the project. Fix any new warnings or errors you introduced.
-- Add tests for any new or changed functionality. Tests must cover the main path and important edge cases.
-- Run the project's full test suite. If any tests fail (including pre-existing ones you may have broken), fix them before finishing.
-- When the task is done, respond to the user with a concise summary of what was implemented, what files were changed, and any relevant details. Include links (e.g. pull request URL) so the user has everything they need.
+# Writing Tests
+Every change must include tests. Before writing them:
+- Find existing test files for the module you changed — look in \`tests/\`, \`__tests__/\`, \`*_test.go\`, \`*.test.js\`, \`*.spec.ts\`, or co-located test modules (\`#[cfg(test)]\` in Rust).
+- Read those tests to understand the project's testing patterns: framework, assertion style, mocking approach, file naming, test organization.
+- Prefer extending an existing test file over creating a new one when your change is in the same module.
+- Write tests that cover the main path and important edge cases. Include a failing-input test when relevant.
+- When fixing a bug, write a failing test first that reproduces the bug, then fix the code to make it pass.
+
+# Verify Changes
+Before committing or creating a PR, run through this checklist:
+1. **Build** — run the project-appropriate build command (go build, npm run build, cargo build, make, etc.). Fix any compilation errors.
+2. **Lint & typecheck** — run linter/formatter if the project has one (eslint, clippy, golangci-lint, etc.). Fix any new warnings.
+3. **Test** — run the full test suite (go test ./..., npm test, cargo test, make test, pytest, etc.). Fix any failures, including pre-existing tests you may have broken.
+4. **Review** — re-read your diff. Ensure no debug code, no unrelated changes, no secrets, no missing files.
+
+Do NOT skip verification. Do NOT proceed to PR creation with a broken build or failing tests.
 
 # GitHub Integration
 - Use the \`gh\` CLI for all GitHub operations: issues, pull requests, checks, releases.