[Feature] nyxid skill install — local install for limited-access Ornn skills via NyxID CLI

[chronoai-shining]

Background

Ornn is rolling out a public-skill mirror to ChronoAIProject/ornn-skills on GitHub so any user can install public / system skills via the community-standard CLI: npx skills add ChronoAIProject/ornn-skills/<name> (tracked in ChronoAIProject/Ornn).

That mirror does not include limited-access skills — anything that's private or shared with specific users / orgs stays Ornn-side. Reason: npx skills works by git clone and assumes anonymous access; mapping NyxID identity into GitHub collaborator ACLs would require linking every NyxID user to a GitHub username and reflecting ACL changes via the GitHub API in real time. That's a brittle two-system identity dance with poor revocation semantics.

The clean path is to keep the limited-access fetch on Ornn's API (already gated by NyxID's identity proxy and the per-skill ACL list), and expose it through a one-line CLI command in nyxid so the agent UX stays "one command, one skill installed."

Goal

Ship nyxid skill install <name> (and minimally list / remove / update for symmetry with npx skills) so a NyxID user can pull any Ornn skill they have access to — public, system, OR limited — into their local agent skills directory with one command. Same UX shape as npx skills, but riding NyxID identity.

# After `nyxid login`, agent runtime auto-detected:
nyxid skill install my-private-fetcher
# → calls ornn-api /api/v1/skills/my-private-fetcher/json via the NyxID proxy
# → writes the SKILL.md + references/ + scripts/ to ~/.claude/skills/my-private-fetcher/
# → records in ~/.ornn/installed-skills.json so the agent's manual knows it's installed

Scope

Subcommand: nyxid skill install <name>

Internally:

1. Resolve target agent runtime's skills dir (auto-detect; fallback to flag override): Claude Code → ~/.claude/skills/, Codex CLI → ~/.codex/skills/ (where applicable), Cursor → workspace .cursor/rules/, project-local fallback ./skills/.
2. nyxid proxy request ornn-api /api/v1/skills/<name>/json to fetch the canonical payload { name, description, metadata, files: { "SKILL.md": "...", "references/...": "...", "scripts/...": "..." } } (this endpoint already exists; tracked in ornn-agent-manual-cli §1).
3. Write each files[path] entry to <skills-dir>/<name>/<path>, preserving the directory structure.
4. Append a record to ~/.ornn/installed-skills.json per the agent-manual contract: { name, ornnGuid, installedVersion, installedAt, localPath }. If the skill is already in the registry, bump installedVersion + installedAt in place.

Symmetric operations

• nyxid skill list — walk ~/.ornn/installed-skills.json, render a table (name + version + last installed at)
• nyxid skill remove <name> — delete <skills-dir>/<name>/ and remove the registry entry
• nyxid skill check / update <name> — compare installedVersion against Ornn's latest; pull if newer
• nyxid skill find <query> — proxy to Ornn's /api/v1/skill-search with the caller's identity, so private / shared skills the user has access to also surface

Out of scope for this issue

• Authoring / publishing flow (nyxid skill create / publish) — keep that on the agent manual + Ornn web UI for now
• Multi-skill bulk install (nyxid skill install ornn-org/<org-id> to pull every skill shared with my org) — useful, but defer until basic install lands

Why a NyxID CLI command (not Ornn's CLI)

Ornn doesn't have a CLI today (Phase 2 roadmap). NyxID does, and it already handles the auth + token-refresh lifecycle. Riding nyxid skill * means:

• Zero new auth surface — reuses the existing nyxid login session
• One CLI for users to install (no ornn binary to add)
• Token refresh is already battle-tested in nyxid proxy request

When Ornn eventually ships its own CLI, nyxid skill * and ornn skill * can coexist or one can wrap the other; the API contract (/api/v1/skills/:name/json) doesn't care which CLI is calling it.

Implementation hints

• Reuse nyxid proxy request <service> <path> plumbing — it's the same call, just wrapped with file writes
• Agent runtime detection: probe well-known directories at startup; document the override flag (--target ~/.claude/skills) for cases where probing fails
• Cross-platform: macOS / Linux / Windows path conventions; today's nyxid already handles this for the config dir
• Error mapping: surface Ornn's error codes into actionable messages — SKILL_NOT_FOUND → "skill 'X' doesn't exist or you don't have access. Try nyxid skill find X."; AUTH_MISSING → "session expired, run nyxid login."

Acceptance criteria

• nyxid skill install <public-skill-name> works against a fresh nyxid login session and lands the skill in the right directory for the auto-detected agent runtime.
• nyxid skill install <skill-shared-with-me> works for a skill the caller has via direct sharedWithUsers grant — and rejects with a clear error for a skill the caller cannot see.
• nyxid skill install <skill-shared-with-my-org> works for any skill shared with an org the caller is admin or member of (uses NyxID's existing org-resolve middleware on the Ornn side, no NyxID-CLI changes needed).
• ~/.ornn/installed-skills.json is created if missing and updated idempotently on repeat installs of the same skill (bumps version + timestamp, no duplicates).
• Symmetric list / remove / update commands round-trip cleanly: install → list shows it → update bumps to latest → remove deletes the local copy and the registry entry.
• All commands exit with sensible non-zero codes on failure and print actionable messages mapping Ornn error codes to user-facing remediation.

Companion

• ChronoAIProject/Ornn — [Feature] Auto-mirror public + system skills to ChronoAIProject/ornn-skills GitHub repo — the public-skill side of this story. Together they form the unified install UX:

  • Public / system skills → npx skills add ChronoAIProject/ornn-skills/<name> (anonymous, GitHub-cloned)
  • Limited-access skills → nyxid skill install <name> (NyxID-authed, Ornn-fetched)

  Two paths because they reflect two genuinely-different permission models. Each path is one line — no UX regression.

[chronoai-bot]

github-devloop intake decision: enable
Service class: standard

Reason:
Implementation request for nyxid skill install <name> and related CLI operations; established CLI best practice favors reusing existing auth/proxy plumbing and idempotent local installs, with no human-gate, umbrella, or recurring-instance basis.

[chronoai-bot]

github-devloop thinking: consensus started

[chronoai-bot]

github-devloop convergence round 0 - no three-angle consensus; narrowing

Narrowed question: Narrow to an authenticated private-skill installer for nyxid skill install <name> with explicit target selection, normalized confined files[path], manifest/version/integrity validation, atomic install/rollback and overwrite rules, plus per-target ownership metadata; defer list / remove / update / find, public-skill handling, and multi-runtime autodetect until that contract is proven.

Angle stances:

• minimal: abstain — Established practice for package/plugin installers is to start with a narrow authenticated fetch/install path and treat local filesystem writes as a supply-chain boundary requiring path normalization, atomic writes, manifest/version validation, and rollback; the core nyxid skill install <name> is directionally justified for limited-access ACL-backed skills, but minimal approval is blocked by unproven extra scope (list/remove/update/find, multi-runtime detection, public-skill handling) and missing install-safety requirements such as rejecting ../ or absolute paths, defining overwrit
• structural: abstain — Established plugin/package-manager practice is an authenticated registry contract with explicit target selection, constrained path extraction, atomic writes, versioned metadata, and unambiguous uninstall ownership; the proposal has the right high-level boundary by keeping limited-access authorization in Ornn/NyxID instead of mirroring ACLs into GitHub, but it is not structurally ready because nyxid skill install <name> auto-detects multiple runtimes while recording a single ~/.ornn/installed-skills.json entry keyed by name, leaving unclear ownership for list / remove / update and n
• delete: abstain — Established practice for private plugin/package distribution is to use an authenticated registry/installer with explicit target selection, manifest validation, integrity/version metadata, path traversal defense, and transactional install/remove; this proposal justifies not mapping NyxID users into GitHub ACLs, but it overreaches from nyxid skill install <name> into list / remove / update / find and underspecifies the risky core write path, especially validating files[path], atomic rollback, version pinning/integrity, and whether auto-detecting Claude/Codex/Cursor destinations can w

⟦AI:FKST⟧

[chronoai-bot]

github-devloop convergence round 0 - no three-angle consensus; narrowing

Narrowed question: Reframe #613 to a hardened MVP for only nyxid skill install <name> over existing NyxID proxy auth, with explicit target selection, manifest/schema/version validation, path normalization plus traversal/symlink/overwrite boundaries, atomic install/rollback, idempotent ~/.ornn/installed-skills.json updates, and clear failure codes; defer list/remove/update/find, broad runtime auto-detection, and registry/org-sharing expansion.

Angle stances:

• minimal: abstain — Established practice for authenticated plugin/package installers is a narrow, idempotent install path over existing auth, with explicit target resolution, manifest/path validation, atomic writes, and clear failure codes; this proposal justifies not using npx skills for limited-access skills, but the requested scope expands beyond the smallest viable change into list, remove, update, find, multi-runtime auto-detection, registry semantics, and org-sharing acceptance without proof those are needed for the first release. I would approve a scoped MVP limited to `nyxid skill install
• structural: abstain — Established plugin/package-installer practice requires a narrow registry contract, validated manifests, atomic/idempotent writes, and strict filesystem boundary checks; the proposal has a good boundary between NyxID auth/proxy and Ornn as skill authority, but it still defines files[path] as directly written to local skill directories without explicit path normalization, traversal/symlink protection, schema/version validation, or transactional rollback, so the structural contract is not yet maintainable enough to approve.
• delete: abstain — Established practice for authenticated plugin/package installers is to minimize package-manager surface and require safe extraction, path validation, atomic installs, and integrity/version guarantees; this proposal expands nyxid into skill install/list/remove/update/find and writes arbitrary files[path] from Ornn JSON into local agent directories without acceptance criteria for traversal prevention, overwrite policy, signatures/checksums, or atomic rollback, so the install scope should be narrowed to a hardened minimal nyxid skill install <name> path before approval.

⟦AI:FKST⟧

[chronoai-bot]

github-devloop timeout redrive attempt: thinking 1

⟦AI:FKST⟧