feat(skills): mark Cursor as a verified host - #20
Conversation
Verified end to end on Cursor 3.14.27 (desktop) and cursor-agent 2026.08.04-aaa8809, using reply-cli 0.5.1: all three packs install to ~/.cursor/skills and all 18 skills reach the model; --project installs to .agents/skills and is read from the open workspace; selective install pulls only ai-sdr-core; a name collision with a user-authored skill is refused rather than overwritten; and remove leaves user-authored skills byte-identical. Skills take effect in a new chat, with no restart. The README support table gains the skills path and the activation step per host. Test expectations follow the flag; no behaviour change.
ArtemKosolap
left a comment
ArtemKosolap
left a comment
There was a problem hiding this comment.
Reviewed the whole change, and independently checked the claims it makes rather than taking them from the description.
The product change is one line — hosts.ts flipping Cursor's verified flag — and it is the right line. What I could confirm from the repository supports it: --agent is a real option (src/commands/skills.ts:100), and Cursor is detected by the presence of ~/.cursor rather than by a binary (src/skills/detect.ts:95, binaries: [] and binary_paths: [] on the Cursor entry), so a plain reply skills install finds it and the flag is only the explicit form. v0.5.1 is a published release, so citing it as the version the verification ran on is not a forward-dated claim. What the repository cannot confirm is the substance of the run itself — that Cursor reads from ~/.cursor/skills — which is exactly what the Paths verified column is for, and the versions are named there to the same standard as the other rows.
One finding worth acting on, in the test that changed, plus three smaller things whose lines are not in the diff.
report.test.ts:116-123 still uses Cursor as its example of an unverified host
The test named marks a host whose paths are not yet verified, and only that host builds its fixture from literals, so it keeps passing — but it now asserts /Cursor .*paths not yet verified/ about a host this PR declares verified. It passes and teaches the opposite of the product.
Fix: swap the fixture host for gemini-cli or windsurf. Same for the test below it, which uses Cursor for the not-detected case.
report.ts:83 names two of the three verified hosts
Install Claude Code or Codex, or pass --agent to name one explicitly. — the line a user sees when nothing was detected. Cursor now belongs in it.
The README's activation column and the CLI's own output disagree
The new To take effect column says start a new chat for Cursor, while the report prints one line for every host: Start a new session in each assistant so the skills load. (report.ts:108). The README is the more precise of the two, so the output is the side worth changing — or the column can say a new session (a new chat in Cursor) and leave the code alone.
Sequencing with the docs change in reply-skills
The companion PR there tells a reader that Cursor is verified and cites reply-cli 0.5.1. That is true of the paths, but the verified: true flag ships in the next release — so between merging that PR and cutting a release from this one, a user on 0.5.1 reads "verified" in one repository and sees Cursor (paths not yet verified) in the CLI's own output. Merging this one and releasing before the docs change lands avoids the window entirely.
Everything else checks out: the host registry test asserts the full verified set rather than a count, --json keeps carrying the flag, and the suite is green on both runners.
Four things the flag change left inconsistent. orchestrate.test.ts had been the only end-to-end proof that an unverified host's warning reaches the report, and with Cursor verified both detected hosts were verified, so the assertion had been inverted to expect no warning at all. The fixture now also detects Gemini CLI, so the test asserts both halves: the flag travels from the registry into a real report, and the warning still surfaces for a host that has not been verified. Gemini CLI is created inside the test rather than in beforeEach, because detecting a third host globally would change the expected host list of every other test in the file. report.test.ts used Cursor as its example of a host whose paths are not verified. The fixture is built from literals so it kept passing, while asserting the opposite of what the product now says. It moves to gemini-cli rather than windsurf, so it stays true when the next host is verified. report.ts named only Claude Code and Codex in the hint printed when no assistant is found; Cursor belongs in it now. The README's activation column said "start a new chat" for Cursor while the CLI prints "Start a new session in each assistant" for every host. The column now leads with the CLI's own term and adds the host-specific one — "a new session (a new chat)" — so the product's wording stays canonical without losing the detail that Cursor calls them chats.
458d000 to
5ac7dcb
Compare
ArtemKosolap
left a comment
ArtemKosolap
left a comment
There was a problem hiding this comment.
Approving. Every follow-up checks out, and I verified the one that mattered rather than reading it: with .gemini back in the fixture, flipping gemini-cli to verified: true in the registry fails this test and only this test — the guard catches the defect it exists for again, where before the fix the same plant passed silently. Full suite green locally too, 174 passed.
The activation column landing on a new session (a new chat) rather than changing the output is the cheaper side of that trade and reads well.
One sequencing note, not a condition: the docs change in reply-skills describes Cursor as verified, and the flag only reaches users with the next release from here. Merging this and cutting the release before that one lands keeps the two repositories saying the same thing to anyone on 0.5.1.
2 participants
No description provided.