Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add bearlike/Grove --skill configuring-grovegit clone --depth 1 https://github.com/bearlike/GroveWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/bearlike/grove/configuring-grove)<a href="https://agentmods.dev/skills/bearlike/grove/configuring-grove"><img src="https://agentmods.dev/badge/skills/bearlike/grove/configuring-grove/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/bearlike/grove/configuring-grove"><img src="https://agentmods.dev/badge/skills/bearlike/grove/configuring-grove.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00092 | $0.07582 |
| Opus 5.5 | $0.00037 | $0.03033 |
| Sonnet 5.5 | $0.00018 | $0.01516 |
| Haiku 4.5 | $0.00009 | $0.00758 |
Grade B, and why
configuring-grove scanned grade B with 1 finding against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 21d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Reads agent configuration directoriesmediumAgent snooping
.claude/, .codex/, .gemini/ hold keys, settings and other credentials a mod has no legitimate need for.
- **Codex** reads `~/.codex/config.toml` (global, so it already applies to How it starts
The opening of the file, as written. The whole thing — 558 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Configuring Grove
Grove is a software factory for coding agents. Each Grove workspace is one git worktree plus one tmux session running an agent, scoped to the repository it is launched from. This skill helps you configure Grove correctly for a user, both at the host/user level and per project.
Your job: find out what the user wants, decide which config layer it belongs in, write valid JSON, and verify it against the version of Grove they actually have installed. Do not guess. Grove validates strictly and rejects unknown keys, so a wrong field is a hard error, not a silent no-op.
What people use this for
Common requests, and how to handle them:
- "Set this repo up so every workspace is ready to code." Configure a project
init_script(committed in<repo>/.grove/config.json) that installs dependencies and prepares the tree, for exampleuv sync,npm ci, ormake bootstrap. It runs in its own tmux window before the agent starts. - "Handle my secrets properly." Never put secret values in the committed
project config; it is meant to be shared. Reference environment variables
instead (the user sets them in their shell or a gitignored
.env), keep machine-specific values in the gitignored project-local config (<repo>/.grove/config.local.json), and let the init script wire secrets up, for examplecp .env.example .env.agents[].envand init scripts can read env vars; keep the literal secrets out of anything committed. - "Make test, deploy, or scratch directories for each workspace." Put the
mkdir, fixture seeding, mock-data setup, or deploy scaffolding in theinit_script, so every new worktree starts in the right shape. - "Bring my MCP servers into each workspace." A Grove workspace is a real git
worktree, so any file committed at the repo root is already present inside it.
- Claude Code reads project MCP servers from a committed
.mcp.jsonat the repo root, so committing that file gives every workspace and teammate the same servers. Reference secret tokens via env vars there; do not hardcode them. - Codex reads
~/.codex/config.toml(global, so it already applies to every workspace) or a project.codex/config.tomlwith[mcp_servers.<name>]tables. Commit the project file, or have the init script copy or symlink the user's config into the new worktree. - For any MCP config that is gitignored or lives only in the home directory, the init script is the place to copy or symlink it into the workspace.
- Claude Code reads project MCP servers from a committed
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 21d ago Changed e75d7b7600a8
- 1mo ago Changed · -1 lines 56437d71071a
- 1mo ago Changed · +51 lines · -30 tokens per session 9dd11e0f0c83
- 1mo ago First seen · 508 lines · 122 tokens per session scan B 1a3c1bb077ff
configuring-grove is a skill published in the GitHub repository bearlike/Grove (9 stars, last pushed 21d ago), licensed MIT. It adds 92 tokens to every session and 7,582 once invoked, about $0.0004 per session on Opus 5.5. A static security scan graded it B with 1 finding (reads agent configuration directories). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
hunk-launch-video
Produces Hunk videos by driving the real TUI headlessly in a PTY, compositing captioned 1080p frames in Chromium, and encoding with ffmpeg. Use for feature demos, workflow explainers, announcements, launch videos, and full-release roundups.
repo-guidance
Navigate the Composio SDK monorepo, branch and PR workflow, repo layout, generated-file boundaries, changesets, and shared maintenance rules. Use when work spans multiple packages, when deciding where code belongs, when preparing a PR, or when the user asks about repository conventions rather than a specific SDK…
python-release
Handle Python SDK release, build, bump, packaging metadata, PyPI client pin, uv.lock, nox/build workflow, and publish verification changes. Use for Python release process work or dependency pin bumps; do not use for ordinary Python feature implementation.
storage-retention
Inspect machine storage, clean up files, and configure automatic thread archive or deletion.
thread-list
Inspect or change the sidebar thread list's layout preferences: organization mode, sort, section order, hidden groups, collapsed groups, and thread row actions.
automations
Schedule or manage recurring and one-shot BB agent or script automations.