# Athos on Claude (Claude Code / claude.ai)

`SKILL.md` at the package root is already a valid **Anthropic Agent Skill** — its
YAML frontmatter (`name`, `description`) plus the modular `references/` are
exactly the progressive-disclosure format Claude loads. Claude drives Athos with
its native **tool use** (the Bash tool in Claude Code, or a connector/MCP on
claude.ai): it calls the Athos REST API directly with your API key. No OpenClaw
CLI, hook transform, or `~/.openclaw` paths are involved.

## Install

Download and unpack the package:

```bash
curl -L <ATHOS_API_URL>/api/v1/skill/download -o athos-skill.tar.gz
tar xzf athos-skill.tar.gz            # extracts an athos/ folder
```

- **Claude Code:** put the folder at `.claude/skills/athos/` (project) or
  `~/.claude/skills/athos/` (personal). Claude auto-discovers it and reads
  `references/*.md` on demand — the progressive disclosure the skill is written
  for. Athos calls run through the **Bash** tool (`curl`).
- **claude.ai:** zip the `athos/` folder and upload it as a skill in the
  capabilities UI. Give Claude the API key in-conversation, or wire an MCP /
  custom connector so it can reach the Athos API.

## Config

Provide the two values to the runtime (env/secret in Claude Code, or in-context /
connector on claude.ai):

```bash
ATHOS_API_URL=<ATHOS_API_URL>   # default https://app.athos.fitness
ATHOS_API_KEY=<ATHOS_API_KEY>   # ak_...
```

Every request authenticates with `Authorization: Bearer $ATHOS_API_KEY`:

```bash
curl -H "Authorization: Bearer $ATHOS_API_KEY" "$ATHOS_API_URL/api/v1/program/week/current"
```

## First run — authenticate, then onboard

Claude does **not** run `athos login` or the `setup-test`/webhook loop (those are
OpenClaw-specific). Just confirm auth works, then start coaching:

1. `GET /api/v1/program/week/current` → 200 confirms the key works.
2. `GET /api/v1/onboarding/questions` → ask the first 1-2 required questions
   conversationally (don't dump a form).
3. `POST /api/v1/onboarding/submit-answers` with exact question IDs.
4. Poll `GET /api/v1/onboarding/status` until strategy is ready (see caveat
   below), then `GET /api/v1/onboarding/strategy-summary` and
   `POST /api/v1/onboarding/confirm-strategy`.
5. Deliver `GET /api/v1/program/week/current` — the canonical current plan.

Modifications: `POST /api/v1/program/today/modify` (today), `.../program/modify`
(week), `.../program/schedule-adjustment` (travel). Food:
`.../food/entries/analyze-text` and `.../food/analyze-image`. Activity:
`.../activity/log`.

## Notifications caveat

Claude runtimes have no OpenClaw `athos-webhook` transform, so proactive
`notification.due` / `skill.updated` pushes won't reach Claude on their own.
Either:

- **Poll** `GET /api/v1/onboarding/status` and `GET /api/v1/program/week/current`
  when the user re-engages (simplest — Athos still delivers push via the app), or
- Register a reachable callback with `POST /api/v1/webhooks` if your deployment
  can receive inbound HTTP (e.g. a hosted endpoint).

## Coaching rules

Full routing, dedupe, and the non-negotiables live in `SKILL.md` / `references/`.
Core ones: never invent training or nutrition numbers — fetch Athos state;
`GET /api/v1/program/week/current` is the source of truth; keep planned vs logged
state distinct; let the Athos backend own notifications. See `/agents.md` for the
agent-facing overview.