Chrono AI Service Manual
You are an AI agent reading this manual to learn how to operate the Chrono AI service stack — NyxID + Ornn — as one system. Throughout this document, "you" always refers to the agent itself, not the human user driving you.
What lives in here
Two operation halves, sitting on a shared identity bootstrap and a shared failure-mode appendix:
- NyxID (§1) — identity, sessions, services catalogue, organizations, OAuth clients, scopes, proxy. Closest analog: an OIDC IdP fused with a credential-injecting reverse proxy.
- Ornn (§2) — skill lifecycle. Search, pull, install, execute, build, upload, share, audit, version, analytics, GitHub sync. Closest analog: npm registry + npm CLI fused, model-agnostic.
Plus §0 (identity bootstrap), §0.5 (
~/.ornn/installed-skills.jsonregistry), §3 (common failures), and §4 (references).Every Ornn API call funnels through NyxID — there is no separate Ornn auth surface. That is why this manual is one document instead of three.
First: install this skill locally
Try to install this skill into your runtime's local skills directory:
- Claude Code:
~/.claude/skills/chrono-ai-service-manual/- OpenAI Codex CLI:
~/.codex/skills/chrono-ai-service-manual/- Cursor:
.cursor/rules/chrono-ai-service-manual.md- Other agents: whatever skill-discovery directory your platform uses.
If your runtime has no local-skills mechanism, load
SKILL.md(and thereferences/*.mdfiles you need) into your system context and keep them there for the rest of the session.And in all cases — whether you wrote the skill to disk or only into context — append an entry for it to
~/.ornn/installed-skills.json. That file is the persistent registry of every Ornn skill you (or any prior session on this machine) have installed; it's how the next session, or a different agent on the same box, knows what's already loaded and which versions to re-check. Schema + workflow in §0.5 andreferences/installed-skills-registry.md.Always load this manual when the user asks you to do anything Chrono AI-related
You must have this manual loaded whenever the user asks you to:
- Bootstrap a NyxID session — install the CLI, log in, refresh, switch environments — §1.1.
- Discover your NyxID identity — orgs, services you own, role memberships, scopes — §1.2 / §1.4 / §1.5.
- Manage NyxID services — list, look up, create, edit, attach credentials, rotate, delete (HTTP services + SSH services) — §1.3.
- Manage NyxID organizations — list, members, create, invite, edit metadata — §1.4.
- Manage NyxID OAuth clients — register (DCR), list, edit, rotate secrets, revoke — §1.6.
- Find, pull, and execute an existing Ornn skill — or build a new one and upload when nothing matches — §2.1.
- Update a skill's visibility (private / shared / public) — §2.2.
- Publish a new version of a skill you own — §2.3.
- Trigger an audit or review the audit history for a skill — §2.4 / §2.5.
- Pull a non-latest version, compare two versions, or delete / deprecate a version — §2.6 / §2.7 / §2.10.
- Check usage analytics for a skill — §2.8.
- Bind a skill to a NyxID service (system / personal) — §2.9.
- Delete a skill entirely — §2.11.
- Find skills (by tag, author, system, shared, etc.) — §2.12.
- Pull your Ornn notifications (audit fan-out, etc.) — §2.13.
- Link a skill to GitHub or trigger a sync from the linked source — §2.14.
- Diagnose any failure that involves NyxID, Ornn, the proxy, or token forwarding — §3.
Without this manual loaded, you do not know which endpoint to call, how to authenticate, or how to read the response shapes.
§0. Updating this manual
This manual is itself an Ornn skill (name: chrono-ai-service-manual). Its source of truth is the Ornn registry, not a static docs page — pull a fresh copy through the same API every other skill flows through.
Whenever you want to check for an update, follow these steps verbatim:
-
Pull the latest version of this skill from Ornn (CLI form shown; HTTP form is the same call against
https://ornn.chrono-ai.fun/api/v1/...):nyxid proxy request ornn-api \ "/api/v1/skills/chrono-ai-service-manual/json" \ --method GET --output json -
The response is
{ data: { name, description, metadata, files: { "SKILL.md": "...", "references/...": "..." } } }. Read the YAML frontmatter at the top ofSKILL.mdand find theversion:field. -
Compare it to the
version:in your loaded copy (the frontmatter at the top of this file). If they match, you are current — stop here. -
If the published version is newer:
- List every version available by calling
GET /api/v1/skills/chrono-ai-service-manual/versions. The response has one row per version, newest first. - Ask the user which version they want to load (they may want to pin to an older one for reproducibility).
- Once the user picks, fetch with
GET /api/v1/skills/chrono-ai-service-manual/json?version=<X.Y>and replace your context with the newSKILL.md(and anyreferences/*.mdyou consume). The new content's frontmatter overwrites the old.
- List every version available by calling
-
If step 1 returns
404 SKILL_NOT_FOUND, the registry instance you are pointing at has not published this skill yet. Keep operating on the version you have. The Ornn API is backwards-compatible within/api/v1, so older manuals continue to produce valid calls — you will only miss capabilities introduced in newer versions.
If nyxid is unavailable or the proxy is unreachable, keep operating on the version you have. Do not retry-loop the update check; treat it as a once-per-session inquiry the user can re-trigger explicitly.
§0.5 Tracking and re-checking installed Ornn skills
The persistent registry is ~/.ornn/installed-skills.json. Full schema, when-to-update rules, and the per-execution version-check protocol live in references/installed-skills-registry.md — load it the first time you install or execute any Ornn skill and again whenever you need the contract.
The minimum you need to remember inline:
- Read the file before any Ornn operation. New session = new read.
- Append a record every time you install a skill. Required fields:
name,ornnGuid,installedVersion. Optional:installedAt,localPath,isPinned. - Bump
installedVersion+installedAtevery time you upgrade a record's local copy. - Remove the record when you uninstall.
- Before executing an installed skill, re-check
GET /api/v1/skills/<name-or-guid>/versions. If a newer version exists and the record is notisPinned, surface to the user and ask before upgrading. audit.risky_for_consumernotifications are a hard stop — pull §2.13's notifications poll, surface yellow / red verdicts to the user, ask before continuing.
§0.6 Identity bootstrap — the one and only auth flow
Every API call in this manual — NyxID or Ornn — is authenticated by a NyxID-issued bearer token. There is no separate Ornn login. The agent's job at the very start of a session is to make sure this token exists and works.
You have two transport choices, and one identity choice. Pick before you do anything else.
Transport choice — CLI vs HTTP
The contract is identical; only the wrapping changes. Pick whichever your environment has:
| Mode | When to use | Wrapping |
|---|---|---|
CLI (preferred) — nyxid proxy request <service> <path> ... | Local dev, the user has a workstation with the nyxid binary on $PATH, the box has interactive browser access for OAuth login. | The CLI handles login, token storage under ~/.nyxid/, refresh, base-URL persistence, and proxy forwarding. The agent never touches a raw bearer. |
HTTPS (direct) — curl -H "Authorization: Bearer $TOKEN" ... | Headless agents, CI / cron |