feat(coding-agent): include custom tools in system prompt

[semtexzv]

Custom tools registered via extensions or the SDK are available to the LLM through the API tool listing, but invisible in the system prompt. The "Available tools" and "Guidelines" sections only show built-ins. This means the LLM gets no high-level orientation about custom tools and extension authors can't inject behavioral guidelines.

Changes

Add two optional fields to ToolDefinition:

• shortDescription — one-liner for the system prompt tool list (falls back to first line of description)
• systemGuidelines — bullet points appended to the system prompt guidelines section

Custom tools now appear in the system prompt alongside built-ins, with stable ordering: built-ins first (fixed order), then custom tools alphabetically. Guidelines are deduplicated via Set.

Example:

pi.registerTool({
  name: "my_tool",
  description: "Manage a todo list. Supports listing, adding, and removing items.",
  shortDescription: "Manage a todo list",
  systemGuidelines: ["Confirm with the user before removing todo items"],
  // ...
});

Produces:

Available tools:
- read: Read file contents
- bash: Execute bash commands (ls, grep, find, etc.)
- my_tool: Manage a todo list

Guidelines:
- Use read to examine files before editing...
- Confirm with the user before removing todo items

Files

• extensions/types.ts — add shortDescription?, systemGuidelines? to ToolDefinition
• system-prompt.ts — SystemPromptToolInfo, resolveShortDescription() fallback, addGuideline() dedup, export DEFAULT_TOOL_ORDER
• agent-session.ts — build SystemPromptToolInfo map from built-in + custom tools, stable ordering, pass tools to buildSystemPrompt()
• docs/extensions.md — document new fields with examples
• docs/sdk.md — document new fields for SDK usage

Possible follow-up: Per-tool system prompt sections

This is out of scope for this PR but worth considering:

• a systemPromptSection field that emits a dedicated block per tool in the system prompt, similar to how skills get <available_skills> and context files get ## path sections.
• This would allow extensions to provide usage examples, workflow descriptions, or domain context beyond what fits in a guideline bullet. Could be placed before the skills listing:

[badlogic]

Default behavior change: buildSystemPrompt currently defaults to read/bash/edit/write when callers pass no tools. This PR makes the implicit default all built-ins via DEFAULT_TOOL_ORDER. Please keep the default at read/bash/edit/write for direct buildSystemPrompt callers.

[semtexzv]

Updated the behavior to keep the previous system prompt for existing callers.

Additionally:

1. Added a way to exclude tool from system prompt, if shortDescription is "", tool is excluded.
2. Added tests to cover different behaviors.

[badlogic]

Signaling exclusion via empty string is not great. I think it should be opt in: if shortDescription is givren, include, otherwise don't, guidelines optional.

[semtexzv]

Updated. Kept it as a separate commit, will rebase for submission

[pasky]

I'm curious - does this really matter? In fact I was surprised even about the system prompt talking about the default tools. In my experience, just keeping clear tool descriptions should be enough guidance for modern models - that's why tool descriptions exist after all?

[ThePaSch]

I'm curious - does this really matter? In fact I was surprised even about the system prompt talking about the default tools. In my experience, just keeping clear tool descriptions should be enough guidance for modern models - that's why tool descriptions exist after all?

Agreed. I can see the value in a "guidelines" property that can (deterministically) inject into the system prompt on session start, but tools literally already have a description, so shortDescription is reinventing the wheel.