The /neurometric skill assumes a Neurometric platform API with endpoints that don't exist on api.neurometric.ai. Three of the skill's subcommands fail with HTTP 404:
/neurometric status → GET /v1/status → 404/neurometric replay → GET /v1/captures → 404/neurometric optimize --captures → GET /v1/captures → 404
Evidence
The gateway's own OpenAPI spec at https://api.neurometric.ai/openapi.json lists exactly these paths:
/health/models/v1/chat/completions/v1/models
No status, captures, sessions, or analytics endpoints exist on this host. I also confirmed:
studio.neurometric.ai/api/v1/* → 307 redirect to WorkOS sign-in (browser cookie auth via AuthKit, not bearer-token consumable)platform.neurometric.ai, app.neurometric.ai → DNS NXDOMAIN- The public API docs page at
studio.neurometric.ai/docs only documents /v1/chat/completions as the programmatic API surface
Reproduction
export NEUROMETRIC_API_KEY=sk_live_...
curl -sS -o /dev/null -w "%{http_code}\n" \
-H "Authorization: Bearer $NEUROMETRIC_API_KEY" \
https://api.neurometric.ai/v1/status
# 404
curl -sS -o /dev/null -w "%{http_code}\n" \
-H "Authorization: Bearer $NEUROMETRIC_API_KEY" \
https://api.neurometric.ai/v1/captures
# 404Or, in a Claude Code session with the plugin installed:
/neurometric:neurometric status
…returns a "Connection Failed" panel with Endpoint: /v1/status returned HTTP 404.
User-facing impact
3 of the 5 skill subcommands are broken as shipped. The skill surfaces the raw HTTP 404, which gives the user no actionable information about what's wrong or how to fix it.
Suggested direction (not prescriptive)
status could hit GET /v1/models with the bearer key — that endpoint exists, requires auth (returns 401 without, would return 200 with a valid key), and costs no tokens. It's a real "is my routing working" check.replay / optimize --captures depend on a captures API that doesn't appear to exist publicly. Options: remove them, or rewrite them to direct users to the studio dashboard at https://studio.neurometric.ai where captures actually live.
Happy to send a PR if that direction is acceptable — wanted to flag the issue first so you can confirm intent.
Related: #1 (separate, packaging-only PR I just opened).
The
/neurometricskill assumes a Neurometric platform API with endpoints that don't exist onapi.neurometric.ai. Three of the skill's subcommands fail with HTTP 404:/neurometric status→GET /v1/status→ 404/neurometric replay→GET /v1/captures→ 404/neurometric optimize --captures→GET /v1/captures→ 404Evidence
The gateway's own OpenAPI spec at https://api.neurometric.ai/openapi.json lists exactly these paths:
/health/models/v1/chat/completions/v1/modelsNo
status,captures,sessions, or analytics endpoints exist on this host. I also confirmed:studio.neurometric.ai/api/v1/*→ 307 redirect to WorkOS sign-in (browser cookie auth via AuthKit, not bearer-token consumable)platform.neurometric.ai,app.neurometric.ai→ DNS NXDOMAINstudio.neurometric.ai/docsonly documents/v1/chat/completionsas the programmatic API surfaceReproduction
Or, in a Claude Code session with the plugin installed:
…returns a "Connection Failed" panel with
Endpoint: /v1/status returned HTTP 404.User-facing impact
3 of the 5 skill subcommands are broken as shipped. The skill surfaces the raw HTTP 404, which gives the user no actionable information about what's wrong or how to fix it.
Suggested direction (not prescriptive)
statuscould hitGET /v1/modelswith the bearer key — that endpoint exists, requires auth (returns 401 without, would return 200 with a valid key), and costs no tokens. It's a real "is my routing working" check.replay/optimize --capturesdepend on a captures API that doesn't appear to exist publicly. Options: remove them, or rewrite them to direct users to the studio dashboard at https://studio.neurometric.ai where captures actually live.Happy to send a PR if that direction is acceptable — wanted to flag the issue first so you can confirm intent.
Related: #1 (separate, packaging-only PR I just opened).