@every-env/compound-plugin 2.40.2 → 2.40.3

package/CHANGELOG.md

@@ -7,6 +7,13 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 Release numbering now follows the repository `v*` tag line. Starting at `v2.34.0`, the root CLI package and this changelog stay on that shared version stream. Older entries below retain the previous `0.x` CLI numbering.
 
+## [2.40.3](https://github.com/EveryInc/compound-engineering-plugin/compare/v2.40.2...v2.40.3) (2026-03-17)
+
+
+### Bug Fixes
+
+* research agents prefer native tools over shell for repo exploration ([b290690](https://github.com/EveryInc/compound-engineering-plugin/commit/b2906906555810fca176fa4e0153bf080446c486))
+
 ## [2.40.2](https://github.com/EveryInc/compound-engineering-plugin/compare/v2.40.1...v2.40.2) (2026-03-17)
 
 

package/docs/specs/codex.md

@@ -48,7 +48,9 @@ https://developers.openai.com/codex/mcp
 - `SKILL.md` uses YAML front matter and requires `name` and `description`. citeturn3view3turn3view4
 - Required fields are single-line with length limits (name ≤ 100 chars, description ≤ 500 chars). citeturn3view4
 - At startup, Codex loads only each skill’s name/description; full content is injected when invoked. citeturn3view3turn3view4
-- Skills can be repo-scoped in `.codex/skills/` or user-scoped in `~/.codex/skills/`. citeturn3view4
+- Skills can be repo-scoped in `.agents/skills/` and are discovered from the current working directory up to the repository root. User-scoped skills live in `~/.agents/skills/`. citeturn1view1turn1view4
+- Inference: some existing tooling and user setups still use `.codex/skills/` and `~/.codex/skills/` as legacy compatibility paths, but those locations are not documented in the current OpenAI Codex skills docs linked above.
+- Codex also supports admin-scoped skills in `/etc/codex/skills` plus built-in system skills bundled with Codex. citeturn1view4
 - Skills can be invoked explicitly using `/skills` or `$skill-name`. citeturn3view3
 
 ## MCP (Model Context Protocol)

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@every-env/compound-plugin",
-  "version": "2.40.2",
+  "version": "2.40.3",
   "type": "module",
   "private": false,
   "bin": {

package/plugins/compound-engineering/AGENTS.md

@@ -93,6 +93,18 @@ This plugin is authored once, then converted for other agent platforms. Commands
 - [ ] When one skill refers to another skill, prefer semantic wording such as "load the `document-review` skill" rather than slash syntax.
 - [ ] Use slash syntax only when referring to an actual published command or workflow such as `/ce:work` or `/deepen-plan`.
 
+### Tool Selection in Agents and Skills
+
+Agents and skills that explore codebases must prefer native tools over shell commands.
+
+Why: shell-heavy exploration causes avoidable permission prompts in sub-agent workflows; native file-search, content-search, and file-read tools avoid that.
+
+- [ ] Never instruct agents to use `find`, `ls`, `cat`, `head`, `tail`, `grep`, `rg`, `wc`, or `tree` through a shell for routine file discovery, content search, or file reading
+- [ ] Describe tools by capability class with platform hints — e.g., "Use the native file-search/glob tool (e.g., Glob in Claude Code)" — not by Claude Code-specific tool names alone
+- [ ] When shell is the only option (e.g., `ast-grep`, `bundle show`, git commands), instruct one simple command at a time — no chaining (`&&`, `||`, `;`), pipes, or redirects
+- [ ] Do not encode shell recipes for routine exploration when native tools can do the job; encode intent and preferred tool classes instead
+- [ ] For shell-only workflows (e.g., `gh`, `git`, `bundle show`, project CLIs), explicit command examples are acceptable when they are simple, task-scoped, and not chained together
+
 ### Quick Validation Command
 
 ```bash

package/plugins/compound-engineering/agents/research/best-practices-researcher.md

@@ -30,9 +30,12 @@ You are an expert technology researcher specializing in discovering, analyzing,
 Before going online, check if curated knowledge already exists in skills:
 
 1. **Discover Available Skills**:
-   - Use Glob to find all SKILL.md files: `**/**/SKILL.md` and `~/.claude/skills/**/SKILL.md`
-   - Also check project-level skills: `.claude/skills/**/SKILL.md`
-   - Read the skill descriptions to understand what each covers
+   - Use the platform's native file-search/glob capability to find `SKILL.md` files in the active skill locations
+   - For maximum compatibility, check project/workspace skill directories in `.claude/skills/**/SKILL.md`, `.codex/skills/**/SKILL.md`, and `.agents/skills/**/SKILL.md`
+   - Also check user/home skill directories in `~/.claude/skills/**/SKILL.md`, `~/.codex/skills/**/SKILL.md`, and `~/.agents/skills/**/SKILL.md`
+   - In Codex environments, `.agents/skills/` may be discovered from the current working directory upward to the repository root, not only from a single fixed repo root location
+   - If the current environment provides an `AGENTS.md` skill inventory (as Codex often does), use that list as the initial discovery index, then open only the relevant `SKILL.md` files
+   - Use the platform's native file-read capability to examine skill descriptions and understand what each covers
 
 2. **Identify Relevant Skills**:
    Match the research topic to available skills. Common mappings:
@@ -123,4 +126,6 @@ Always cite your sources and indicate the authority level:
 
 If you encounter conflicting advice, present the different viewpoints and explain the trade-offs.
 
+**Tool Selection:** Use native file-search/glob (e.g., `Glob`), content-search (e.g., `Grep`), and file-read (e.g., `Read`) tools for repository exploration. Only use shell for commands with no native equivalent (e.g., `bundle show`), one command at a time.
+
 Your research should be thorough but focused on practical application. The goal is to help users implement best practices confidently, not to overwhelm them with every possible approach.

package/plugins/compound-engineering/agents/research/framework-docs-researcher.md

@@ -103,4 +103,6 @@ Structure your findings as:
 6. **Common Issues**: Known problems and their solutions
 7. **References**: Links to documentation, GitHub issues, and source files
 
+**Tool Selection:** Use native file-search/glob (e.g., `Glob`), content-search (e.g., `Grep`), and file-read (e.g., `Read`) tools for repository exploration. Only use shell for commands with no native equivalent (e.g., `bundle show`), one command at a time.
+
 Remember: You are the bridge between complex documentation and practical implementation. Your goal is to provide developers with exactly what they need to implement features correctly and efficiently, following established best practices for their specific framework versions.

package/plugins/compound-engineering/agents/research/git-history-analyzer.md

@@ -23,17 +23,19 @@ assistant: "Let me use the git-history-analyzer agent to investigate the histori
 
 You are a Git History Analyzer, an expert in archaeological analysis of code repositories. Your specialty is uncovering the hidden stories within git history, tracing code evolution, and identifying patterns that inform current development decisions.
 
+**Tool Selection:** Use native file-search/glob (e.g., `Glob`), content-search (e.g., `Grep`), and file-read (e.g., `Read`) tools for all non-git exploration. Use shell only for git commands, one command per call.
+
 Your core responsibilities:
 
-1. **File Evolution Analysis**: For each file of interest, execute `git log --follow --oneline -20` to trace its recent history. Identify major refactorings, renames, and significant changes.
+1. **File Evolution Analysis**: Run `git log --follow --oneline -20 <file>` to trace recent history. Identify major refactorings, renames, and significant changes.
 
-2. **Code Origin Tracing**: Use `git blame -w -C -C -C` to trace the origins of specific code sections, ignoring whitespace changes and following code movement across files.
+2. **Code Origin Tracing**: Run `git blame -w -C -C -C <file>` to trace the origins of specific code sections, ignoring whitespace changes and following code movement across files.
 
-3. **Pattern Recognition**: Analyze commit messages using `git log --grep` to identify recurring themes, issue patterns, and development practices. Look for keywords like 'fix', 'bug', 'refactor', 'performance', etc.
+3. **Pattern Recognition**: Run `git log --grep=<keyword> --oneline` to identify recurring themes, issue patterns, and development practices.
 
-4. **Contributor Mapping**: Execute `git shortlog -sn --` to identify key contributors and their relative involvement. Cross-reference with specific file changes to map expertise domains.
+4. **Contributor Mapping**: Run `git shortlog -sn -- <path>` to identify key contributors and their relative involvement.
 
-5. **Historical Pattern Extraction**: Use `git log -S"pattern" --oneline` to find when specific code patterns were introduced or removed, understanding the context of their implementation.
+5. **Historical Pattern Extraction**: Run `git log -S"pattern" --oneline` to find when specific code patterns were introduced or removed.
 
 Your analysis methodology:
 - Start with a broad view of file history before diving into specifics

package/plugins/compound-engineering/agents/research/repo-research-analyst.md

@@ -56,8 +56,10 @@ You are an expert repository research analyst specializing in understanding code
    - Analyze template structure and required fields
 
 5. **Codebase Pattern Search**
-   - Use `ast-grep` for syntax-aware pattern matching when available
-   - Fall back to `rg` for text-based searches when appropriate
+   - Use the native content-search tool for text and regex pattern searches
+   - Use the native file-search/glob tool to discover files by name or extension
+   - Use the native file-read tool to examine file contents
+   - Use `ast-grep` via shell when syntax-aware pattern matching is needed
    - Identify common implementation patterns
    - Document naming conventions and code organization
 
@@ -115,14 +117,7 @@ Structure your findings as:
 - Flag any contradictions or outdated information
 - Provide specific file paths and examples to support findings
 
-**Search Strategies:**
-
-Use the built-in tools for efficient searching:
-- **Grep tool**: For text/code pattern searches with regex support (uses ripgrep under the hood)
-- **Glob tool**: For file discovery by pattern (e.g., `**/*.md`, `**/CLAUDE.md`)
-- **Read tool**: For reading file contents once located
-- For AST-based code patterns: `ast-grep --lang ruby -p 'pattern'` or `ast-grep --lang typescript -p 'pattern'`
-- Check multiple variations of common file names
+**Tool Selection:** Use native file-search/glob (e.g., `Glob`), content-search (e.g., `Grep`), and file-read (e.g., `Read`) tools for repository exploration. Only use shell for commands with no native equivalent (e.g., `ast-grep`), one command at a time.
 
 **Important Considerations:**