Goose Skills: the README installs a command the package does not declare

The README installs a command the package does not declare

Every installation route in the document runs npx gooseworks. There is a login command, a search command, a credits command and an update command, all prefixed the same way, and the manual install line is npx gooseworks install --all.

The package manifest names something else. The npm package is goose-skills at version 1.0.1, and its single binary is declared as goose-skills pointing at ./bin/goose-skills.js. The description field inside that manifest also tells you to install with npx goose-skills install <slug>.

So there are two executable names in play, and they are not the same. The README's own build-from-source instructions use the declared one, running node bin/goose-skills.js list, while every user-facing command uses the other.

Neither the README nor the manifest explains the relationship, and there is no alias or bin mapping in the manifest to account for it. A reader who trusts the manifest gets a different command than a reader who trusts the README, and a reader who pastes the setup prompt into their agent gets the README's version.

The manifest points its repository field at a different owner

The repository block in the package manifest declares a URL under an account called athina-ai, while the repository hosting this document is gooseworks-ai/goose-skills.

The README's own build-from-source section clones the gooseworks-ai address, so the two halves of the same project disagree about where the code lives. The author field names Athina AI, and the licence field says MIT, which matches the repository.

Three plausible explanations exist and the material settles none of them. The project may have moved accounts and the manifest was not updated. It may be a fork, a rebrand or an internal package published from a different organisation. Or the manifest may describe an earlier state of the same work.

What matters practically is that a package manager will use the repository field for provenance links, and a security reviewer checking where the code came from will find a different organisation than the one hosting the code they just read. The README's contents list does promise a Security and Trust section, which is where that question belongs, and the document cuts off before reaching it.

Installing grants your agent the ability to fetch two hundred more

The install command is npx gooseworks install --all, annotated as applying to all detected agents. So the installer looks at your machine, finds the coding agents it recognises, and writes the skills into them.

npx gooseworks install --all       # All detected agents

What it writes is not the whole catalogue. The README says the install gives your agent access to the full catalog of 200 or more skills, and that afterwards you ask your agent to use a skill by name, at which point the agent searches the GooseWorks catalog, downloads the skill and runs it automatically.

So the installed artefact is a thin entry point plus the ability to pull and execute instruction sets on demand from a hosted catalogue. That is the normal shape for a skills marketplace, and it is also the part a security review has to look at hardest, because what runs later was not present when you consented.

There is also a credit system attached. One of the three documented commands is a balance check, and a hosted product is offered for people who would rather not run the skills locally at all.

Every skill directory has to declare its own install command

There is a documented metadata contract, and it is stricter than most skill collections bother with.

Each skill directory must contain a SKILL.md holding the documentation and a skill.meta.json holding machine-readable metadata. Six fields are required. The slug must be a unique kebab-case identifier. The category must be one of three values, capabilities, composites or playbooks. Tags must be a string array. installation.base_command is the install command. installation.supports is an array naming the agents, drawn from claude, codex and cursor. A features field is listed as optional, and the table is cut off part way through describing it.

The base_command field is the one with consequences. Each skill carries the command that installs it, which means the catalogue is not a set of static documents but a set of instructions with an attached install action, and the validator and the build script both exist to keep that pair consistent.

The local workflow makes that explicit: a validation script checks the SKILL.md and skill.meta.json contract, a build script generates skills-index.json, and the binary's list command prints what was found.

The CI script names nine test files by hand

The test script is a single node --test invocation that enumerates nine files, including the brand-growth collection and routes tests, the targets and packs tests, two Meta ads harnesses, the shared video harness, and the unit tests for the build-index and validate-skills scripts.

Every one is named explicitly. A test file added to the repository later does not run until somebody edits that line, which is the standard hazard of an explicit list and the reason most projects move to a glob.

The ci script chains three steps in order: validate the skills, build the index, then run the tests. So the index is regenerated as part of the pipeline, and skills-index.json is also committed at the repository root, meaning the generated artefact and the check for it live in the same tree.

The rest of the scripts are evaluation tooling rather than unit tests: one for the evaluation harness, one to run it, one to check a run, one to generate eval prompts, and one to report.

The dependency list is one entry, the changesets CLI, which is the tool that cuts releases.

Nineteen skills are named out of two hundred

The Brand Growth collection is the only part of the catalogue described in detail, and it is organised as four stages rather than as a package.

Research is the widest, with seven named skills covering brand, audience, comment mining, competitor social research, influencer prospecting, trend discovery and product demand. Analyse has seven, covering competitor ad intelligence, creator profile teardowns, transcript intelligence, a Meta ads analyser, a Meta ad policy checker, an ad to landing page auditor and an outlier post finder. Create has five, covering content repurposing, remixing a graphic ad from a reference, a product photoshoot, brand graphics and animating a still image. The fourth stage has no skill names at all, only the instruction to re-run an analysis skill with current evidence.

Nineteen named skills against a stated two hundred or more. The README is careful to say the collection is not a separate package or command, just a curated path through the normal catalogue.

One data source is named behind several of these workflows: ScrapeCreators, for structured public social and ad-library research, reached by signed-in users through a managed first-party proxy so that no separate key is needed, with the skills returning briefs and shortlists instead of raw API output.

Two entries in the tree have no explanation anywhere

The top level is a JavaScript project with a familiar shape and a few things that are not.

Expected are bin/ for the CLI, skills/ for the catalogue, collections/ for the curated path, schemas/ for the metadata contract, scripts/ for the build and validate tooling, test/ for the harness, tools/, and skills-index.json as the generated index. .changeset/ holds the version-cut configuration, and .claude/ suggests the skills are also developed with an agent in the loop.

One directory is unexplained. skillopt/ sits beside skills/ with no description anywhere in the document, and given the naming it is either an optimiser for skill text or a second source of skills, and neither is documented.

The README's own contents list is also unfinished in practice. It promises sections for the metadata contract, security and trust, and the licence, and the document that reaches a reader stops inside the metadata table, on a features row cut off mid-word.

What survives is still enough to evaluate the project: the install model, the two executable names, the required contract, and the fact that the trust story is where the remaining questions would be answered.

Editorial conclusion

The skill contract here is the part worth stealing, a required metadata file with a declared install command and an explicit list of supported agents, which is more discipline than most skill collections have. What to check before running the setup prompt is which executable the installer actually puts on your machine, because the documented command and the declared binary are different names. If the underlying data APIs matter to you, look at the credits model and the managed proxy first, since several workflows depend on a third-party data source reached through the vendor.

Frequently asked questions

Official sources

1. gooseworks-ai/goose-skills on GitHub
2. Issues
3. License: MIT
4. Project website
5. README