Add AI assistant skill installation

[strangesource]

Summary

• add local Bitmovin CLI skill installation via bitmovin init and legacy bitmovin skill output
• add bitmovin skills list/find/add/remove for remote Bitmovin skills
• discover remote skills from the bitmovin/skills GitHub archive via skills/*/SKILL.md
• add archive/path validation and tests for skill installation flows

Verification

• npm run build
• npm test
• npm run lint
• packed and installed the CLI tarball into a temp project, then verified bitmovin skill, bitmovin init, skills list, skills find, and skills add --dry-run

[lukaskroepfl]

A few directional points before this lands:

1. Rename bitmovin init. init is a heavily overloaded verb (project init, config init, local infra setup). Today the command does one narrow thing — write a SKILL.md into agent skill directories. A user running bitmovin init in a fresh checkout will reasonably expect "set up local state for the CLI", not "install AI assistant files into ~/.claude/skills". Options: bitmovin skills install, bitmovin skills install-cli, or fold it into bitmovin skills add with a --cli/default-target behavior. The top-level init slot is hard to walk back later.

2. Drop the dedicated CLI skill; make the canonical install be the hub skill from bitmovin/skills (the bitmovin.com/skill hub). The skills/bitmovin-cli/SKILL.md in this PR is essentially a hand-curated --help dump. oclif already exposes that surface (bitmovin <topic> --help, help topics, generated README) and agents can navigate it on their own. That makes the CLI skill duplicate-maintenance — every flag added has to be re-written into the markdown, and it'll drift. Genuine question rather than a hard claim: do you have evidence that agents struggle with oclif's help output and specifically need the hand-written cheat sheet? If not, the higher-leverage thing to install is the hub skill that points agents at the CLI + API docs + player/analytics SDKs together. Naming-wise that also resolves the bitmovin skill vs bitmovin skills add --skill bitmovin mismatch — they'd refer to the same thing.

3. Reuse the existing npx skills flow for add/search/remove instead of reimplementing it. We already have npx skills for skill discovery/install. Building a parallel pipeline here (tar dep, archive download, validation, install/remove) duplicates that work and gives us two installers to keep in sync. Could bitmovin skills add/find/list/remove shell out to npx skills … and inherit it? If yes, the CLI's contribution shrinks to "know which Bitmovin skills exist and delegate", and we drop ~600 lines plus the tar dep plus the Node 18→20 engine bump.

Net effect if all three land: bitmovin init → renamed; default install target → hub skill; add/find/remove → thin wrappers over npx skills. The PR shrinks meaningfully and avoids inventing infrastructure that exists elsewhere.

[strangesource]

Thanks for the thoughtful review — I agree with point 2 that the dedicated CLI skill risks becoming duplicate-maintenance if it remains a hand-curated help dump.

One bit of context: this CLI skill was already present before this PR as the hidden bitmovin skill command with the markdown embedded directly in TypeScript. In this PR I mostly moved that existing content into skills/bitmovin-cli/SKILL.md, which felt like a more convenient and packageable place for the same pattern, and then wired bitmovin init to install it.

Given your point, should we remove the dedicated CLI skill entirely instead of preserving/moving the existing behavior?