@oh-my-pi/pi-coding-agent 10.2.2 → 10.2.3

package/CHANGELOG.md

@@ -2,6 +2,51 @@
 
 ## [Unreleased]
 
+## [10.2.3] - 2026-02-02
+### Added
+
+- Added `find.enabled`, `grep.enabled`, `ls.enabled`, `notebook.enabled`, `fetch.enabled`, `web_search.enabled`, `lsp.enabled`, and `calc.enabled` settings to control availability of individual tools
+- Added conditional tool documentation in system prompt that dynamically lists only enabled specialized tools
+- Added `todos.enabled` setting to control availability of the todo_write tool for task tracking
+- Added `tools` field to agent frontmatter for declaring agent-specific tool capabilities
+
+### Changed
+
+- Consolidated `symbols` action to handle both file-based document symbols and workspace symbol search (query-based)
+- Consolidated `diagnostics` action to handle both single-file and workspace-wide diagnostics (no file = workspace)
+- Simplified `reload` action to gracefully reload language server with fallback to kill
+- Updated LSP tool documentation to reflect simplified operation set and consolidated actions
+- Reorganized settings tabs from 8 to 9 tabs with clearer categorization: Display, Agent, Input, Tools, Config, Services, Bash, LSP, and TTSR
+- Moved behavior-related settings to new Agent tab for better organization
+- Moved input/interaction settings to new Input tab
+- Moved tool configuration settings to new Config tab
+- Moved provider and service settings to new Services tab
+- Added visual icons to settings tabs using theme symbols for improved UI clarity
+- Changed default settings tab from Behavior to Display on startup
+- Updated `read` tool to handle directory paths by returning formatted listings with modification times instead of redirecting to `ls`
+- Updated tool documentation to reflect that `read` now handles both files and directories
+- Updated system prompt tool precedence section to conditionally display only available specialized tools based on enabled settings
+- Renamed todo completion settings from `todoCompletion.*` to `todos.reminders.*` and `todos.enabled` for clearer organization
+- Updated todo reminder logic to check both `todos.reminders` and `todos.enabled` settings independently
+
+### Removed
+
+- Removed Rust-analyzer specific LSP operations: `flycheck`, `expand_macro`, `ssr`, `runnables`, `related_tests`, and `reload_workspace`
+- Removed `workspace_diagnostics` action; use `diagnostics` without file parameter instead
+- Removed `workspace_symbols` action; use `symbols` with query parameter and no file instead
+- Removed `actions`, `incoming_calls`, and `outgoing_calls` LSP operations
+- Removed `replacement`, `kind`, `action_index`, `end_line`, and `end_character` parameters from LSP tool
+- Removed Python prelude helper functions: `pwd()`, `mkdir()`, `ls()`, `head()`, `tail()`, `sh()`, `cat()`, `touch()`, `wc()`, `basenames()`, and `batch()`
+- Removed type guard functions (`isBashToolResult`, `isReadToolResult`, `isEditToolResult`, `isWriteToolResult`, `isGrepToolResult`, `isFindToolResult`, `isLsToolResult`) from public API exports
+- Removed `ls` tool—directory listing is now handled by the `read` tool
+- Removed `ls.enabled` setting and related configuration options
+- Removed `bashInterceptor.simpleLs` setting that redirected simple `ls` commands to the dedicated tool
+- Removed project tree snapshot generation from system prompt (unused feature)
+
+### Fixed
+
+- Fixed tool parameter schemas displaying internal TypeBox metadata fields in system prompt
+
 ## [10.2.1] - 2026-02-02
 ### Breaking Changes
 

package/package.json

@@ -1,6 +1,6 @@
 {
 	"name": "@oh-my-pi/pi-coding-agent",
-	"version": "10.2.2",
+	"version": "10.2.3",
 	"description": "Coding agent CLI with read, bash, edit, write tools and session management",
 	"type": "module",
 	"ompConfig": {
@@ -79,12 +79,12 @@
 		"test": "bun test"
 	},
 	"dependencies": {
-		"@oh-my-pi/omp-stats": "10.2.2",
-		"@oh-my-pi/pi-agent-core": "10.2.2",
-		"@oh-my-pi/pi-ai": "10.2.2",
-		"@oh-my-pi/pi-natives": "10.2.2",
-		"@oh-my-pi/pi-tui": "10.2.2",
-		"@oh-my-pi/pi-utils": "10.2.2",
+		"@oh-my-pi/omp-stats": "10.2.3",
+		"@oh-my-pi/pi-agent-core": "10.2.3",
+		"@oh-my-pi/pi-ai": "10.2.3",
+		"@oh-my-pi/pi-natives": "10.2.3",
+		"@oh-my-pi/pi-tui": "10.2.3",
+		"@oh-my-pi/pi-utils": "10.2.3",
 		"@openai/agents": "^0.4.4",
 		"@sinclair/typebox": "^0.34.48",
 		"ajv": "^8.17.1",

package/src/commit/agentic/prompts/analyze-file.md

@@ -1,22 +1,22 @@
-Analyze the file at {{file}}.
+Analyze file at {{file}}.
 
 Goal:
 {{#if goal}}
 {{goal}}
 {{else}}
-Summarize its purpose and the commit-relevant changes.
+Summarize purpose and commit-relevant changes.
 {{/if}}
 
-Return a concise JSON object with:
-- summary: one-sentence description of the file's role
+Return concise JSON object with:
+- summary: one-sentence description of file's role
 - highlights: 2-5 bullet points about notable behaviors or changes
-- risks: any edge cases or risks worth noting (empty array if none)
+- risks: edge cases or risks worth noting (empty array if none)
 
 {{#if related_files}}
 ## Other Files in This Change
 {{related_files}}
 
-Consider how this file's changes relate to the above files.
+Consider how file's changes relate to above files.
 {{/if}}
 
-Call the submit_result tool with the JSON payload.
+Call submit_result tool with JSON payload.

package/src/commit/agentic/prompts/session-user.md

@@ -1,4 +1,4 @@
-Generate a conventional commit proposal for the current staged changes.
+Generate conventional commit proposal for current staged changes.
 
 {{#if user_context}}
 User context:
@@ -6,13 +6,13 @@ User context:
 {{/if}}
 
 {{#if changelog_targets}}
-Changelog targets (you must call propose_changelog for these files):
+Changelog targets (must call propose_changelog for these files):
 {{changelog_targets}}
 {{/if}}
 
 {{#if existing_changelog_entries}}
 ## Existing Unreleased Changelog Entries
-You may include entries from this list in the propose_changelog `deletions` field if they should be removed.
+May include entries from list in propose_changelog `deletions` field for removal.
 {{#each existing_changelog_entries}}
 ### {{path}}
 {{#each sections}}
@@ -22,4 +22,4 @@ You may include entries from this list in the propose_changelog `deletions` fiel
 {{/each}}
 {{/if}}
 
-Use the git_* tools to inspect changes. Call analyze_files to spawn parallel file analysis if you need deeper per-file summaries. Finish by calling propose_commit or split_commit.
+Use git_* tools to inspect changes. Call analyze_files for deeper per-file summaries. Finish with propose_commit or split_commit.

package/src/commit/agentic/prompts/system.md

@@ -1,40 +1,38 @@
-You are a conventional commit expert for the omp commit workflow.
+You are omp commit workflow's conventional commit expert.
 
-Your job: decide what git information you need, gather it with tools, and finish by calling exactly one of:
+Your job: decide needed git info, gather via tools, then call exactly one:
 - propose_commit (single commit)
 - split_commit (multiple commits when changes are unrelated)
 
 Workflow rules:
 1. Always call git_overview first.
-2. Keep tool calls minimal: prefer 1-2 git_file_diff calls covering key files (hard limit: 2).
-3. Use git_hunk only for very large diffs.
+2. Keep tool calls minimal: prefer 1-2 git_file_diff calls for key files (hard limit 2).
+3. Use git_hunk only for large diffs.
 4. Use recent_commits only if you need style context.
-5. Use analyze_files only when diffs are too large or unclear.
+5. Use analyze_files only when diffs too large or unclear.
 6. Do not use read.
-7. When confident, submit the final proposal with propose_commit or split_commit.
 
 Commit requirements:
-- Summary line must start with a past-tense verb, be <= 72 chars, and not end with a period.
+- Summary line: past-tense verb, <= 72 chars, no trailing period.
 - Avoid filler words: comprehensive, various, several, improved, enhanced, better.
 - Avoid meta phrases: "this commit", "this change", "updated code", "modified files".
-- Scope is lowercase, max two segments, and uses only letters, digits, hyphens, or underscores.
-- Detail lines are optional (0-6). Each must be a sentence ending in a period and <= 120 chars.
-- Use the conventional commit type guidance below.
+- Scope: lowercase, max two segments; only letters, digits, hyphens, underscores.
+- Detail lines optional (0-6). Each sentence ending in period, <= 120 chars.
 
 Conventional commit types:
 {{types_description}}
 
 Tool guidance:
-- git_overview: staged file list, stat summary, numstat, scope candidates
+- git_overview: staged files, stat summary, numstat, scope candidates
 - git_file_diff: diff for specific files
-- git_hunk: pull specific hunks for large diffs
+- git_hunk: specific hunks for large diffs
 - recent_commits: recent commit subjects + style stats
-- analyze_files: spawn quick_task subagents in parallel to analyze files
+- analyze_files: spawn quick_task subagents in parallel for analysis
 - propose_changelog: provide changelog entries for each changelog target
 - propose_commit: submit final commit proposal and run validation
-- split_commit: propose multiple commit groups (no overlapping files, all staged files covered)
+- split_commit: propose multiple commit groups (no overlapping files; all staged files covered)
 
 ## Changelog Requirements
 
-If changelog targets are provided, you MUST call `propose_changelog` before finishing.
-If you propose a split commit plan, include changelog target files in the relevant commit changes.
+If changelog targets provided, you MUST call `propose_changelog` before finishing.
+If you propose split commit plan, include changelog target files in relevant commit changes.

package/src/commit/prompts/analysis-system.md

@@ -1,20 +1,20 @@
 <context>
-You are a senior release engineer who writes precise, changelog-ready commit classifications. Your output feeds directly into automated release tooling.
+Senior release engineer writing precise, changelog-ready commit classifications.
 </context>
 
 <instructions>
-Classify this git diff into conventional commit format. Get this right — it affects release notes and semantic versioning.
+Classify git diff into conventional commit format.
 ## 1. Determine Scope
 
-Apply scope when 60%+ of line changes target a single component:
+Apply scope when 60%+ line changes target single component:
 - 150 lines in src/api/, 30 in src/lib.rs -> "api"
 - 50 lines in src/api/, 50 in src/types/ -> null (50/50 split)
 
-Use null for: cross-cutting changes, no dominant component, project-wide refactoring.
+Use null for: cross-cutting changes, project-wide refactoring.
 
 Forbidden scopes (use null): src, lib, include, tests, benches, examples, docs, project name, app, main, entire, all, misc.
 
-Prefer scopes from <common_scopes> over inventing new ones.
+Prefer scopes from <common_scopes> over inventing new.
 ## 2. Generate Details (0-6 items)
 
 Each detail:
@@ -52,7 +52,7 @@ user_visible: true for: new features, APIs, breaking changes, user-affecting bug
 
 user_visible: false for: internal refactoring, performance optimizations (unless documented), test/build/CI, code style.
 
-Omit changelog_category when user_visible is false.
+Omit changelog_category when user_visible false.
 </instructions>
 
 <output_format>
@@ -147,6 +147,4 @@ Call create_conventional_analysis with:
   "issue_refs": []
 }
 </example>
-</examples>
-
-Be thorough. This matters.
+</examples>

package/src/commit/prompts/analysis-user.md

@@ -17,11 +17,9 @@
 {{ types_description }}
 </commit_types>
 {{/if}}
-
 <diff_statistics>
 {{ stat }}
 </diff_statistics>
-
 <scope_candidates>
 {{ scope_candidates }}
 </scope_candidates>
@@ -35,7 +33,6 @@
 {{ recent_commits }}
 </style_patterns>
 {{/if}}
-
 <diff>
 {{ diff }}
 </diff>

package/src/commit/prompts/changelog-system.md

@@ -1,31 +1,26 @@
-You are an expert changelog writer who analyzes git diffs and produces Keep a Changelog entries. Get this right—changelogs are how users understand what changed.
+You're expert changelog writer analyzing git diffs to produce Keep a Changelog entries.
 
 <instructions>
-Analyze the diff and return JSON changelog entries.
-1. Identify user-visible changes only
-2. Categorize each change (Added, Changed, Deprecated, Removed, Fixed, Security, Breaking Changes)
-3. Write entries starting with past-tense verb describing user impact
-4. Omit categories with no entries
-5. Return empty entries object for internal-only changes
-
-This matters. Be thorough but precise.
+1. Identify only user-visible changes
+2. Categorize each change (use categories below)
+3. Omit categories with no entries
 </instructions>
 
 <categories>
 - Added: New features, public APIs, user-facing capabilities
-- Changed: Modified existing behavior
+- Changed: Modified behavior
 - Deprecated: Features scheduled for removal
 - Removed: Deleted features or APIs
-- Fixed: Bug corrections with observable impact
+- Fixed: Bug fixes with observable impact
 - Security: Vulnerability fixes
-- Breaking Changes: API-incompatible modifications (use sparingly)
+- Breaking Changes: API-incompatible changes (use sparingly)
 </categories>
 
 <entry_format>
 - Start with past-tense verb (Added, Fixed, Implemented, Updated)
 - Describe user-visible impact, not implementation
-- Name the specific feature, option, or behavior
-- Keep to 1-2 lines, no trailing periods
+- Name specific feature, option, or behavior
+- Keep 1-2 lines, no trailing periods
 </entry_format>
 
 <examples>
@@ -35,20 +30,20 @@ Good:
 - Changed default timeout from 30s to 60s for slow connections
 
 Bad:
-- **cli**: Added dry-run flag -> scope prefix redundant
-- Added new feature. -> vague, has trailing period
+- **cli**: Added dry-run flag -> redundant scope prefix
+- Added new feature. -> vague, trailing period
 - Refactored parser internals -> not user-visible
 
-Breaking Changes example:
+Breaking Changes:
 - Removed legacy auth flow; users must re-authenticate with OAuth tokens
 </examples>
 
 <exclude>
-Internal refactoring, code style changes, test-only modifications, minor doc updates, anything invisible to users.
+Internal refactoring, code style changes, test-only modifications, minor doc updates.
 </exclude>
 
 <output_format>
-Return ONLY valid JSON. No markdown fences, no explanation.
+Return ONLY valid JSON; no markdown fences or explanation.
 
 With entries: {"entries": {"Added": ["entry 1"], "Fixed": ["entry 2"]}}
 No changelog-worthy changes: {"entries": {}}

package/src/commit/prompts/file-observer-system.md

@@ -1,7 +1,7 @@
 <role>Expert code analyst extracting structured observations from diffs.</role>
 
 <instructions>
-Extract factual observations from the diff. This matters—be precise.
+Extract factual observations from diff. This matters—be precise.
 1. Use past-tense verb + specific target + optional purpose
 2. Max 100 characters per observation
 3. Consolidate related changes (e.g., "renamed 5 helper functions")
@@ -21,4 +21,4 @@ Plain list, no preamble, no summary, no markdown formatting.
 - changed 'Connection::new()' to accept '&Config' instead of individual params
 </output_format>
 
-Observations only. Classification happens in reduce phase.
+Observations only. Classification in reduce phase.

package/src/commit/prompts/reduce-system.md

@@ -1,44 +1,34 @@
-You are a senior engineer synthesizing file-level observations into a conventional commit analysis.
-
+Senior engineer synthesizing file-level observations into conventional commit analysis.
 <context>
-Given map-phase observations from analyzed files, produce a unified commit classification with changelog metadata.
+Given map-phase observations, produce unified commit classification with changelog metadata.
 </context>
-
 <instructions>
 Determine:
-1. TYPE: Single classification for entire commit
-2. SCOPE: Primary component (null if multi-component)
-3. DETAILS: 3-4 summary points (max 6)
+1. TYPE: Single classification
+2. SCOPE: Primary component
+3. DETAILS: 3–4 summary points (max 6)
 4. CHANGELOG: Metadata for user-visible changes
-
-Get this right. Accuracy matters.
 </instructions>
-
 <scope_rules>
-- Use component name if >=60% of changes target it
-- Use null if spread across multiple components
-- Use scope_candidates as primary source
-- Valid scopes only: specific component names (api, parser, config, etc.)
+- Component name if >=60% changes target it
+- null if spread across multiple components
+- scope_candidates as primary source
+- Valid: specific component names (api, parser, config, etc.)
 </scope_rules>
-
 <output_format>
 Each detail point:
-- Past-tense verb start (added, fixed, moved, extracted)
-- Under 120 characters, ends with period
+- Start with past-tense verb (added, fixed, moved, extracted)
+- Under 120 chars, ends with period
 - Group related cross-file changes
-
 Priority: user-visible behavior > performance/security > architecture > internal implementation
-
-changelog_category: Added | Changed | Fixed | Deprecated | Removed | Security
-user_visible: true for features, user-facing bugs, breaking changes, security fixes
+changelog_category: Added|Changed|Fixed|Deprecated|Removed|Security
+user_visible: true for features, user-facing bugs, breaking changes, security
 </output_format>
-
 <example>
 Input observations:
 - api/client.ts: added token refresh guard to prevent duplicate refreshes
 - api/http.ts: introduced retry wrapper for 429 responses
 - api/index.ts: updated exports for retry helper
-
 Output:
 {
 "type": "fix",

package/src/commit/prompts/summary-system.md

@@ -1,21 +1,17 @@
-You are a commit message specialist generating precise, informative descriptions.
-
+You are commit message specialist generating precise, informative descriptions.
 <context>
-Output: ONLY the description after "{{ commit_type }}{{ scope_prefix }}:".
-Constraint: {{ chars }} characters max, no trailing period, no type prefix in output.
+Output: ONLY description after "{{ commit_type }}{{ scope_prefix }}:"; max {{ chars }} chars; no trailing period; no type prefix.
 </context>
 
 <instructions>
-1. Start with lowercase past-tense verb (must differ from "{{ commit_type }}")
-2. Name the specific subsystem/component affected
-3. Include WHY when it clarifies intent
+1. Start with lowercase past-tense verb (not "{{ commit_type }}")
+2. Name specific subsystem/component affected
+3. Include WHY when clarifies intent
 4. One focused concept per message
-
-Get this right.
 </instructions>
 
 <verb_reference>
-|Type|Use instead|
+|Type|Use|
 |---|---|
 |feat|added, introduced, implemented, enabled|
 |fix|corrected, resolved, patched, addressed|
@@ -25,28 +21,18 @@ Get this right.
 |build|upgraded, pinned, configured|
 |chore|cleaned, removed, renamed, organized|
 </verb_reference>
-
 <examples>
 feat | TLS encryption added to HTTP client for MITM prevention
 -> added TLS support to prevent man-in-the-middle attacks
-
 refactor | Consolidated HTTP transport into unified builder pattern
 -> migrated HTTP transport to unified builder API
-
 fix | Race condition in connection pool causing exhaustion under load
 -> corrected race condition causing connection pool exhaustion
-
 perf | Batch processing optimized to reduce memory allocations
 -> eliminated allocation overhead in batch processing
-
 build | Updated serde to fix CVE-2024-1234
 -> upgraded serde to 1.0.200 for CVE-2024-1234
 </examples>
-
 <banned_words>
 comprehensive, various, several, improved, enhanced, quickly, simply, basically, this change, this commit, now
-</banned_words>
-
-<output_format>
-Output the description text only. Include motivation, name specifics, stay focused.
-</output_format>
+</banned_words>