savant-code 0.0.19 → 0.0.20

package/common/src/tools/params/tool/run-terminal-command.ts

@@ -1,185 +0,0 @@
-import z from 'zod/v4'
-
-import { $getNativeToolCallExampleString, jsonToolResultSchema } from '../utils'
-
-import type { $ToolParams } from '../../constants'
-
-export const terminalCommandOutputSchema = z.union([
-  z.object({
-    command: z.string(),
-    startingCwd: z.string().optional(),
-    message: z.string().optional(),
-    stderr: z.string().optional(),
-    stdout: z.string().optional(),
-    exitCode: z.number().optional(),
-  }),
-  z.object({
-    command: z.string(),
-    startingCwd: z.string().optional(),
-    message: z.string().optional(),
-    stderr: z.string().optional(),
-    stdoutOmittedForLength: z.literal(true),
-    exitCode: z.number().optional(),
-  }),
-  z.object({
-    command: z.string(),
-    processId: z.number(),
-    backgroundProcessStatus: z.enum(['running', 'completed', 'error']),
-  }),
-  z.object({
-    command: z.string(),
-    errorMessage: z.string(),
-  }),
-])
-
-export const gitCommitGuidePrompt = `
-### Using git to commit changes
-
-When the user requests a new git commit, please follow these steps closely:
-
-1. **Run two run_terminal_command tool calls:**
-   - Run \`git diff\` to review both staged and unstaged modifications.
-   - Run \`git log\` to check recent commit messages, ensuring consistency with this repository's style.
-
-2. **Select relevant files to include in the commit:**
-   Use the git context established at the start of this conversation to decide which files are pertinent to the changes. Stage any new untracked files that are relevant, but avoid committing previously modified files (from the beginning of the conversation) unless they directly relate to this commit.
-
-3. **Analyze the staged changes and compose a commit message:**
-   Enclose your analysis in <commit_analysis> tags. Within these tags, you should:
-   - Note which files have been altered or added.
-   - Categorize the nature of the changes (e.g., new feature, fix, refactor, documentation, etc.).
-   - Consider the purpose or motivation behind the alterations.
-   - Refrain from using tools to inspect code beyond what is presented in the git context.
-   - Evaluate the overall impact on the project.
-   - Check for sensitive details that should not be committed.
-   - Draft a concise, one- to two-sentence commit message focusing on the “why” rather than the “what.”
-   - Use precise, straightforward language that accurately represents the changes.
-   - Ensure the message provides clarity—avoid generic or vague terms like “Update” or “Fix” without context.
-   - Revisit your draft to confirm it truly reflects the changes and their intention.
-
-4. **Create the commit, ending with this specific footer:**
-   \`\`\`
-   Generated with SavantCode 🤖
-   Co-Authored-By: SavantCode <noreply@savantcode.com>
-   \`\`\`
-   To maintain proper formatting, use cross-platform compatible commit messages:
-   
-   **For Unix/bash shells:**
-   \`\`\`
-   git commit -m "$(cat <<'EOF'
-   Your commit message here.
-
-   🤖 Generated with SavantCode
-   Co-Authored-By: SavantCode <noreply@savantcode.com>
-   EOF
-   )"
-   \`\`\`
-   
-   **For Windows Command Prompt:**
-   \`\`\`
-   git commit -m "Your commit message here.
-
-   🤖 Generated with SavantCode
-   Co-Authored-By: SavantCode <noreply@savantcode.com>"
-   \`\`\`
-   
-   Always detect the platform and use the appropriate syntax. HEREDOC syntax (\`<<'EOF'\`) only works in bash/Unix shells and will fail on Windows Command Prompt.
-
-**Important details**
-
-- When feasible, use a single \`git commit -am\` command to add and commit together, but do not accidentally stage unrelated files.
-- Never alter the git config.
-- Do not push to the remote repository.
-- Avoid using interactive flags (e.g., \`-i\`) that require unsupported interactive input.
-- Do not create an empty commit if there are no changes.
-- Make sure your commit message is concise yet descriptive, focusing on the intention behind the changes rather than merely describing them.
-`
-
-const toolName = 'run_terminal_command'
-const endsAgentStep = true
-const inputSchema = z
-  .object({
-    // Can be empty to use it for a timeout.
-    command: z
-      .string()
-      .min(1, 'Command cannot be empty')
-      .describe(`CLI command valid for user's OS.`),
-    process_type: z
-      .enum(['SYNC'])
-      .default('SYNC')
-      .describe(
-        `Waits for the command to finish and returns its output. Default SYNC`,
-      ),
-    cwd: z
-      .string()
-      .optional()
-      .describe(
-        `The working directory to run the command in. Default is the project root.`,
-      ),
-    timeout_seconds: z
-      .number()
-      .default(30)
-      .optional()
-      .describe(`Set to -1 for no timeout. Default 30`),
-  })
-  .describe(
-    `Execute a CLI command from the **project root** (different from the user's cwd).`,
-  )
-const description = `
-Stick to these use cases:
-1. Typechecking the project or running build (e.g., "npm run build"). Reading the output can help you edit code to fix build errors. If possible, use an option that performs checks but doesn't emit files, e.g. \`tsc --noEmit\`.
-2. Running tests (e.g., "npm test"). Reading the output can help you edit code to fix failing tests. Or, you could write new unit tests and then run them.
-3. Moving, renaming, or deleting files and directories. These actions can be vital for refactoring requests. Use commands like \`mv\`/\`move\` or \`rm\`/\`del\`.
-
-Most likely, you should ask for permission for any other type of command you want to run. If asking for permission, show the user the command you want to run using \`\`\` tags and *do not* use the tool call format, e.g.:
-\`\`\`bash
-git branch -D foo
-\`\`\`
-
-DO NOT do any of the following:
-1. Run commands that can modify files outside of the project directory, install packages globally, install virtual environments, or have significant side effects outside of the project directory, unless you have explicit permission from the user. Treat anything outside of the project directory as read-only.
-2. Run \`git push\` because it can break production (!) if the user was not expecting it. Don't run \`git commit\`, \`git rebase\`, or related commands unless you get explicit permission. If a user asks to commit changes, you can do so, but you should not invoke any further git commands beyond the git commit command.
-3. Run scripts without asking. Especially don't run scripts that could run against the production environment or have permanent effects without explicit permission from the user.
-4. Be careful with any command that has big or irreversible effects. Anything that touches a production environment, servers, the database, or other systems that could be affected by a command should be run with explicit permission from the user.
-5. Use the run_terminal_command tool to create or edit files. Do not use \`cat\` or \`echo\` to create or edit files. You should instead use other tools for creating or editing files.
-6. Use the wrong package manager for the project. For example, if the project uses \`pnpm\` or \`bun\` or \`yarn\`, you should not use \`npm\`. Similarly not everyone uses \`pip\` for python, etc.
-
-Do:
-- If there's an opportunity to use "-y" or "--yes" flags, use them. Any command that prompts for confirmation will hang if you don't use the flags.
-
-Notes:
-- If the user references a specific file, it could be either from their cwd or from the project root. You **must** determine which they are referring to (either infer or ask). Then, you must specify the path relative to the project root (or use the cwd parameter)
-- Commands can succeed without giving any output, e.g. if no type errors were found.
-
-${gitCommitGuidePrompt}
-
-Example:
-${$getNativeToolCallExampleString({
-  toolName,
-  inputSchema,
-  input: {
-    command: 'echo "hello world"',
-  },
-  endsAgentStep,
-})}
-
-${$getNativeToolCallExampleString({
-  toolName,
-  inputSchema,
-  input: {
-    command: `git commit -m "Your commit message here.
-
-🤖 Generated with SavantCode
-Co-Authored-By: SavantCode <noreply@savantcode.com>"`,
-  },
-  endsAgentStep,
-})}
-    `.trim()
-
-export const runTerminalCommandParams = {
-  toolName,
-  endsAgentStep,
-  description,
-  inputSchema,
-  outputSchema: jsonToolResultSchema(terminalCommandOutputSchema),
-} satisfies $ToolParams

package/common/src/tools/params/tool/sequential-thinking.ts

@@ -1,110 +0,0 @@
-import z from 'zod/v4'
-
-import { $getNativeToolCallExampleString, textToolResultSchema } from '../utils'
-
-import type { $ToolParams } from '../../constants'
-
-const toolName = 'sequentialthinking'
-const endsAgentStep = false
-
-/**
- * FID-2026-0801-012: permissive boolean coercion before strict validation.
- * Matches the MCP reference server (`coercedBoolean`): models commonly emit
- * stringified `"true"`/`"false"`; strict-only schemas reject them and crash
- * the loop (MCP issues #2473 / #2792). This normalizes serialization quirks
- * without inventing values — anything else still fails validation.
- */
-const coercedBoolean = z.preprocess((val) => {
-  if (typeof val === 'boolean') return val
-  if (typeof val === 'string') {
-    if (val.toLowerCase() === 'true') return true
-    if (val.toLowerCase() === 'false') return false
-  }
-  return val
-}, z.boolean())
-
-const inputSchema = z
-  .object({
-    thought: z
-      .string()
-      .min(1, 'Thought cannot be empty')
-      .describe('Your current thinking step.'),
-    nextThoughtNeeded: coercedBoolean.describe(
-      'Whether another thought step is needed.',
-    ),
-    thoughtNumber: z.coerce
-      .number()
-      .int()
-      .min(1)
-      .describe('Current position in the thought sequence.'),
-    totalThoughts: z.coerce
-      .number()
-      .int()
-      .min(1)
-      .describe('Current estimate of total thoughts needed.'),
-    isRevision: coercedBoolean
-      .optional()
-      .describe('Whether this revises a previous thought.'),
-    revisesThought: z.coerce
-      .number()
-      .int()
-      .optional()
-      .describe('Which thought is being revised.'),
-    branchFromThought: z.coerce
-      .number()
-      .int()
-      .optional()
-      .describe('Branching from this thought number.'),
-    branchId: z
-      .string()
-      .optional()
-      .describe('Branch identifier for alternative exploration paths.'),
-    needsMoreThoughts: coercedBoolean
-      .optional()
-      .describe('Extend beyond the initial totalThoughts estimate.'),
-  })
-  .describe(
-    'Structured step-by-step reasoning with support for branching, revision, and convergence detection.',
-  )
-
-const description = `
-Use when you need to reason through a complex problem with structured step-by-step thinking.
-
-This tool supports:
-- **Revision**: Correct a previous thought by setting isRevision and revisesThought.
-- **Branching**: Explore alternative approaches by setting branchFromThought and branchId.
-- **Extension**: Signal that more thoughts are needed than initially estimated.
-
-When to use:
-- Architecture design decisions
-- Debugging complex issues
-- Critiquing specs, plans, or implementations
-- Choosing between implementation approaches
-- Any non-trivial reasoning task
-
-When NOT to use:
-- Simple factual questions
-- Trivial decisions
-- Quick lookups
-
-Example:
-${$getNativeToolCallExampleString({
-  toolName,
-  inputSchema,
-  input: {
-    thought: 'Analyze the problem constraints and requirements...',
-    thoughtNumber: 1,
-    totalThoughts: 5,
-    nextThoughtNeeded: true,
-  },
-  endsAgentStep,
-})}
-`.trim()
-
-export const sequentialThinkingParams = {
-  toolName,
-  endsAgentStep,
-  description,
-  inputSchema,
-  outputSchema: textToolResultSchema(),
-} satisfies $ToolParams

package/common/src/tools/params/tool/set-messages.ts

@@ -1,42 +0,0 @@
-import z from 'zod/v4'
-
-import { $getNativeToolCallExampleString, textToolResultSchema } from '../utils'
-
-import type { Message } from '../../../types/messages/savant-code-message'
-import type { $ToolParams } from '../../constants'
-
-const toolName = 'set_messages'
-const endsAgentStep = true
-const inputSchema = z
-  .object({
-    messages: z.array(z.custom<Message>()),
-  })
-  .describe(`Set the conversation history to the provided messages.`)
-const description = `
-Example:
-${$getNativeToolCallExampleString({
-  toolName,
-  inputSchema,
-  input: {
-    messages: [
-      {
-        role: 'user',
-        content: 'Hello, how are you?',
-      },
-      {
-        role: 'assistant',
-        content: 'I am fine, thank you.',
-      },
-    ],
-  },
-  endsAgentStep,
-})}
-`.trim()
-
-export const setMessagesParams = {
-  toolName,
-  endsAgentStep,
-  description,
-  inputSchema,
-  outputSchema: textToolResultSchema(),
-} satisfies $ToolParams

package/common/src/tools/params/tool/set-output.ts

@@ -1,62 +0,0 @@
-import z from 'zod/v4'
-
-import { jsonValueSchema } from '../../../types/json'
-import { $getNativeToolCallExampleString } from '../utils'
-
-import type { $ToolParams } from '../../constants'
-
-const toolName = 'set_output'
-const endsAgentStep = false
-
-// WHY `data` EXISTS IN THE INPUT SCHEMA:
-// Subagents inherit their parent's tool definitions, and because of prompt caching
-// we cannot modify or add tools mid-conversation. OpenAI models enforce the tool's
-// input schema strictly, so we need a permissive shape that any model can call.
-// An empty schema or `z.object({}).passthrough()` would be rejected by OpenAI's
-// strict schema enforcement. The `data: z.record(...)` field is a deliberately
-// vague shape that satisfies OpenAI while allowing us to inject the real
-// outputSchema later in the conversation (in the instructions prompt).
-//
-// At runtime, the handler (`packages/agent-runtime/src/tools/handlers/tool/set-output.ts`)
-// tries parsing against the real outputSchema in two ways:
-//   1. Parse the raw output (agent passed fields at top level)
-//   2. Fallback: parse `output.data` (agent wrapped fields in `data`)
-// This means both `{ results: [...] }` and `{ data: { results: [...] } }` are accepted.
-const inputSchema = z
-  .looseObject({
-    data: z.record(z.string(), jsonValueSchema).optional(),
-  })
-  .describe(
-    'JSON object to set as the agent output. The shape of the parameters are specified dynamically further down in the conversation. This completely replaces any previous output. If the agent was spawned, this value will be passed back to its parent. If the agent has an outputSchema defined, the output will be validated against it.',
-  )
-const description = `
-Subagents must use this tool as it is the only way to report any findings. Nothing else you write will be visible to the user/parent agent.
-
-Note that the output schema is provided dynamically in a user prompt further down in the conversation. Be sure to follow what the latest output schema is when using this tool.
-
-Please set the output with all the information and analysis you want to pass on. If you just want to send a simple message, use an object with the key "message" and value of the message you want to send.
-Example:
-${$getNativeToolCallExampleString({
-  toolName,
-  inputSchema,
-  input: {
-    message: 'I found a bug in the code!',
-  },
-  endsAgentStep,
-})}
-`.trim()
-
-export const setOutputParams = {
-  toolName,
-  endsAgentStep,
-  description,
-  inputSchema,
-  outputSchema: z.tuple([
-    z.object({
-      type: z.literal('json'),
-      value: z.object({
-        message: z.string(),
-      }),
-    }),
-  ]),
-} satisfies $ToolParams

package/common/src/tools/params/tool/set-scaffold-complete.ts

@@ -1,51 +0,0 @@
-import z from 'zod/v4'
-
-import { $getNativeToolCallExampleString, jsonToolResultSchema } from '../utils'
-
-import type { $ToolParams } from '../../constants'
-
-const toolName = 'set_scaffold_complete'
-const endsAgentStep = false
-const inputSchema = z
-  .object({
-    summary: z
-      .string()
-      .optional()
-      .describe('Optional short summary of what the scaffold completed.'),
-  })
-  .describe(
-    'Declare that the current scaffold session is complete. This seals the umbrella FID and reverts the CLI to EDIT mode. Only available in SCAFFOLD mode.',
-  )
-
-const description = `
-Declare that the current scaffold session is complete.
-
-Effect:
-- Seals the umbrella FID for this scaffold.
-- Reverts the CLI mode toggle back to EDIT.
-- May only be called when the orchestrator is in SCAFFOLD mode.
-
-Example:
-${$getNativeToolCallExampleString({
-  toolName,
-  inputSchema,
-  input: {
-    summary:
-      'Initial project scaffold created (package.json, tsconfig.json, README).',
-  },
-  endsAgentStep,
-})}
-`.trim()
-
-export const setScaffoldCompleteParams = {
-  toolName,
-  endsAgentStep,
-  description,
-  inputSchema,
-  outputSchema: jsonToolResultSchema(
-    z.object({
-      message: z.string(),
-      scaffoldComplete: z.boolean(),
-    }),
-  ),
-} satisfies $ToolParams

package/common/src/tools/params/tool/skill.ts

@@ -1,56 +0,0 @@
-import z from 'zod/v4'
-
-import { $getNativeToolCallExampleString, jsonToolResultSchema } from '../utils'
-
-import type { $ToolParams } from '../../constants'
-
-const toolName = 'skill'
-const endsAgentStep = true
-
-const inputSchema = z
-  .object({
-    name: z.string().min(1).describe('The name of the skill to load'),
-  })
-  .describe(
-    'Load a skill by name to get its full instructions. Skills provide reusable behaviors and instructions.',
-  )
-
-const outputValueSchema = z.object({
-  name: z.string(),
-  description: z.string(),
-  content: z.string(),
-  license: z.string().optional(),
-})
-
-/**
- * Placeholder marker that will be replaced with the actual available skills XML.
- * This is replaced at runtime when generating tool prompts.
- */
-export const AVAILABLE_SKILLS_PLACEHOLDER = '{{AVAILABLE_SKILLS}}'
-
-// Base description - the full description with available skills is generated dynamically
-const baseDescription = `Load a skill by name to get its full instructions. Skills provide reusable behaviors and domain-specific knowledge that you can use to complete tasks.
-
-The following are the pre-loaded skills available at session start:
-${AVAILABLE_SKILLS_PLACEHOLDER}
-
-Note: You can load any skill by name, including ones created or installed during this session (e.g. via \`npx skills add\`). The skill is always read fresh from disk, so its latest contents are used.
-
-Example:
-${$getNativeToolCallExampleString({
-  toolName,
-  inputSchema,
-  input: {
-    name: 'git-release',
-  },
-  endsAgentStep,
-})}
-`
-
-export const skillParams = {
-  toolName,
-  endsAgentStep,
-  description: baseDescription.trim(),
-  inputSchema,
-  outputSchema: jsonToolResultSchema(outputValueSchema),
-} satisfies $ToolParams

package/common/src/tools/params/tool/spawn-agent-inline.ts

@@ -1,57 +0,0 @@
-import z from 'zod/v4'
-
-import { jsonValueSchema } from '../../../types/json'
-import {
-  $getNativeToolCallExampleString,
-  coerceToObject,
-  textToolResultSchema,
-} from '../utils'
-
-import type { $ToolParams } from '../../constants'
-
-const toolName = 'spawn_agent_inline'
-const endsAgentStep = true
-const inputSchema = z
-  .object({
-    agent_type: z.string().describe('Agent to spawn'),
-    prompt: z.string().optional().describe('Prompt to send to the agent'),
-    params: z
-      .preprocess(coerceToObject, z.record(z.string(), jsonValueSchema))
-      .optional()
-      .describe('Parameters object for the agent (if any)'),
-  })
-  .describe(
-    `Spawn a single agent that runs within the current message history.`,
-  )
-const description = `
-Spawn a single agent that runs within the current message history. 
-The spawned agent sees all previous messages and any messages it adds 
-are preserved when control returns to you.
-
-You should prefer to use the spawn_agents tool unless instructed otherwise. This tool is only for special cases.
-
-This is useful for:
-- Delegating specific tasks while maintaining context
-- Having specialized agents process information inline
-- Managing message history (e.g., summarization)
-The agent will run until it calls end_turn, then control returns to you. There is no tool result for this tool.
-Example:
-${$getNativeToolCallExampleString({
-  toolName,
-  inputSchema,
-  input: {
-    agent_type: 'scout',
-    prompt: 'Find files related to authentication',
-    params: { paths: ['src/auth.ts', 'src/user.ts'] },
-  },
-  endsAgentStep,
-})}
-`.trim()
-
-export const spawnAgentInlineParams = {
-  toolName,
-  endsAgentStep,
-  description,
-  inputSchema,
-  outputSchema: textToolResultSchema(),
-} satisfies $ToolParams