{"id":"3b8c3f0c-0114-412d-b0d8-00c32246223b","entityType":"agent","slug":"clawhub-olares-olares-shared","name":"Olares Shared (olares-cli foundation)","canonicalUrl":"https://www.xpersona.co/agent/clawhub-olares-olares-shared","canonicalPath":"/agent/clawhub-olares-olares-shared","generatedAt":"2026-10-12T07:55:03.643Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"editorial-content","verified":true,"confidence":"high","updatedAt":"2026-10-11T20:09:23.506Z","emptyReason":null},"description":"Olares profile and authentication foundation for olares-cli — required prerequisite for every other olares-cli skill on Olares (files, market, settings, dash... Skill: Olares Shared (olares-cli foundation) Owner: olares Summary: Olares profile and authentication foundation for olares-cli — required prerequisite for every other olares-cli skill on Olares (files, market, settings, dash... Tags: latest:4.0.1 Version history: v4.0.1 | 2026-05-29T05:54:25.050Z | user Migrate ownership from @pengpeng to @olares (no content change vs 4.0.0) v4.0.0 | 2026-05-29T04:53:31.765Z | user","descriptionLabel":"Technical summary","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 999 downloads reported by the source. Last updated 10/11/2026.","installCommand":"clawhub skill install s1718vftp5x2gwbtzenpt3kxch87k6j0:olares-shared","sourceUrl":"https://clawhub.ai/olares/olares-shared","homepage":"https://clawhub.ai/olares/skills/olares-shared","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/olares/olares-shared","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/olares/skills/olares-shared","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":60,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"Olares profile and authentication foundation for olares-cli — required prerequisite for every other olares-cli skill on Olares (files, market, settings, dash..."},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-11T20:09:23.506Z","emptyReason":null},"protocols":[{"protocol":"OPENCLEW","label":"OpenClaw","status":"self-declared","notes":"Declared in the public agent profile."}],"capabilities":[],"verifiedCount":0,"selfDeclaredCount":1,"capabilityMatrix":{"rows":[{"key":"OPENCLEW","type":"protocol","support":"unknown","confidenceSource":"profile","notes":"Listed on profile"}],"flattenedTokens":"protocol:OPENCLEW|unknown|profile"}},"adoption":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T20:09:23.506Z","emptyReason":null},"stars":null,"forks":null,"downloads":999,"likes":null,"task":null,"library":null,"packageName":null,"latestVersion":"4.0.1","tractionLabel":"999 downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T20:09:23.431Z","emptyReason":null},"lastUpdatedAt":"2026-10-11T20:09:23.506Z","lastCrawledAt":"2026-10-11T20:09:23.431Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-12T20:09:23.431Z","lastVerifiedAt":null,"highlights":[{"version":"4.0.1","createdAt":"2026-05-29T05:54:25.050Z","changelog":"Migrate ownership from @pengpeng to @olares (no content change vs 4.0.0)","fileCount":3,"zipByteSize":5262},{"version":"4.0.0","createdAt":"2026-05-29T04:53:31.765Z","changelog":"Automated publish from cli/skills/publish.sh","fileCount":3,"zipByteSize":5338},{"version":"1.2.0","createdAt":"2026-05-28T09:27:52.166Z","changelog":"Automated publish from cli/skills/publish.sh","fileCount":3,"zipByteSize":8099},{"version":"1.1.0","createdAt":"2026-04-30T13:22:14.555Z","changelog":"Automated publish from cli/skills/publish.sh","fileCount":2,"zipByteSize":6957}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s1718vftp5x2gwbtzenpt3kxch87k6j0:olares-shared","setupComplexity":"low","setupSteps":["Setup complexity is LOW. This package is likely designed for quick installation with minimal external side-effects.","Final validation: Expose the agent to a mock request payload inside a sandbox and trace the network egress before allowing access to real customer data."],"contract":{"contractStatus":"missing","authModes":[],"requires":[],"forbidden":[],"supportsMcp":false,"supportsA2a":false,"supportsStreaming":false,"inputSchemaRef":null,"outputSchemaRef":null,"dataRegion":null,"contractUpdatedAt":null,"sourceUpdatedAt":null,"freshnessSeconds":null},"invocationGuide":{"preferredApi":{"snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-olares-olares-shared/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-olares-olares-shared/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-olares-olares-shared/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-olares-olares-shared/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-olares-olares-shared/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-olares-olares-shared/trust\""],"jsonRequestTemplate":{"query":"summarize this repo","constraints":{"maxLatencyMs":2000,"protocolPreference":["OPENCLEW"]}},"jsonResponseTemplate":{"ok":true,"result":{"summary":"...","confidence":0.9},"meta":{"source":"CLAWHUB","generatedAt":"2026-10-12T07:55:03.641Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-olares-olares-shared/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-olares-olares-shared/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-olares-olares-shared/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-olares-olares-shared/trust"}},"reliability":{"evidence":{"source":"runtime-metrics","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No trust, reliability, or runtime telemetry is available."},"trust":{"status":"unavailable","handshakeStatus":"UNKNOWN","verificationFreshnessHours":null,"reputationScore":null,"p95LatencyMs":null,"successRate30d":null,"fallbackRate":null,"attempts30d":null,"trustUpdatedAt":null,"trustConfidence":"unknown","sourceUpdatedAt":null,"freshnessSeconds":null},"decisionGuardrails":{"doNotUseIf":["Contract metadata is missing or unavailable for deterministic execution."],"safeUseWhen":[],"riskFlags":["missing_or_unavailable_contract","trust_data_unavailable","schema_references_missing"],"operationalConfidence":"low"},"executionMetrics":{"observedLatencyMsP50":null,"observedLatencyMsP95":null,"estimatedCostUsd":null,"uptime30d":null,"rateLimitRpm":null,"rateLimitBurst":null,"lastVerifiedAt":null,"verificationSource":null},"runtimeMetrics":{"successRate":null,"avgLatencyMs":null,"avgCostUsd":null,"hallucinationRate":null,"retryRate":null,"disputeRate":null,"p50Latency":null,"p95Latency":null,"lastUpdated":null}},"benchmarks":{"evidence":{"source":"no-benchmark-data","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No benchmark suites or observed failure patterns are available."},"suites":[],"failurePatterns":[]},"artifacts":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"high","updatedAt":"2026-10-11T20:09:23.506Z","emptyReason":null},"readme":"Skill: Olares Shared (olares-cli foundation)\n\nOwner: olares\n\nSummary: Olares profile and authentication foundation for olares-cli — required prerequisite for every other olares-cli skill on Olares (files, market, settings, dash...\n\nTags: latest:4.0.1\n\nVersion history:\n\nv4.0.1 | 2026-05-29T05:54:25.050Z | user\n\nMigrate ownership from @pengpeng to @olares (no content change vs 4.0.0)\n\nv4.0.0 | 2026-05-29T04:53:31.765Z | user\n\nAutomated publish from cli/skills/publish.sh\n\nv1.2.0 | 2026-05-28T09:27:52.166Z | user\n\nAutomated publish from cli/skills/publish.sh\n\nv1.1.0 | 2026-04-30T13:22:14.555Z | user\n\nAutomated publish from cli/skills/publish.sh\n\nArchive index:\n\nArchive v4.0.1: 3 files, 5262 bytes\n\nFiles: skill-card.md (2084b), SKILL.md (9102b), _meta.json (132b)\n\nFile v4.0.1:SKILL.md\n\n---\r\nname: olares-shared\r\nversion: 4.0.1\r\ndescription: \"Olares profile and authentication foundation for olares-cli — required prerequisite for every other olares-cli skill on Olares (files, market, settings, dashboard, cluster). Covers the Olares profile model (one profile = one Olares instance + one Olares ID, e.g. alice@olares.com), first-time Olares login with password and optional TOTP, importing an existing refresh_token, switching / listing / removing Olares profiles, OS-keychain token storage keyed by Olares ID, automatic access_token refresh on 401/403, and the full Olares auth-error recovery table. Use when the user mentions Olares, Olares ID, olares-cli, OpenClaw on Olares, profile, login, logout, two-factor / 2FA / TOTP, refresh token, keychain, or sees errors like 'server rejected the access token', 'refresh token for X became invalid', 'no access token for X', 'already authenticated', or 'two-factor authentication required'.\"\r\nmetadata:\r\n requires:\r\n bins: [\"olares-cli\"]\r\n cliHelp: \"olares-cli profile --help\"\r\n---\r\n\r\n# olares-cli shared rules\r\n\r\nFoundation for every other `olares-cli` skill. Every business verb under `cluster` / `files` / `market` / `settings` / `dashboard` rides the active profile's token. **Read this first.**\r\n\r\n> **Source of truth for flags & syntax is always `olares-cli --help`.** This file only carries what `--help` cannot give: the profile mental model, agent-driven login flow, token-storage backends, refresh semantics, and the error → fix matrix.\r\n\r\n## Profile model\r\n\r\nOne profile = one Olares instance + one user identity, keyed by **olaresId** (e.g. `alice@olares.com`). Each profile owns its own access_token / refresh_token pair, stored in the OS keychain.\r\n\r\n| Command | Purpose |\r\n|---------|---------|\r\n| `olares-cli profile login` | Mode A — password (+ TOTP if 2FA is on); auto-creates the profile on first run |\r\n| `olares-cli profile import` | Mode B — bootstrap an access_token from an existing refresh_token |\r\n| `olares-cli profile list` | List every profile, mark the current one, show login status per profile |\r\n| `olares-cli profile use ` | Switch the current profile; `-` reverts to the previous one (like `cd -`) |\r\n| `olares-cli profile remove ` | Delete a profile and its stored token in one shot |\r\n\r\n> **There is no `auth login` / `auth logout` namespace and no per-invocation `--profile` override flag.** Everything lives under `profile`. \"Logout\" is `profile remove`. Identity is whichever profile is currently selected; to target a different one, run `olares-cli profile use ` first.\r\n\r\n## Login modes\r\n\r\n### Mode A — password (+ optional TOTP)\r\n\r\n```bash\r\nolares-cli profile login --olares-id \r\n```\r\n\r\n- Interactive: prompts for password (echo disabled); prompts for TOTP if 2FA is enabled.\r\n- Scripted: pipe via `--password-stdin`; if 2FA is on, you MUST also pass `--totp ` because there is no second prompt.\r\n- **There is no `--password ` flag** — passwords are never accepted on the command line.\r\n\r\n### Mode B — existing refresh_token\r\n\r\n```bash\r\nolares-cli profile import --olares-id <olaresId> --refresh-token \"$OLARES_REFRESH_TOKEN\"\r\n```\r\n\r\nExchanges the refresh_token for an access_token once via `/api/refresh` and writes both to the keychain. **Read the token from an env var or secret manager — never inline plaintext.**\r\n\r\n### Agent-driven login (recommended)\r\n\r\nWhen you (an AI agent) drive the login on the user's behalf, do NOT pass password / TOTP as command-line arguments. Spawn `olares-cli profile login --olares-id <id>` as a background process so it parks at the password prompt, forward the prompt to the user, and read its output after the command exits to confirm success.\r\n\r\n## Switching and inspecting profiles\r\n\r\n`profile list` output:\r\n\r\n```\r\n NAME OLARES-ID STATUS\r\n* alice alice@olares.com logged-in (23h59m)\r\n bob bob@olares.com expired\r\n eve eve@olares.com invalidated\r\n frank frank@olares.com never\r\n```\r\n\r\n| STATUS | Meaning | Recovery |\r\n|--------|---------|----------|\r\n| `logged-in (Xh Ym)` | Token valid; column shows time-to-expiry | — |\r\n| `logged-in` | Token present but JWT has no exp claim (can't verify locally) | Trust until the server says no |\r\n| `expired` | JWT exp is in the past | `profile login` |\r\n| `invalidated` | Server explicitly rejected the refresh leg | `profile login` directly (no need to `profile remove` first) |\r\n| `never` | No token has ever been stored | `profile login` or `profile import` |\r\n\r\nThe leading `*` marks the current profile. `profile use` accepts either the NAME alias or the olaresId.\r\n\r\n## Token storage\r\n\r\n| OS | Backend | Location |\r\n|------|---------|----------|\r\n| darwin | macOS Keychain | service `olares-cli`, account = olaresId |\r\n| linux | AES-256-GCM file | under `~/.local/share/olares-cli/` |\r\n| windows | DPAPI | `HKCU\\Software\\OlaresCli\\keychain` |\r\n\r\nAfter `login` / `import` succeeds, the CLI prints `token stored via <backend> (service \"olares-cli\", account \"<id>\")`. If the backend resolves to `file-fallback` (sandboxed / CI environments), be aware the token now sits in a file with **different security properties than the system keychain**.\r\n\r\n> **The plaintext `~/.olares-cli/tokens.json` from older builds is deprecated** — if a user upgraded and suddenly appears \"logged out\", `profile login` is the fix.\r\n\r\n## Re-authentication rules\r\n\r\n`profile login` and `profile import` both reject the case \"a still-valid token already exists for this olaresId\" — to force-overwrite, run `profile remove <id>` first. Expired / invalidated / never-logged-in profiles get the new token written in place; this lets scripts call `login` after `invalidated` without an extra `remove` step.\r\n\r\n## Automatic token refresh\r\n\r\n**The CLI rotates expired access_tokens transparently.** Users do NOT need to run `profile login` just because their access_token aged out — only when the *refresh_token itself* becomes invalid.\r\n\r\n- Replayable requests (every JSON verb, `files cat`, `files download`, `files rm`, `market` verbs, …): on 401/403 the transport calls `/api/refresh` and retries once with the new token.\r\n- Streaming uploads (`files upload` chunks): pre-decode the JWT exp; if within 60s of expiry, refresh BEFORE sending, because once a `*os.File` chunk is consumed it can't be replayed on a 401.\r\n\r\nAcross goroutines AND across concurrent `olares-cli` processes, `/api/refresh` is hit at most once per stale token (in-process mutex + cross-process flock).\r\n\r\n> **Do not implement custom retry/backoff loops on top of auth errors.** Once you see `ErrTokenInvalidated` or `ErrNotLoggedIn`, only `profile login` / `profile import` will help.\r\n\r\n## Auth error recovery table\r\n\r\n| Error message (excerpt) | Meaning | Fix |\r\n|-------------------------|---------|-----|\r\n| `refresh token for <id> became invalid at <ts>` | `/api/refresh` returned 401/403 — the grant is dead | `olares-cli profile login --olares-id <id>` |\r\n| `no access token for <id>` | Profile selected but keychain has no entry | `olares-cli profile login` or `profile import` |\r\n| `server rejected the access token (HTTP 401)` / `(HTTP 403)` | After auto-refresh the server still rejects (rare) | `olares-cli profile login --olares-id <id>` |\r\n| `--olares-id is required` | login / import invoked without olaresId | Add `--olares-id <id>` |\r\n| `already authenticated for <id> (expires in ...)` | Still-valid token exists | `olares-cli profile remove <id>` then re-run |\r\n| `a token is already stored for <id> but its expiry can't be determined client-side` | Token present but JWT carries no exp claim | `profile remove <id>` then re-run |\r\n| `two-factor authentication required: re-run with --totp <code>` | 2FA on, non-TTY context | Re-run with `--totp <code>`, or run interactively |\r\n| `password is empty` / `TOTP code is empty` | stdin / TTY returned an empty string | Check for premature EOF or an empty pipe |\r\n| `profile <name> not found` | `profile use` / `profile remove` referenced an unknown profile | `profile list` to see the actual names |\r\n\r\n> **Do not silently retry auth errors.** 401/403 after auto-refresh and `already authenticated` are deterministic — follow the table; blind retries make it worse.\r\n\r\n## Security rules\r\n\r\n- **Never** invent a `--password <plaintext>` argument (it does not exist). Passwords go through the TTY or `--password-stdin` fed by a secret pipe.\r\n- **Never** echo `access_token` / `refresh_token` to the terminal. When passing a refresh_token to `profile import`, source it from an environment variable: `--refresh-token \"$OLARES_REFRESH_TOKEN\"`.\r\n- **Confirm intent before write/delete actions** (`profile remove`, `files rm`, `files upload --overwrite`, `cluster pod delete`, …). Do not act unilaterally on the user's behalf.\r\n- **TOTP is not a password** — it is single-use and short-lived, so the CLI echoes it to make manual entry less error-prone. Never persist a TOTP in a shared script.\n\nFile v4.0.1:_meta.json\n\n{\n \"ownerId\": \"kn7153k9wp5dwxsm6getv104r985vrf5\",\n \"slug\": \"olares-shared\",\n \"version\": \"4.0.1\",\n \"publishedAt\": 1780034065050\n}\n\nFile v4.0.1:skill-card.md\n\n## Description:\n\nOlares profile and authentication foundation for olares-cli, covering profile login, refresh-token import, profile switching, keychain-backed token storage, automatic token refresh, and auth-error recovery for Olares CLI workflows.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[olares](https://clawhub.ai/user/olares)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers and agents use this skill as the authentication and profile-management foundation for Olares CLI workflows. It helps users log in safely, import refresh tokens, switch profiles, understand token storage, and recover from common authentication failures.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Long-lived refresh tokens or 2FA codes may be exposed through shared shells, CI logs, recorded terminals, or monitored systems.\n\nMitigation: Prefer interactive login where the user enters credentials directly, and avoid refresh-token import or --totp in shared or logged environments.\n\nRisk: Tokens stored through file fallback have different security properties than a system keychain.\n\nMitigation: Treat file-fallback token storage as sensitive local credential material and review the environment before installing or using the skill.\n\n## Reference(s):\n\n- [ClawHub skill page](https://clawhub.ai/olares/skills/olares-shared)\n- [Olares publisher profile](https://clawhub.ai/user/olares)\n\n## Skill Output:\n\n**Output Type(s):** [guidance, shell commands, configuration]\n\n**Output Format:** [Markdown with inline shell commands and recovery tables]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Requires olares-cli and relies on the active local Olares profile.]\n\n## Skill Version(s):\n\n4.0.1 (source: frontmatter and release evidence)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v4.0.0: 3 files, 5338 bytes\n\nFiles: skill-card.md (2311b), SKILL.md (9102b), _meta.json (132b)\n\nFile v4.0.0:SKILL.md\n\n---\r\nname: olares-shared\r\nversion: 4.0.0\r\ndescription: \"Olares profile and authentication foundation for olares-cli — required prerequisite for every other olares-cli skill on Olares (files, market, settings, dashboard, cluster). Covers the Olares profile model (one profile = one Olares instance + one Olares ID, e.g. alice@olares.com), first-time Olares login with password and optional TOTP, importing an existing refresh_token, switching / listing / removing Olares profiles, OS-keychain token storage keyed by Olares ID, automatic access_token refresh on 401/403, and the full Olares auth-error recovery table. Use when the user mentions Olares, Olares ID, olares-cli, OpenClaw on Olares, profile, login, logout, two-factor / 2FA / TOTP, refresh token, keychain, or sees errors like 'server rejected the access token', 'refresh token for X became invalid', 'no access token for X', 'already authenticated', or 'two-factor authentication required'.\"\r\nmetadata:\r\n requires:\r\n bins: [\"olares-cli\"]\r\n cliHelp: \"olares-cli profile --help\"\r\n---\r\n\r\n# olares-cli shared rules\r\n\r\nFoundation for every other `olares-cli` skill. Every business verb under `cluster` / `files` / `market` / `settings` / `dashboard` rides the active profile's token. **Read this first.**\r\n\r\n> **Source of truth for flags & syntax is always `olares-cli <command> --help`.** This file only carries what `--help` cannot give: the profile mental model, agent-driven login flow, token-storage backends, refresh semantics, and the error → fix matrix.\r\n\r\n## Profile model\r\n\r\nOne profile = one Olares instance + one user identity, keyed by **olaresId** (e.g. `alice@olares.com`). Each profile owns its own access_token / refresh_token pair, stored in the OS keychain.\r\n\r\n| Command | Purpose |\r\n|---------|---------|\r\n| `olares-cli profile login` | Mode A — password (+ TOTP if 2FA is on); auto-creates the profile on first run |\r\n| `olares-cli profile import` | Mode B — bootstrap an access_token from an existing refresh_token |\r\n| `olares-cli profile list` | List every profile, mark the current one, show login status per profile |\r\n| `olares-cli profile use <name\\|->` | Switch the current profile; `-` reverts to the previous one (like `cd -`) |\r\n| `olares-cli profile remove <name>` | Delete a profile and its stored token in one shot |\r\n\r\n> **There is no `auth login` / `auth logout` namespace and no per-invocation `--profile` override flag.** Everything lives under `profile`. \"Logout\" is `profile remove`. Identity is whichever profile is currently selected; to target a different one, run `olares-cli profile use <name>` first.\r\n\r\n## Login modes\r\n\r\n### Mode A — password (+ optional TOTP)\r\n\r\n```bash\r\nolares-cli profile login --olares-id <olaresId>\r\n```\r\n\r\n- Interactive: prompts for password (echo disabled); prompts for TOTP if 2FA is enabled.\r\n- Scripted: pipe via `--password-stdin`; if 2FA is on, you MUST also pass `--totp <code>` because there is no second prompt.\r\n- **There is no `--password <plaintext>` flag** — passwords are never accepted on the command line.\r\n\r\n### Mode B — existing refresh_token\r\n\r\n```bash\r\nolares-cli profile import --olares-id <olaresId> --refresh-token \"$OLARES_REFRESH_TOKEN\"\r\n```\r\n\r\nExchanges the refresh_token for an access_token once via `/api/refresh` and writes both to the keychain. **Read the token from an env var or secret manager — never inline plaintext.**\r\n\r\n### Agent-driven login (recommended)\r\n\r\nWhen you (an AI agent) drive the login on the user's behalf, do NOT pass password / TOTP as command-line arguments. Spawn `olares-cli profile login --olares-id <id>` as a background process so it parks at the password prompt, forward the prompt to the user, and read its output after the command exits to confirm success.\r\n\r\n## Switching and inspecting profiles\r\n\r\n`profile list` output:\r\n\r\n```\r\n NAME OLARES-ID STATUS\r\n* alice alice@olares.com logged-in (23h59m)\r\n bob bob@olares.com expired\r\n eve eve@olares.com invalidated\r\n frank frank@olares.com never\r\n```\r\n\r\n| STATUS | Meaning | Recovery |\r\n|--------|---------|----------|\r\n| `logged-in (Xh Ym)` | Token valid; column shows time-to-expiry | — |\r\n| `logged-in` | Token present but JWT has no exp claim (can't verify locally) | Trust until the server says no |\r\n| `expired` | JWT exp is in the past | `profile login` |\r\n| `invalidated` | Server explicitly rejected the refresh leg | `profile login` directly (no need to `profile remove` first) |\r\n| `never` | No token has ever been stored | `profile login` or `profile import` |\r\n\r\nThe leading `*` marks the current profile. `profile use` accepts either the NAME alias or the olaresId.\r\n\r\n## Token storage\r\n\r\n| OS | Backend | Location |\r\n|------|---------|----------|\r\n| darwin | macOS Keychain | service `olares-cli`, account = olaresId |\r\n| linux | AES-256-GCM file | under `~/.local/share/olares-cli/` |\r\n| windows | DPAPI | `HKCU\\Software\\OlaresCli\\keychain` |\r\n\r\nAfter `login` / `import` succeeds, the CLI prints `token stored via <backend> (service \"olares-cli\", account \"<id>\")`. If the backend resolves to `file-fallback` (sandboxed / CI environments), be aware the token now sits in a file with **different security properties than the system keychain**.\r\n\r\n> **The plaintext `~/.olares-cli/tokens.json` from older builds is deprecated** — if a user upgraded and suddenly appears \"logged out\", `profile login` is the fix.\r\n\r\n## Re-authentication rules\r\n\r\n`profile login` and `profile import` both reject the case \"a still-valid token already exists for this olaresId\" — to force-overwrite, run `profile remove <id>` first. Expired / invalidated / never-logged-in profiles get the new token written in place; this lets scripts call `login` after `invalidated` without an extra `remove` step.\r\n\r\n## Automatic token refresh\r\n\r\n**The CLI rotates expired access_tokens transparently.** Users do NOT need to run `profile login` just because their access_token aged out — only when the *refresh_token itself* becomes invalid.\r\n\r\n- Replayable requests (every JSON verb, `files cat`, `files download`, `files rm`, `market` verbs, …): on 401/403 the transport calls `/api/refresh` and retries once with the new token.\r\n- Streaming uploads (`files upload` chunks): pre-decode the JWT exp; if within 60s of expiry, refresh BEFORE sending, because once a `*os.File` chunk is consumed it can't be replayed on a 401.\r\n\r\nAcross goroutines AND across concurrent `olares-cli` processes, `/api/refresh` is hit at most once per stale token (in-process mutex + cross-process flock).\r\n\r\n> **Do not implement custom retry/backoff loops on top of auth errors.** Once you see `ErrTokenInvalidated` or `ErrNotLoggedIn`, only `profile login` / `profile import` will help.\r\n\r\n## Auth error recovery table\r\n\r\n| Error message (excerpt) | Meaning | Fix |\r\n|-------------------------|---------|-----|\r\n| `refresh token for <id> became invalid at <ts>` | `/api/refresh` returned 401/403 — the grant is dead | `olares-cli profile login --olares-id <id>` |\r\n| `no access token for <id>` | Profile selected but keychain has no entry | `olares-cli profile login` or `profile import` |\r\n| `server rejected the access token (HTTP 401)` / `(HTTP 403)` | After auto-refresh the server still rejects (rare) | `olares-cli profile login --olares-id <id>` |\r\n| `--olares-id is required` | login / import invoked without olaresId | Add `--olares-id <id>` |\r\n| `already authenticated for <id> (expires in ...)` | Still-valid token exists | `olares-cli profile remove <id>` then re-run |\r\n| `a token is already stored for <id> but its expiry can't be determined client-side` | Token present but JWT carries no exp claim | `profile remove <id>` then re-run |\r\n| `two-factor authentication required: re-run with --totp <code>` | 2FA on, non-TTY context | Re-run with `--totp <code>`, or run interactively |\r\n| `password is empty` / `TOTP code is empty` | stdin / TTY returned an empty string | Check for premature EOF or an empty pipe |\r\n| `profile <name> not found` | `profile use` / `profile remove` referenced an unknown profile | `profile list` to see the actual names |\r\n\r\n> **Do not silently retry auth errors.** 401/403 after auto-refresh and `already authenticated` are deterministic — follow the table; blind retries make it worse.\r\n\r\n## Security rules\r\n\r\n- **Never** invent a `--password <plaintext>` argument (it does not exist). Passwords go through the TTY or `--password-stdin` fed by a secret pipe.\r\n- **Never** echo `access_token` / `refresh_token` to the terminal. When passing a refresh_token to `profile import`, source it from an environment variable: `--refresh-token \"$OLARES_REFRESH_TOKEN\"`.\r\n- **Confirm intent before write/delete actions** (`profile remove`, `files rm`, `files upload --overwrite`, `cluster pod delete`, …). Do not act unilaterally on the user's behalf.\r\n- **TOTP is not a password** — it is single-use and short-lived, so the CLI echoes it to make manual entry less error-prone. Never persist a TOTP in a shared script.\n\nFile v4.0.0:_meta.json\n\n{\n \"ownerId\": \"kn7153k9wp5dwxsm6getv104r985vrf5\",\n \"slug\": \"olares-shared\",\n \"version\": \"4.0.0\",\n \"publishedAt\": 1780030411765\n}\n\nFile v4.0.0:skill-card.md\n\n## Description: <br>\nOlares Shared gives agents the profile, login, token storage, profile switching, token refresh, and authentication error recovery guidance needed to use olares-cli safely. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[olares](https://clawhub.ai/user/olares) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nDevelopers, operators, and agents use this skill as the shared authentication foundation before running other olares-cli workflows for files, market, settings, dashboard, and cluster operations on Olares. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: The skill requires sensitive Olares credentials and tokens for profile login and import workflows. <br>\nMitigation: Use the interactive prompt, --password-stdin, environment variables, or a secret manager; do not place passwords, refresh tokens, or access tokens directly on the command line or in shared scripts. <br>\nRisk: Profile removal, profile switching, uploads with overwrite, and delete operations can change the active account or affect remote Olares state. <br>\nMitigation: Confirm the active profile and the intended target before running write or delete commands. <br>\nRisk: File-fallback token storage has weaker security properties than a system keychain. <br>\nMitigation: Prefer OS keychain-backed environments for persistent credentials and treat fallback token files as sensitive local secrets. <br>\n\n\n## Reference(s): <br>\n- [ClawHub skill page](https://clawhub.ai/olares/olares-shared) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [guidance, shell commands, configuration] <br>\n**Output Format:** [Markdown with inline shell commands] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [Guidance centers on olares-cli profile commands, credential handling, and authentication recovery decisions.] <br>\n\n## Skill Version(s): <br>\n4.0.0 (source: frontmatter and server release evidence) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>\n\nArchive v1.2.0: 3 files, 8099 bytes\n\nFiles: skill-card.md (2384b), SKILL.md (17554b), _meta.json (132b)\n\nFile v1.2.0:SKILL.md\n\n---\r\nname: olares-shared\r\nversion: 1.2.0\r\ndescription: \"Olares profile and authentication foundation for olares-cli — required prerequisite for every other olares-cli skill (files, market, settings, dashboard, cluster). Covers the Olares profile model (one profile = one Olares instance + one olaresId), first-time login with password and optional TOTP, importing an existing refresh_token, switching / listing / removing Olares profiles, OS-keychain token storage, automatic access_token refresh on 401/403, and the full Olares auth-error recovery table. Use when the user mentions Olares, olares-cli, OpenClaw on Olares, profile, olaresId, login, logout, two-factor / 2FA / TOTP, refresh token, keychain, or sees errors like 'server rejected the access token', 'refresh token for X became invalid', 'no access token for X', 'already authenticated', or 'two-factor authentication required'.\"\r\nmetadata:\r\n requires:\r\n bins: [\"olares-cli\"]\r\n cliHelp: \"olares-cli profile --help\"\r\n---\r\n\r\n# olares-cli shared rules\r\n\r\nThis skill explains: what a profile is, how to obtain access credentials for it, where those credentials live, and how to recover when the server rejects a token. **Every `olares-cli files ...` (and other business) command depends on the profile selection + auth flow described here.**\r\n\r\n## Profile model\r\n\r\nOne profile = one Olares instance + one user identity. The identity is uniquely keyed by an **olaresId** (e.g. `alice@olares.com`). Each profile owns its own access_token / refresh_token pair, stored in the OS keychain.\r\n\r\nThe `profile` command tree exposes 5 verbs (see [`cmd/ctl/profile/root.go`](cli/cmd/ctl/profile/root.go)):\r\n\r\n| Command | Purpose |\r\n|---------|---------|\r\n| `olares-cli profile login` | Authenticate with a password (+ TOTP if 2FA is on); auto-creates the profile on first run (mode A) |\r\n| `olares-cli profile import` | Bootstrap an access_token from an existing refresh_token (mode B) |\r\n| `olares-cli profile list` | List every profile, mark the current one, show login status per profile |\r\n| `olares-cli profile use <name\\|->` | Switch the current profile; `-` reverts to the previous one (analogous to `cd -`) |\r\n| `olares-cli profile remove <name>` | Delete a profile and its stored token in one shot |\r\n\r\n> **There is no `olares-cli auth login` / `auth logout` namespace.** Every auth-related action lives under `profile`. \"Logout\" is `profile remove`.\r\n\r\n> **There is no per-invocation `--profile` override flag.** Identity is whichever profile is currently selected (set by `profile use`, `profile login`, or `profile import`). Every business verb under `cluster` / `files` / `market` / `settings` / `dashboard` runs against that one profile for the lifetime of the process. To target a different profile, run `olares-cli profile use <name>` first — committing to one role up-front is intentional, so agents don't silently hop identities mid-pipeline.\r\n\r\n## First-time login (mode A: password + optional TOTP)\r\n\r\n```bash\r\nolares-cli profile login --olares-id <olaresId>\r\n```\r\n\r\nBehavior (see [`cmd/ctl/profile/login.go`](cli/cmd/ctl/profile/login.go) and [`cmd/ctl/profile/credentials.go`](cli/cmd/ctl/profile/credentials.go)):\r\n\r\n- Profile does not exist → auto-created\r\n- Profile exists, token expired or invalidated → reuse the profile entry, write a fresh token\r\n- Profile exists, token still valid → **rejected** with a hint to run `olares-cli profile remove <id>` first\r\n\r\n### Password\r\n\r\n- Default: read from the controlling TTY with echo disabled\r\n- Scripts: `--password-stdin`, e.g. `printf '%s' \"$PW\" | olares-cli profile login --olares-id <id> --password-stdin`\r\n- **There is no `--password <plaintext>` flag.** The CLI deliberately omits it so passwords never leak into shell history or `ps` output.\r\n\r\n### 2FA / TOTP\r\n\r\nWhen the server's `/api/firstfactor` returns `fa2=true`, a second factor is required:\r\n\r\n- TTY: the CLI prompts `two-factor code for <id>:` automatically; the user types the 6-digit code\r\n- Non-TTY (`--password-stdin`, CI, etc.): you MUST pass `--totp <code>` up front, otherwise the command fails with `two-factor authentication required: re-run with --totp <code>`\r\n\r\n> **The CLI does not try to guess whether 2FA is enabled.** It probes every login with a targetURL that triggers Authelia's 2FA policy. Accounts without 2FA pass through transparently; accounts with 2FA get prompted for TOTP and then proceed.\r\n\r\n### Agent-driven login (recommended pattern)\r\n\r\nWhen you (an AI agent) drive the login on the user's behalf, **do not** pass the password or TOTP as plaintext command-line arguments. Recommended flow:\r\n\r\n1. Spawn `olares-cli profile login --olares-id <id>` as a background process so it parks at the password prompt.\r\n2. Forward the prompt verbatim to the user and wait for them to type the password / TOTP into their own terminal.\r\n3. After the command exits, read its output to confirm whether the login succeeded.\r\n\r\nAlternatively, instruct the user to run the login in their terminal themselves; the agent then takes over for follow-up command orchestration.\r\n\r\n## Bootstrap from an existing refresh_token (mode B)\r\n\r\nIf the user already has a refresh_token (from LarePass, the wizard activation flow, or any other source), there is no need to run through password + 2FA again:\r\n\r\n```bash\r\nolares-cli profile import --olares-id <olaresId> --refresh-token <tok>\r\n```\r\n\r\nThe CLI exchanges the refresh_token for an access_token via a single `/api/refresh` call (see [`cmd/ctl/profile/import.go`](cli/cmd/ctl/profile/import.go)) and writes both into the keychain. The \"reject if a valid token already exists\" rule from `login` applies here too.\r\n\r\n> **Never write `--refresh-token <tok>` as plaintext in scripts.** Read it from an environment variable or a secret manager:\r\n> ```bash\r\n> olares-cli profile import --olares-id <id> --refresh-token \"$OLARES_REFRESH_TOKEN\"\r\n> ```\r\n\r\n## Switching and inspecting profiles\r\n\r\n### `profile list`\r\n\r\nOutput (see [`cmd/ctl/profile/list.go`](cli/cmd/ctl/profile/list.go)):\r\n\r\n```\r\n NAME OLARES-ID STATUS\r\n* alice alice@olares.com logged-in (23h59m)\r\n bob bob@olares.com expired\r\n eve eve@olares.com invalidated\r\n frank frank@olares.com never\r\n```\r\n\r\n| STATUS | Meaning | Recovery |\r\n|--------|---------|----------|\r\n| `logged-in (Xh Ym)` | Token is valid; column shows time-to-expiry | — |\r\n| `logged-in` | Token is present but its JWT has no exp claim, so we can't verify locally | Trust until the server says no |\r\n| `expired` | Token JWT exp is in the past | `profile login` to re-authenticate |\r\n| `invalidated` | The server explicitly rejected the refresh leg (`/api/refresh` returned 401/403) | `profile login` directly — no need to `profile remove` first |\r\n| `never` | No token has ever been stored for this profile | `profile login` or `profile import` |\r\n\r\nThe leading `*` marks the current profile.\r\n\r\n### `profile use <name|->`\r\n\r\n```bash\r\nolares-cli profile use alice # by NAME alias\r\nolares-cli profile use alice@olares.com # by olaresId (also accepted)\r\nolares-cli profile use - # back to the previous current (errors when none)\r\n```\r\n\r\nUpdates `currentProfile` and `previousProfile` inside `~/.config/olares-cli/config.json`.\r\n\r\n### `profile remove <name>`\r\n\r\n```bash\r\nolares-cli profile remove alice\r\n```\r\n\r\nPerforms four actions atomically:\r\n\r\n1. Removes the profile entry from `config.json`.\r\n2. Deletes the stored token for that olaresId from the keychain.\r\n3. If the removed profile was current, current falls back to the previous (when valid) or to the first remaining profile.\r\n4. If the removed profile was the last one, the keychain namespace itself is purged so no orphan entries remain in Keychain Access.app / regedit / etc.\r\n\r\n## Token storage\r\n\r\n| OS | Backend | Location |\r\n|------|---------|----------|\r\n| darwin | macOS Keychain | service `olares-cli`, account = olaresId |\r\n| linux | AES-256-GCM file | under `~/.local/share/olares-cli/` |\r\n| windows | DPAPI | `HKCU\\Software\\OlaresCli\\keychain` |\r\n\r\n**The plaintext `~/.olares-cli/tokens.json` from older builds is deprecated** — tokens written there by previous versions are no longer read. If the user upgraded and suddenly appears \"logged out\", the correct fix is `profile login` to repopulate the new storage.\r\n\r\nAfter `login` / `import` succeeds, the CLI prints a line like `token stored via <backend> (service \"olares-cli\", account \"<id>\")`. That message is the source of truth for \"where did my token actually land\". If the backend resolves to `file-fallback` (sandboxed / CI environments without access to a system keychain), be aware: that token is now sitting in a file with **different security properties than the system keychain**.\r\n\r\n## Re-authentication rules (critical)\r\n\r\n`profile login` and `profile import` both apply the same logic per olaresId:\r\n\r\n```\r\n ┌───────────────────────────────────────┐\r\nprofile not exist ──▶│ Auto-create and write the new token │\r\n └───────────────────────────────────────┘\r\n ┌──────────────────────────────────────────────┐\r\ntoken expired ──▶│ Reuse the profile entry, write a new token │\r\n └──────────────────────────────────────────────┘\r\n ┌──────────────────────────────────────────────┐\r\ntoken invalidated ──▶│ Reuse the profile entry, write a new token │\r\n └──────────────────────────────────────────────┘\r\n ┌──────────────────────────────────────────────────────────┐\r\ntoken still valid ──▶│ Reject; tell the user to run profile remove <id> first │\r\n └──────────────────────────────────────────────────────────┘\r\n```\r\n\r\nLogic lives in [`cmd/ctl/profile/credentials.go`](cli/cmd/ctl/profile/credentials.go) `ensureProfileWritable`. If a script needs unconditional overwrite, it MUST `profile remove` first and then `profile login` / `profile import`.\r\n\r\n## Automatic token refresh\r\n\r\n**The CLI rotates expired access_tokens transparently.** Users do NOT need to run `profile login` just because their access_token aged out — only when the *refresh_token* itself becomes invalid.\r\n\r\nThe refresh logic lives in [`cli/pkg/cmdutil/factory.go`](cli/pkg/cmdutil/factory.go) (`refreshingTransport`) and [`cli/pkg/credential/refresher.go`](cli/pkg/credential/refresher.go). Every `*http.Client` the Factory hands out has it wired in.\r\n\r\n### Two trigger paths\r\n\r\n| Trigger | Applies to | Behavior |\r\n|---------|------------|----------|\r\n| **Reactive (401/403 + retry)** | Replayable bodies — every JSON / `files cat` / `files download` / `files rm` / `market` JSON verb | Send with current token. On 401/403, `/api/refresh`, retry the same request once with the new token. One extra round-trip in the rare expiry case; zero overhead in steady state. |\r\n| **Pro-active (JWT exp + skew)** | Non-replayable bodies — `files upload` chunks (`*os.File`) | Decode the access_token's JWT exp before sending. If within 60s of expiry (or already past), `/api/refresh` first, send with the new token. Required because once a streaming body is consumed by the first send we can't replay it on a 401. |\r\n\r\nThe pro-active skew is hardcoded at 60s in `cli/pkg/cmdutil/factory.go` (`preflightSkew`) — comfortably absorbs client↔server clock drift plus the time from local decode to the request landing on the server. Tokens issued without an `exp` claim, or values that don't decode as a JWT at all, skip the pre-flight gracefully and fall back to the reactive path.\r\n\r\n### Concurrency\r\n\r\nAcross goroutines AND across concurrent `olares-cli` processes, **`/api/refresh` is hit at most once per stale token**:\r\n\r\n1. Process-wide `sync.Mutex` — losers wait, then read whatever the winner persisted.\r\n2. Compare-after-Get against the keychain — short-circuits when a sibling already rotated the token.\r\n3. On-disk `flock` under `<config-dir>/locks/<sanitized-olaresId>.refresh.lock` — serializes across processes; bounded by a 30s acquire timeout so a stuck peer can't hang the CLI.\r\n4. Re-check inside the flock — collapses any final race that snuck in between the in-process and on-disk locks.\r\n\r\nFor most users this is invisible. It matters when you script multiple `olares-cli` invocations in parallel: they will not stampede `/api/refresh`.\r\n\r\n### When refresh itself fails\r\n\r\n| Outcome | What the user sees | Fix |\r\n|---------|---------------------|-----|\r\n| `/api/refresh` returns 200 + new tokens | (silent — request retried, command succeeds) | — |\r\n| `/api/refresh` returns 401/403 (refresh_token revoked / expired / rotated by another login) | `refresh token for <id> became invalid at <ts>; please run: olares-cli profile login --olares-id <id>` (typed `*ErrTokenInvalidated`) | `olares-cli profile login --olares-id <id>` |\r\n| No token in keychain at all | `no access token for <id>; run: olares-cli profile login --olares-id <id>` (typed `*ErrNotLoggedIn`) | `olares-cli profile login` (or `profile import`) |\r\n| `/api/refresh` returns 5xx / network error | Surfaced verbatim from the transport | Retry the command — the grant itself is still valid |\r\n\r\nThe keychain entry is stamped `InvalidatedAt` on the 401 path so subsequent commands skip the network round-trip and go straight to the CTA. `profile list` shows these as `invalidated`.\r\n\r\n> **Do not implement custom retry/backoff loops on top of these errors.** The transport already handles the recoverable cases; once you see `ErrTokenInvalidated` or `ErrNotLoggedIn`, only `profile login` / `profile import` will help.\r\n\r\n## Auth error recovery table\r\n\r\n| Error message (excerpt) | Meaning | Fix |\r\n|-------------------------|---------|-----|\r\n| `refresh token for <id> became invalid at <ts>` | `/api/refresh` itself returned 401/403 — the grant is dead | `olares-cli profile login --olares-id <id>` |\r\n| `no access token for <id>` | Profile selected but keychain has no entry | `olares-cli profile login` or `profile import` |\r\n| `server rejected the access token (HTTP 401)` / `(HTTP 403)` | After auto-refresh the server still rejects (rare; usually a server-side state drift) | `olares-cli profile login --olares-id <id>` |\r\n| `--olares-id is required` | login / import was invoked without olaresId | Add `--olares-id <id>` |\r\n| `already authenticated for <id> (expires in ...)` | A still-valid token exists for this olaresId | `olares-cli profile remove <id>` and re-run login / import |\r\n| `a token is already stored for <id> but its expiry can't be determined client-side` | Token present but JWT carries no exp claim, so we conservatively reject | Same: `profile remove <id>` and re-run |\r\n| `two-factor authentication required: re-run with --totp <code>` | 2FA is on and we're in a non-TTY context (no way to prompt) | Re-run with `--totp <code>`, or run interactively in a TTY |\r\n| `password is empty` / `TOTP code is empty` | stdin / TTY returned an empty string | Check for premature EOF or an empty pipe |\r\n| `profile <name> not found` | `profile use` / `profile remove` referenced an unknown profile | `profile list` to see the actual names |\r\n\r\n> **Do not silently retry auth errors.** 401/403 after auto-refresh and `already authenticated` are deterministic — follow the table; blind retries make the situation worse.\r\n\r\n## dev / internal flags\r\n\r\nFor internal debugging or self-hosted dev environments only — **never include these in user-facing examples or scripts**:\r\n\r\n| Flag | Use |\r\n|------|-----|\r\n| `--auth-url-override <url>` | Hard-pin the Authelia URL instead of deriving it from olaresId |\r\n| `--local-url-prefix <label>` | Inject an extra label between the auth subdomain and the terminus name |\r\n| `--insecure-skip-verify` | Disable TLS verification (only for self-signed local environments) |\r\n\r\n## Security rules\r\n\r\n- **Never** invent a `--password <plaintext>` argument (it does not exist). Passwords go through the TTY or `--password-stdin` fed by a secret pipe.\r\n- **Never** echo `access_token` / `refresh_token` to the terminal. When passing a refresh_token to `profile import`, source it from an environment variable or external secret store: `--refresh-token \"$OLARES_REFRESH_TOKEN\"`.\r\n- **Confirm intent before write/delete actions** (`profile remove`, `files rm`, `files upload --overwrite`, ...). Do not act unilaterally on the user's behalf.\r\n- **TOTP is not a password** — it is single-use and short-lived, so the CLI deliberately echoes it to make manual entry less error-prone (matching `gh auth login`, `aws sso login`, kubectl OIDC plugins). That said, never persist a TOTP in a shared script.\n\nFile v1.2.0:_meta.json\n\n{\n \"ownerId\": \"kn7153k9wp5dwxsm6getv104r985vrf5\",\n \"slug\": \"olares-shared\",\n \"version\": \"1.2.0\",\n \"publishedAt\": 1779960472166\n}\n\nFile v1.2.0:skill-card.md\n\n## Description: <br>\nGuides agents through Olares olares-cli profile authentication, token storage, profile switching, and auth-error recovery used by other Olares CLI skills. <br>\n\nThis skill is ready for commercial/non-commercial use. <br>\n\n## Publisher: <br>\n[pengpeng](https://clawhub.ai/user/pengpeng) <br>\n\n### License/Terms of Use: <br>\nMIT-0 <br>\n\n\n## Use Case: <br>\nDevelopers and operators use this skill when configuring or troubleshooting Olares CLI authentication before running files, market, settings, dashboard, or cluster commands. It helps agents choose the correct profile commands, handle password, TOTP, and refresh-token flows, and recover from common authentication errors. <br>\n\n### Deployment Geography for Use: <br>\nGlobal <br>\n\n## Known Risks and Mitigations: <br>\nRisk: The skill handles authentication workflows that may involve passwords, TOTP codes, access tokens, and refresh tokens. <br>\nMitigation: Avoid pasting passwords or refresh tokens into chat; prefer terminal prompts, secret-manager input, or environment variables. <br>\nRisk: Profile removal, file deletion, and overwrite actions can change local configuration or remote Olares state. <br>\nMitigation: Review any profile removal, deletion, or overwrite action before allowing an agent to run it. <br>\nRisk: Tokens stored with a file fallback backend have different security properties than a system keychain. <br>\nMitigation: Check the CLI token-storage message after login or import and treat file-fallback storage as more sensitive. <br>\n\n\n## Reference(s): <br>\n- [ClawHub skill page](https://clawhub.ai/pengpeng/olares-shared) <br>\n\n\n## Skill Output: <br>\n**Output Type(s):** [text, markdown, shell commands, configuration, guidance] <br>\n**Output Format:** [Markdown guidance with inline shell commands and recovery tables] <br>\n**Output Parameters:** [1D] <br>\n**Other Properties Related to Output:** [Documentation-only guidance for olares-cli profile and authentication workflows; requires the olares-cli binary.] <br>\n\n## Skill Version(s): <br>\n1.2.0 (source: frontmatter and server release metadata) <br>\n\n## Ethical Considerations: <br>\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment. <br>\n\nArchive v1.1.0: 2 files, 6957 bytes\n\nFiles: SKILL.md (17935b), _meta.json (132b)\n\nFile v1.1.0:SKILL.md\n\n---\r\nname: olares-shared\r\nversion: 1.1.0\r\ndescription: \"Shared olares-cli foundation: profile model, first-time login (profile login with password + TOTP), bootstrapping a profile from an existing refresh token (profile import), switching/listing/removing profiles, the global --profile flag, where access/refresh tokens live in the OS keychain, automatic access_token refresh via /api/refresh (transparent reactive retry on 401/403; pro-active JWT-exp refresh for streaming uploads; cross-goroutine + cross-process deduplication via flock), and how to recover from auth errors (HTTP 401/403, refresh token invalidated, not logged in, two-factor authentication required). Use whenever the user is configuring olares-cli for the first time, logging in or importing credentials, switching/listing/removing profiles, asking how token refresh works, scripting parallel olares-cli invocations, or seeing errors like 'server rejected the access token', 'refresh token for X became invalid', 'no access token for X', 'already authenticated', or 'two-factor authentication required'; also use when the user asks about refresh tokens, the keychain, olaresId, or profile management.\"\r\nmetadata:\r\n requires:\r\n bins: [\"olares-cli\"]\r\n cliHelp: \"olares-cli profile --help\"\r\n---\r\n\r\n# olares-cli shared rules\r\n\r\nThis skill explains: what a profile is, how to obtain access credentials for it, where those credentials live, and how to recover when the server rejects a token. **Every `olares-cli files ...` (and other business) command depends on the profile selection + auth flow described here.**\r\n\r\n## Profile model\r\n\r\nOne profile = one Olares instance + one user identity. The identity is uniquely keyed by an **olaresId** (e.g. `alice@olares.com`). Each profile owns its own access_token / refresh_token pair, stored in the OS keychain.\r\n\r\nThe `profile` command tree exposes 5 verbs (see [`cmd/ctl/profile/root.go`](cli/cmd/ctl/profile/root.go)):\r\n\r\n| Command | Purpose |\r\n|---------|---------|\r\n| `olares-cli profile login` | Authenticate with a password (+ TOTP if 2FA is on); auto-creates the profile on first run (mode A) |\r\n| `olares-cli profile import` | Bootstrap an access_token from an existing refresh_token (mode B) |\r\n| `olares-cli profile list` | List every profile, mark the current one, show login status per profile |\r\n| `olares-cli profile use <name\\|->` | Switch the current profile; `-` reverts to the previous one (analogous to `cd -`) |\r\n| `olares-cli profile remove <name>` | Delete a profile and its stored token in one shot |\r\n\r\n> **There is no `olares-cli auth login` / `auth logout` namespace.** Every auth-related action lives under `profile`. \"Logout\" is `profile remove`.\r\n\r\n## Global `--profile` flag\r\n\r\nThe root command registers a persistent `--profile <olaresId>` flag (see [`cmd/ctl/root.go`](cli/cmd/ctl/root.go) L57). It overrides the currently-selected profile for one invocation without flipping the persisted current pointer:\r\n\r\n```bash\r\n# Doesn't change current; this single ls runs against alice's credentials.\r\nolares-cli files ls drive/Home/ --profile alice@olares.com\r\n```\r\n\r\nUse this for: scripting parallel operations against multiple profiles, sanity-checking a specific profile's status, and avoiding pollution of the interactive terminal's current pointer.\r\n\r\n## First-time login (mode A: password + optional TOTP)\r\n\r\n```bash\r\nolares-cli profile login --olares-id <olaresId>\r\n```\r\n\r\nBehavior (see [`cmd/ctl/profile/login.go`](cli/cmd/ctl/profile/login.go) and [`cmd/ctl/profile/credentials.go`](cli/cmd/ctl/profile/credentials.go)):\r\n\r\n- Profile does not exist → auto-created\r\n- Profile exists, token expired or invalidated → reuse the profile entry, write a fresh token\r\n- Profile exists, token still valid → **rejected** with a hint to run `olares-cli profile remove <id>` first\r\n\r\n### Password\r\n\r\n- Default: read from the controlling TTY with echo disabled\r\n- Scripts: `--password-stdin`, e.g. `printf '%s' \"$PW\" | olares-cli profile login --olares-id <id> --password-stdin`\r\n- **There is no `--password <plaintext>` flag.** The CLI deliberately omits it so passwords never leak into shell history or `ps` output.\r\n\r\n### 2FA / TOTP\r\n\r\nWhen the server's `/api/firstfactor` returns `fa2=true`, a second factor is required:\r\n\r\n- TTY: the CLI prompts `two-factor code for <id>:` automatically; the user types the 6-digit code\r\n- Non-TTY (`--password-stdin`, CI, etc.): you MUST pass `--totp <code>` up front, otherwise the command fails with `two-factor authentication required: re-run with --totp <code>`\r\n\r\n> **The CLI does not try to guess whether 2FA is enabled.** It probes every login with a targetURL that triggers Authelia's 2FA policy. Accounts without 2FA pass through transparently; accounts with 2FA get prompted for TOTP and then proceed.\r\n\r\n### Agent-driven login (recommended pattern)\r\n\r\nWhen you (an AI agent) drive the login on the user's behalf, **do not** pass the password or TOTP as plaintext command-line arguments. Recommended flow:\r\n\r\n1. Spawn `olares-cli profile login --olares-id <id>` as a background process so it parks at the password prompt.\r\n2. Forward the prompt verbatim to the user and wait for them to type the password / TOTP into their own terminal.\r\n3. After the command exits, read its output to confirm whether the login succeeded.\r\n\r\nAlternatively, instruct the user to run the login in their terminal themselves; the agent then takes over for follow-up command orchestration.\r\n\r\n## Bootstrap from an existing refresh_token (mode B)\r\n\r\nIf the user already has a refresh_token (from LarePass, the wizard activation flow, or any other source), there is no need to run through password + 2FA again:\r\n\r\n```bash\r\nolares-cli profile import --olares-id <olaresId> --refresh-token <tok>\r\n```\r\n\r\nThe CLI exchanges the refresh_token for an access_token via a single `/api/refresh` call (see [`cmd/ctl/profile/import.go`](cli/cmd/ctl/profile/import.go)) and writes both into the keychain. The \"reject if a valid token already exists\" rule from `login` applies here too.\r\n\r\n> **Never write `--refresh-token <tok>` as plaintext in scripts.** Read it from an environment variable or a secret manager:\r\n> ```bash\r\n> olares-cli profile import --olares-id <id> --refresh-token \"$OLARES_REFRESH_TOKEN\"\r\n> ```\r\n\r\n## Switching and inspecting profiles\r\n\r\n### `profile list`\r\n\r\nOutput (see [`cmd/ctl/profile/list.go`](cli/cmd/ctl/profile/list.go)):\r\n\r\n```\r\n NAME OLARES-ID STATUS\r\n* alice alice@olares.com logged-in (23h59m)\r\n bob bob@olares.com expired\r\n eve eve@olares.com invalidated\r\n frank frank@olares.com never\r\n```\r\n\r\n| STATUS | Meaning | Recovery |\r\n|--------|---------|----------|\r\n| `logged-in (Xh Ym)` | Token is valid; column shows time-to-expiry | — |\r\n| `logged-in` | Token is present but its JWT has no exp claim, so we can't verify locally | Trust until the server says no |\r\n| `expired` | Token JWT exp is in the past | `profile login` to re-authenticate |\r\n| `invalidated` | The server explicitly rejected the refresh leg (`/api/refresh` returned 401/403) | `profile login` directly — no need to `profile remove` first |\r\n| `never` | No token has ever been stored for this profile | `profile login` or `profile import` |\r\n\r\nThe leading `*` marks the current profile.\r\n\r\n### `profile use <name|->`\r\n\r\n```bash\r\nolares-cli profile use alice # by NAME alias\r\nolares-cli profile use alice@olares.com # by olaresId (also accepted)\r\nolares-cli profile use - # back to the previous current (errors when none)\r\n```\r\n\r\nUpdates `currentProfile` and `previousProfile` inside `~/.config/olares-cli/config.json`.\r\n\r\n### `profile remove <name>`\r\n\r\n```bash\r\nolares-cli profile remove alice\r\n```\r\n\r\nPerforms four actions atomically:\r\n\r\n1. Removes the profile entry from `config.json`.\r\n2. Deletes the stored token for that olaresId from the keychain.\r\n3. If the removed profile was current, current falls back to the previous (when valid) or to the first remaining profile.\r\n4. If the removed profile was the last one, the keychain namespace itself is purged so no orphan entries remain in Keychain Access.app / regedit / etc.\r\n\r\n## Token storage\r\n\r\n| OS | Backend | Location |\r\n|------|---------|----------|\r\n| darwin | macOS Keychain | service `olares-cli`, account = olaresId |\r\n| linux | AES-256-GCM file | under `~/.local/share/olares-cli/` |\r\n| windows | DPAPI | `HKCU\\Software\\OlaresCli\\keychain` |\r\n\r\n**The plaintext `~/.olares-cli/tokens.json` from older builds is deprecated** — tokens written there by previous versions are no longer read. If the user upgraded and suddenly appears \"logged out\", the correct fix is `profile login` to repopulate the new storage.\r\n\r\nAfter `login` / `import` succeeds, the CLI prints a line like `token stored via <backend> (service \"olares-cli\", account \"<id>\")`. That message is the source of truth for \"where did my token actually land\". If the backend resolves to `file-fallback` (sandboxed / CI environments without access to a system keychain), be aware: that token is now sitting in a file with **different security properties than the system keychain**.\r\n\r\n## Re-authentication rules (critical)\r\n\r\n`profile login` and `profile import` both apply the same logic per olaresId:\r\n\r\n```\r\n ┌───────────────────────────────────────┐\r\nprofile not exist ──▶│ Auto-create and write the new token │\r\n └───────────────────────────────────────┘\r\n ┌──────────────────────────────────────────────┐\r\ntoken expired ──▶│ Reuse the profile entry, write a new token │\r\n └──────────────────────────────────────────────┘\r\n ┌──────────────────────────────────────────────┐\r\ntoken invalidated ──▶│ Reuse the profile entry, write a new token │\r\n └──────────────────────────────────────────────┘\r\n ┌──────────────────────────────────────────────────────────┐\r\ntoken still valid ──▶│ Reject; tell the user to run profile remove <id> first │\r\n └──────────────────────────────────────────────────────────┘\r\n```\r\n\r\nLogic lives in [`cmd/ctl/profile/credentials.go`](cli/cmd/ctl/profile/credentials.go) `ensureProfileWritable`. If a script needs unconditional overwrite, it MUST `profile remove` first and then `profile login` / `profile import`.\r\n\r\n## Automatic token refresh\r\n\r\n**The CLI rotates expired access_tokens transparently.** Users do NOT need to run `profile login` just because their access_token aged out — only when the *refresh_token* itself becomes invalid.\r\n\r\nThe refresh logic lives in [`cli/pkg/cmdutil/factory.go`](cli/pkg/cmdutil/factory.go) (`refreshingTransport`) and [`cli/pkg/credential/refresher.go`](cli/pkg/credential/refresher.go). Every `*http.Client` the Factory hands out has it wired in.\r\n\r\n### Two trigger paths\r\n\r\n| Trigger | Applies to | Behavior |\r\n|---------|------------|----------|\r\n| **Reactive (401/403 + retry)** | Replayable bodies — every JSON / `files cat` / `files download` / `files rm` / `market` JSON verb | Send with current token. On 401/403, `/api/refresh`, retry the same request once with the new token. One extra round-trip in the rare expiry case; zero overhead in steady state. |\r\n| **Pro-active (JWT exp + skew)** | Non-replayable bodies — `files upload` chunks (`*os.File`) | Decode the access_token's JWT exp before sending. If within 60s of expiry (or already past), `/api/refresh` first, send with the new token. Required because once a streaming body is consumed by the first send we can't replay it on a 401. |\r\n\r\nThe pro-active skew is hardcoded at 60s in `cli/pkg/cmdutil/factory.go` (`preflightSkew`) — comfortably absorbs client↔server clock drift plus the time from local decode to the request landing on the server. Tokens issued without an `exp` claim, or values that don't decode as a JWT at all, skip the pre-flight gracefully and fall back to the reactive path.\r\n\r\n### Concurrency\r\n\r\nAcross goroutines AND across concurrent `olares-cli` processes, **`/api/refresh` is hit at most once per stale token**:\r\n\r\n1. Process-wide `sync.Mutex` — losers wait, then read whatever the winner persisted.\r\n2. Compare-after-Get against the keychain — short-circuits when a sibling already rotated the token.\r\n3. On-disk `flock` under `<config-dir>/locks/<sanitized-olaresId>.refresh.lock` — serializes across processes; bounded by a 30s acquire timeout so a stuck peer can't hang the CLI.\r\n4. Re-check inside the flock — collapses any final race that snuck in between the in-process and on-disk locks.\r\n\r\nFor most users this is invisible. It matters when you script multiple `olares-cli` invocations in parallel: they will not stampede `/api/refresh`.\r\n\r\n### When refresh itself fails\r\n\r\n| Outcome | What the user sees | Fix |\r\n|---------|---------------------|-----|\r\n| `/api/refresh` returns 200 + new tokens | (silent — request retried, command succeeds) | — |\r\n| `/api/refresh` returns 401/403 (refresh_token revoked / expired / rotated by another login) | `refresh token for <id> became invalid at <ts>; please run: olares-cli profile login --olares-id <id>` (typed `*ErrTokenInvalidated`) | `olares-cli profile login --olares-id <id>` |\r\n| No token in keychain at all | `no access token for <id>; run: olares-cli profile login --olares-id <id>` (typed `*ErrNotLoggedIn`) | `olares-cli profile login` (or `profile import`) |\r\n| `/api/refresh` returns 5xx / network error | Surfaced verbatim from the transport | Retry the command — the grant itself is still valid |\r\n\r\nThe keychain entry is stamped `InvalidatedAt` on the 401 path so subsequent commands skip the network round-trip and go straight to the CTA. `profile list` shows these as `invalidated`.\r\n\r\n> **Do not implement custom retry/backoff loops on top of these errors.** The transport already handles the recoverable cases; once you see `ErrTokenInvalidated` or `ErrNotLoggedIn`, only `profile login` / `profile import` will help.\r\n\r\n## Auth error recovery table\r\n\r\n| Error message (excerpt) | Meaning | Fix |\r\n|-------------------------|---------|-----|\r\n| `refresh token for <id> became invalid at <ts>` | `/api/refresh` itself returned 401/403 — the grant is dead | `olares-cli profile login --olares-id <id>` |\r\n| `no access token for <id>` | Profile selected but keychain has no entry | `olares-cli profile login` or `profile import` |\r\n| `server rejected the access token (HTTP 401)` / `(HTTP 403)` | After auto-refresh the server still rejects (rare; usually a server-side state drift) | `olares-cli profile login --olares-id <id>` |\r\n| `--olares-id is required` | login / import was invoked without olaresId | Add `--olares-id <id>` |\r\n| `already authenticated for <id> (expires in ...)` | A still-valid token exists for this olaresId | `olares-cli profile remove <id>` and re-run login / import |\r\n| `a token is already stored for <id> but its expiry can't be determined client-side` | Token present but JWT carries no exp claim, so we conservatively reject | Same: `profile remove <id>` and re-run |\r\n| `two-factor authentication required: re-run with --totp <code>` | 2FA is on and we're in a non-TTY context (no way to prompt) | Re-run with `--totp <code>`, or run interactively in a TTY |\r\n| `password is empty` / `TOTP code is empty` | stdin / TTY returned an empty string | Check for premature EOF or an empty pipe |\r\n| `profile <name> not found` | `profile use` / `profile remove` referenced an unknown profile | `profile list` to see the actual names |\r\n\r\n> **Do not silently retry auth errors.** 401/403 after auto-refresh and `already authenticated` are deterministic — follow the table; blind retries make the situation worse.\r\n\r\n## dev / internal flags\r\n\r\nFor internal debugging or self-hosted dev environments only — **never include these in user-facing examples or scripts**:\r\n\r\n| Flag | Use |\r\n|------|-----|\r\n| `--auth-url-override <url>` | Hard-pin the Authelia URL instead of deriving it from olaresId |\r\n| `--local-url-prefix <label>` | Inject an extra label between the auth subdomain and the terminus name |\r\n| `--insecure-skip-verify` | Disable TLS verification (only for self-signed local environments) |\r\n\r\n## Security rules\r\n\r\n- **Never** invent a `--password <plaintext>` argument (it does not exist). Passwords go through the TTY or `--password-stdin` fed by a secret pipe.\r\n- **Never** echo `access_token` / `refresh_token` to the terminal. When passing a refresh_token to `profile import`, source it from an environment variable or external secret store: `--refresh-token \"$OLARES_REFRESH_TOKEN\"`.\r\n- **Confirm intent before write/delete actions** (`profile remove`, `files rm`, `files upload --overwrite`, ...). Do not act unilaterally on the user's behalf.\r\n- **TOTP is not a password** — it is single-use and short-lived, so the CLI deliberately echoes it to make manual entry less error-prone (matching `gh auth login`, `aws sso login`, kubectl OIDC plugins). That said, never persist a TOTP in a shared script.\n\nFile v1.1.0:_meta.json\n\n{\n \"ownerId\": \"kn7153k9wp5dwxsm6getv104r985vrf5\",\n \"slug\": \"olares-shared\",\n \"version\": \"1.1.0\",\n \"publishedAt\": 1777555334555\n}","readmeExcerpt":"Skill: Olares Shared (olares-cli foundation) Owner: olares Summary: Olares profile and authentication foundation for olares-cli — required prerequisite for every other olares-cli skill on Olares (files, market, settings, dash... Tags: latest:4.0.1 Version history: v4.0.1 | 2026-05-29T05:54:25.050Z | user Migrate ownership from @pengpeng to @olares (no content change vs 4.0.0) v4.0.0 | 2026-05-29T04:53:31.765Z | user ","codeSnippets":[],"executableExamples":[],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"SKILL.md","content":"---\r\nname: olares-shared\r\nversion: 4.0.1\r\ndescription: \"Olares profile and authentication foundation for olares-cli — required prerequisite for every other olares-cli skill on Olares (files, market, settings, dashboard, cluster). Covers the Olares profile model (one profile = one Olares instance + one Olares ID, e.g. alice@olares.com), first-time Olares login with password and optional TOTP, importing an existing refresh_token, switching / listing / removing Olares profiles, OS-keychain token storage keyed by Olares ID, automatic access_token refresh on 401/403, and the full Olares auth-error recovery table. Use when the user mentions Olares, Olares ID, olares-cli, OpenClaw on Olares, profile, login, logout, two-factor / 2FA / TOTP, refresh token, keychain, or sees errors like 'server rejected the access token', 'refresh token for X became invalid', 'no access token for X', 'already authenticated', or 'two-factor authentication required'.\"\r\nmetadata:\r\n requires:\r\n bins: [\"olares-cli\"]\r\n cliHelp: \"olares-cli profile --help\"\r\n---\r\n\r\n# olares-cli shared rules\r\n\r\nFoundation for every other `olares-cli` skill. Every business verb under `cluster` / `files` / `market` / `settings` / `dashboard` rides the active profile's token. **Read this first.**\r\n\r\n> **Source of truth for flags & syntax is always `olares-cli <command> --help`.** This file only carries what `--help` cannot give: the profile mental model, agent-driven login flow, token-storage backends, refresh semantics, and the error → fix matrix.\r\n\r\n## Profile model\r\n\r\nOne profile = one Olares instance + one user identity, keyed by **olaresId** (e.g. `alice@olares.com`). Each profile owns its own access_token / refresh_token pair, stored in the OS keychain.\r\n\r\n| Command | Purpose |\r\n|---------|---------|\r\n| `olares-cli profile login` | Mode A — password (+ TOTP if 2FA is on); auto-creates the profile on first run |\r\n| `olares-cli profile import` | Mode B — bootstrap an access_token from an existing refresh_token |\r\n| `olares-cli profile list` | List every profile, mark the current one, show login status per profile |\r\n| `olares-cli profile use <name\\|->` | Switch the current profile; `-` reverts to the previous one (like `cd -`) |\r\n| `olares-cli profile remove <name>` | Delete a profile and its stored token in one shot |\r\n\r\n> **There is no `auth login` / `auth logout` namespace and no per-invocation `--profile` override flag.** Everything lives under `profile`. \"Logout\" is `profile remove`. Identity is whichever profile is currently selected; to target a different one, run `olares-cli profile use <name>` first.\r\n\r\n## Login modes\r\n\r\n### Mode A — password (+ optional TOTP)\r\n\r\n```bash\r\nolares-cli profile login --olares-id <olaresId>\r\n```\r\n\r\n- Interactive: prompts for password (echo disabled); prompts for TOTP if 2FA is enabled.\r\n- Scripted: pipe via `--password-stdin`; if 2FA is on, you MUST also pass `--totp <code>` because there is no second prompt.\r\n- **There is no `--password <plaintext>` flag"},{"path":"_meta.json","content":"{\n \"ownerId\": \"kn7153k9wp5dwxsm6getv104r985vrf5\",\n \"slug\": \"olares-shared\",\n \"version\": \"4.0.1\",\n \"publishedAt\": 1780034065050\n}"},{"path":"skill-card.md","content":"## Description:\n\nOlares profile and authentication foundation for olares-cli, covering profile login, refresh-token import, profile switching, keychain-backed token storage, automatic token refresh, and auth-error recovery for Olares CLI workflows.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[olares](https://clawhub.ai/user/olares)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nDevelopers and agents use this skill as the authentication and profile-management foundation for Olares CLI workflows. It helps users log in safely, import refresh tokens, switch profiles, understand token storage, and recover from common authentication failures.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: Long-lived refresh tokens or 2FA codes may be exposed through shared shells, CI logs, recorded terminals, or monitored systems.\n\nMitigation: Prefer interactive login where the user enters credentials directly, and avoid refresh-token import or --totp in shared or logged environments.\n\nRisk: Tokens stored through file fallback have different security properties than a system keychain.\n\nMitigation: Treat file-fallback token storage as sensitive local credential material and review the environment before installing or using the skill.\n\n## Reference(s):\n\n- [ClawHub skill page](https://clawhub.ai/olares/skills/olares-shared)\n- [Olares publisher profile](https://clawhub.ai/user/olares)\n\n## Skill Output:\n\n**Output Type(s):** [guidance, shell commands, configuration]\n\n**Output Format:** [Markdown with inline shell commands and recovery tables]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [Requires olares-cli and relies on the active local Olares profile.]\n\n## Skill Version(s):\n\n4.0.1 (source: frontmatter and release evidence)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment."}],"languages":[],"docsSourceLabel":"CLAWHUB","editorialOverview":"Olares profile and authentication foundation for olares-cli — required prerequisite for every other olares-cli skill on Olares (files, market, settings, dash... Skill: Olares Shared (olares-cli foundation) Owner: olares Summary: Olares profile and authentication foundation for olares-cli — required prerequisite for every other olares-cli skill on Olares (files, market, settings, dash... Tags: latest:4.0.1 Version history: v4.0.1 | 2026-05-29T05:54:25.050Z | user Migrate ownership from @pengpeng to @olares (no content change vs 4.0.0) v4.0.0 | 2026-05-29T04:53:31.765Z | user","editorialQuality":{"score":100,"threshold":65,"status":"ready","wordCount":1125,"uniquenessScore":48,"reasons":[]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-11T20:09:23.506Z","emptyReason":"No screenshots, media assets, or demo links are available."},"primaryImageUrl":null,"mediaAssetCount":0,"assets":[],"demoUrl":null},"ownerResources":{"evidence":{"source":"unclaimed","verified":false,"confidence":"low","updatedAt":"2026-10-11T20:09:23.506Z","emptyReason":"This page has not been claimed by the agent owner."},"hasCustomPage":false,"customPageUpdatedAt":null,"customLinks":[],"structuredLinks":{"docsUrl":null,"demoUrl":null,"supportUrl":null,"pricingUrl":null,"statusUrl":null},"customPage":null},"relatedAgents":{"evidence":{"source":"protocol-neighbors","verified":false,"confidence":"medium","updatedAt":"2026-10-12T07:55:03.643Z","emptyReason":null},"items":[{"id":"8ebccd8e-3863-4187-8355-c3f14e1f9edf","entityType":"agent","canonicalPath":"/agent/iofficeai-aionui","slug":"iofficeai-aionui","name":"AionUi","description":"Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!","url":"https://github.com/iOfficeAI/AionUi","homepage":"https://www.aionui.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-10-09T19:11:12.944Z","createdAt":"2026-02-25T03:38:16.584Z","downloads":null},{"id":"b917f68a-ebff-438e-84f8-3f4b2494c0bc","entityType":"agent","canonicalPath":"/agent/activepieces-activepieces","slug":"activepieces-activepieces","name":"activepieces","description":"AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents","url":"https://github.com/activepieces/activepieces","homepage":"https://www.activepieces.com","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-15T02:22:12.426Z","createdAt":"2026-02-25T03:38:12.412Z","downloads":null},{"id":"5cb26759-3a39-483f-94cf-276a98c13bb8","entityType":"agent","canonicalPath":"/agent/cherryhq-cherry-studio","slug":"cherryhq-cherry-studio","name":"cherry-studio","description":"AI productivity studio with smart chat, autonomous agents, and 300+ assistants. Unified access to frontier LLMs","url":"https://github.com/CherryHQ/cherry-studio","homepage":"https://cherry-ai.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-11T14:38:40.986Z","createdAt":"2026-02-25T03:38:19.379Z","downloads":null},{"id":"6f6582d0-5d76-4f0f-b81d-86520247950b","entityType":"agent","canonicalPath":"/agent/copilotkit-copilotkit","slug":"copilotkit-copilotkit","name":"CopilotKit","description":"The Frontend for Agents & Generative UI. React + Angular","url":"https://github.com/CopilotKit/CopilotKit","homepage":"https://docs.copilotkit.ai","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-03-25T09:50:57.846Z","createdAt":"2026-02-25T03:39:14.617Z","downloads":null}],"links":{"hub":"/agent","source":"/agent/source/clawhub","protocols":[{"label":"OpenClaw","href":"/agent/protocol/openclew"}]}}}