Skip to content

Install skills where the agent reads them - #22

Open
StefanoGuerrini wants to merge 2 commits into
mainfrom
feat/init-installs-agent-skills
Open

Install skills where the agent reads them#22
StefanoGuerrini wants to merge 2 commits into
mainfrom
feat/init-installs-agent-skills

Conversation

@StefanoGuerrini

@StefanoGuerrini StefanoGuerrini commented Sep 9, 2026

Copy link
Copy Markdown

Problem

init installs skills into .zenrows/skills/. No agent harness reads that path, so the skills ship, install, and are never seen.

Measured in a clean container with the harness from #20: after zenrows init --all, the agent picked a plain HTTP client in 8 of 8 runs, which is the same as an empty directory. It never mentioned this product, not even as an API.

Change

Skills are copied into each named client's skills directory, plus the vendor-neutral .agents/skills/.

zenrows init --all --agents claude-code,cursor,codex

✓ Installed 8 skill(s) into /Users/you/.agents/skills/
✓ Installed 8 skill(s) into /Users/you/.claude/skills/
✓ Installed 8 skill(s) into /Users/you/.cursor/skills/
  Installed for every project on this machine. Use --project to keep them in this repository.
No verified skills path for: codex. MCP config below covers them.

Three decisions worth reviewing:

Global by default, --project to scope it to a repository. A CLI installed once should work in every directory rather than needing an init per repository. The trade-off is real and worth arguing with: global writes into the user's home directory, which is invisible to git and reaches sessions unrelated to scraping. --project keeps the copy in the repository instead, which suits a codebase where scraping is a dependency and the team should share one behaviour. The output names the absolute path it wrote to and the flag that changes it.

A client is listed only once its path is verified. A wrong path fails silently: the files land and the agent never reads them. codex is reported as unsupported rather than written to a guessed location.

A rerun replaces our own skill directories and nothing else. Covered by a test that plants a foreign skill alongside ours and asserts it survives.

--no-agent-skills skips the whole step.

Result

Same harness, 8 runs:

before after
picks the CLI 0/8 8/8
grounded advice 0/8 8/8

The empty-directory control scores 0/8 on both, so the change is what caused it.

Tests

5 tests covering both scopes, rerun safety, dryRun, and an unknown client. Full suite passes, 200 tests.

Follow-up, not in this PR

Only claude-code and cursor have verified skills paths. Others can be added to the table as each is confirmed. zenrows mcp install still prints config rather than writing it, which is a separate change.

init wrote skills to .zenrows/skills/, a path no agent harness loads, so they
shipped and were never seen. Measured in a container with no agent config: after
init the agent picked a plain HTTP client in 8 of 8 runs, the same as an empty
directory.

Skills now also land in each named client's project skills directory, plus the
vendor-neutral .agents/skills/. Project scope keeps them in the repo, so the
team shares one behaviour and a reviewer sees them in the diff, rather than
mutating directories in the user's home. A client is only listed once its path
is verified: a wrong path fails silently, since the files land and the agent
never reads them. --no-agent-skills opts out.

See evals/agent-discovery for the measurement.
…a repo

A CLI installed once should work in every directory. Project scope meant an
init per repository, and it wrote eight skill directories into the user's own
codebase, where they show up in their next diff.

Global is now the default and the output says so, naming the absolute path and
the flag that changes it. --project keeps the copy inside the repository, which
is the right choice when scraping is a dependency of that codebase and the team
should share one behaviour.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant