Repository navigation
v3.14.4
What's new
Bug Fixes
Five bundled skills invoked helper scripts with bare relative paths — things like bash references/resolve-base.sh — which a shell resolves against the working directory (the user's project) rather than the directory the skill was actually installed into. These invocations could never work, in any repository, including this one. Each call now resolves through a SKILL_DIR variable set from the directory the harness reports when the skill loads, with every fenced block setting the variable itself since blocks are copied and run independently. A follow-up fix closed a related gap where some hosts flatten a fenced block into a single line: an unterminated SKILL_DIR="..." assignment then collapses into the env-var-prefix form, causing the shell to expand the variable from the outer scope before the assignment takes effect and reproducing the same broken path by a different route. All twenty anchors now terminate correctly, and a new test covers the four properties these invocations depend on (#862).
A persona that omits the tools frontmatter field is not equally restricted across harnesses: on Pi it resolves to a read-only set (read, grep, find, ls), but on OpenCode the same omission means no restriction at all, because the comma-separated string form isn't the map shape OpenCode expects and is silently ignored. Two personas were caught by this divergence with their capabilities backwards relative to their jobs — the PR comment resolver (which is supposed to implement fixes) and the bug reproduction validator (whose entire purpose is running reproductions) both effectively had no working tools declared. Both personas now explicitly declare the tools their instructions already assume. Granting shell access to the validator also required a new untrusted-input rule, since its input is a bug report — text that routinely arrives pasted from an issue tracker or a stranger's terminal — and instructions embedded in that text must never be treated as instructions to the agent (#861).
Documentation
A proposal to add an MCP server to the Claude Code bundle, premised on the bundle having no way to execute anything, was disproven by a local install: the install copies the whole plugin tree rather than only the manifest-declared components, preserves the executable bit, and bin/ reaches the Bash tool's PATH. The real constraint turned out to be packaging, not execution — shipping the existing CLI failed three separate ways (a sibling-chunk import, externalized runtime dependencies with no node_modules to resolve them, and a UMD module with an AMD branch that no bundler can follow). An entry point that imports only the single module the surface needs avoids all three failure modes. The learning captured here: an unshippable dependency may have arrived through entry-point scope rather than through the feature being shipped, and is worth checking before being written off as fatal (#865).
Adding a module under src/lib/ has always carried two registration obligations, but only the ARCHITECTURE.md codemap was documented — the src/lib/AGENTS.md module table is equally required and equally gate-enforced (checkCodemapCompleteness and checkLibModuleTableCompleteness in scripts/content-integrity.ts). The guidance now names both obligations and the verification command, and points the intentional-omission escape hatch at whichever document the exclusion actually belongs to, rather than assuming the codemap (#863).
Also in this release
- deps: update dependency
@biomejs/biometo v2.5.10 (#864)