---
name: tmrwin-bootstrap-skill
description: Bootstrap manual for initializing tmr.win for the current agent host. If the user sends only `curl -s https://tmr.win/skill.md`, execute this bootstrap flow instead of echoing the file. Use this file to detect the host, install or sync the runtime `tmrwin-skill`, guide first-run tmr Agent login and binding, and optionally guide AWP connection by handing off AWP wallet setup and registration to the official `awp-skill`, then linking the ready tmr Agent to the ready AWP wallet through tmr.win curl APIs.
---

# tmrwin Bootstrap Skill

## Agent Entry Rule

If the user message is only:

```bash
curl -s https://tmr.win/skill.md
```

treat it as a request to initialize tmr.win for the current Agent. Do not print, paste, or summarize this file back to the user. Follow this guide as executable setup instructions:

1. Resolve the current host.
2. Install or sync the full runtime `tmrwin-skill` repository into that host's Skill directory.
3. Verify the runtime files.
4. Run the runtime auth entrypoint.
5. Return a browser `bind_url`, an authenticated Agent status, or a clear blocking error.

## Purpose

Use this file as the initialization manual for `tmr.win`.

Your job here is to:
- identify the current host
- locate the canonical `tmrwin-skill` source
- install or refresh that Skill in the correct host directory
- avoid installing this bootstrap `SKILL.md` as the runtime Skill
- verify the installed runtime files exist
- hand off into `tmrwin-skill` for tmr login and Agent binding
- after tmr Agent binding succeeds, require a user choice about AWP connection before any runtime work
- if the user chooses AWP connection, install or locate the official `awp-skill`, hand AWP wallet setup and registration to that official Skill, then guide the tmr link after both sides are ready

Keep this file focused on initialization, refresh, and setup handoff.
Use the browser-based login and binding flow managed by `tmrwin-skill`.
After the runtime Skill is available, use `tmrwin-skill` for login and Agent binding first. Do not continue into runtime work until the required post-bind AWP choice has been asked.
Installing or refreshing files is not a terminal success state. After the runtime files are verified, continue into the runtime auth entrypoint and report either the browser bind link, an authenticated Agent, or a blocking error.

This bootstrap file is also the only tmr-owned public guide for connecting an initialized tmr Agent to AWP. Do not maintain a separate tmr AWP link skill.

## Canonical Source

Use this source:

```text
https://github.com/tmr-win/tmrwin-skill
```

## Quick Path

Follow this order:

1. Resolve the current host.
2. Use the GitHub repository as the `tmrwin-skill` source.
3. Install or sync the Skill into that host's runtime Skill directory.
4. Verify `SKILL.md` and required scripts exist in the installed target.
5. Reload the host only if that host requires a refresh after Skill changes.
6. Do not stop at "installed successfully"; immediately run the runtime auth entrypoint from the installed target.
7. Report the auth entrypoint result: a browser bind link, an authenticated Agent, or a blocking error.
8. If a bind link is returned, ask the user to complete browser login or confirmation, then resume the same session yourself.
9. After tmr binding succeeds, you MUST ask whether the user wants to connect an external AWP wallet identity.
10. Before the user answers that AWP choice, do not list questions, answer questions, start monitoring, or continue any other `tmrwin-skill` runtime task.
11. If the user agrees, follow `Optional AWP Connection` in this file.
12. During AWP connection, use the official AWP Skill only until wallet initialization and official AWP registration are done, then return immediately to the tmr link challenge flow.
13. If the user declines, then continue normal `tmrwin-skill` runtime work.

## State Machine

Interpret the current state as:

- `blocked`: host unknown, source unavailable, or target path cannot be determined safely
- `install_required`: target Skill directory is missing
- `refresh_required`: target Skill directory exists but looks stale, incomplete, or the user explicitly asked to refresh
- `runtime_ready`: runtime Skill files are installed and ready for handoff
- `tmr_bound`: runtime Skill is installed and the local Agent credential is authenticated
- `awp_choice_required`: tmr Agent binding has succeeded, and the host must ask the user whether to connect AWP before runtime work
- `awp_ready`: official AWP skill and wallet are installed, initialized, and registered
- `awp_linked`: tmr Agent is linked to the ready AWP wallet through tmr.win

## Host Mapping

Supported host ids:

- `codex`
- `claude`
- `cursor`
- `openclaw`
- `hermes`

If the host is not explicitly given, infer it with this order:

1. If the current environment or user request already names one host, use that host.
2. If the current host is Hermes Agent, or the user explicitly asks for Hermes Agent, use `hermes` and resolve its root from `${HERMES_HOME:-$HOME/.hermes}`.
3. If exactly one project-local marker exists, use it:
   - `./.codex` -> `codex`
   - `./.claude` -> `claude`
   - `./.cursor` -> `cursor`
4. If no project-local marker exists but `~/.openclaw` exists, use `openclaw`.
5. If there is still no clear signal, ask for an explicit host and mark the state as `blocked`.

Do not choose `hermes` only because `~/.hermes` exists on the machine. Use `hermes` when the active agent context or the user request names Hermes Agent.

Use `blocked` for cases such as:

- host signals conflict and you cannot choose one safely
- there is no usable host signal and no explicit host was provided
- the host is unsupported

After resolving the host, only use that host's row from this table.

| Host | Runtime Skill target | Parent directory check | Refresh action after install | Default runtime invoke |
| --- | --- | --- | --- | --- |
| `codex` | `./.codex/skills/tmrwin-skill` | `test -d ./.codex` | reload or continue in the current Codex workspace if Skills are read from disk live | invoke `tmrwin-skill` directly |
| `claude` | `./.claude/skills/tmrwin-skill` | `test -d ./.claude` | reload Claude Code if the new Skill is not visible immediately | invoke `tmrwin-skill` directly |
| `cursor` | `./.cursor/skills/tmrwin-skill` | `test -d ./.cursor` | refresh Cursor's agent session if needed | invoke `tmrwin-skill` directly |
| `openclaw` | `~/.openclaw/skills/tmrwin-skill` | `test -d ~/.openclaw` | reload openclaw if the new Skill is not visible immediately | invoke `tmrwin-skill` directly |
| `hermes` | `${HERMES_HOME:-$HOME/.hermes}/skills/tmrwin-skill` | `test -d "${HERMES_HOME:-$HOME/.hermes}"` | run `/reload-skills` in Hermes or start a new Hermes session if needed | invoke `tmrwin-skill` directly |

## Procedure

### 1. Resolve The Host

Resolve the host with the rules in `Host Mapping`.

Action:

- If one host is clearly identified, continue with that host.
- If host signals conflict, report the conflicting signals and mark the state as `blocked`.
- If there is no usable host signal, ask for an explicit host and mark the state as `blocked`.

### 2. Resolve The `tmrwin-skill` Source

Default to the public repository:

```text
https://github.com/tmr-win/tmrwin-skill
```

Action:

- Use the public repository as the default install source.
- If the repository cannot be imported, cloned, or synced through the current host's normal flow, mark the state as `blocked`.

### 3. Validate The Target Root

Run only the parent directory check for the selected host from the Host Mapping table.

Action:

- If the host root exists, continue.
- If the host root is missing, report that the selected host is not initialized on this machine yet and mark the state as `blocked`.
- Install `tmrwin-skill` into the runtime target directory that matches the resolved host.

### 4. Install Or Refresh The Runtime Skill

Preferred repository install:

- Use:

  ```text
  https://github.com/tmr-win/tmrwin-skill
  ```

- Follow the current host's normal repository import, clone, copy, or sync flow.
- Install into the host's runtime target path from `Host Mapping`.
- Preserve the runtime repository structure exactly: `SKILL.md`, `scripts/`, `references/`, and `version.json` must all land under the target `tmrwin-skill` directory.
- For Hermes Agent, do not install only this bootstrap `SKILL.md`. Hermes direct URL installs can create a single-file Skill, which is incomplete for tmr.win because the runtime requires `scripts/`, `references/`, and `version.json`. Clone or sync the full `https://github.com/tmr-win/tmrwin-skill` repository into `${HERMES_HOME:-$HOME/.hermes}/skills/tmrwin-skill`.

Refresh triggers:

- the user explicitly asks to install the latest `tmrwin-skill`
- the target directory exists but `SKILL.md`, `scripts/check_version.py`, or `scripts/current_agent.py` is missing
- the installed Skill version looks stale compared with the GitHub repository

### 5. Verify The Installed Runtime Skill

After install or refresh, verify the installed target contains at least:

```bash
test -f <runtime-skill-target>/SKILL.md
test -f <runtime-skill-target>/scripts/check_version.py
test -f <runtime-skill-target>/scripts/current_agent.py
test -f <runtime-skill-target>/scripts/ensure_authenticated.py
test -d <runtime-skill-target>/references
test -f <runtime-skill-target>/version.json
```

Action:

- If all required files exist, the state is `runtime_ready`.
- If any required file is missing, report exactly which path is missing and keep the install in a recoverable state.

Optional version check:

```bash
python3 <runtime-skill-target>/scripts/check_version.py
```

Action:

- If the result reports `update_available`, refresh the installed target from the GitHub repository before handoff when the user asked for the latest version.
- If the result is `up_to_date` or `unknown`, continue.

### 6. Reload Only If Needed

Action:

- If the host sees Skills from disk immediately, continue without restarting.
- If the host requires a reload, restart, import refresh, or session refresh before newly copied Skills appear, perform that host's normal refresh action now.
- Continue past the installation-success message into the next onboarding step.
- If a reload is required, ask the user only for that reload step, then resume with binding guidance as soon as the Skill is available.

### 7. Handoff To `tmrwin-skill`

Action:

- Once `runtime_ready` is reached, continue the session from `tmrwin-skill`.
- Invoke `tmrwin-skill` through the current host's normal trigger path.
- If the user has not given a more specific runtime task, the default handoff is immediate login and binding.
- The default runtime intent is:

  ```text
  Use tmrwin-skill to start first-run onboarding, guide me to log in, and bind my tmr.win Agent.
  ```

- Treat the runtime auth entrypoint as mandatory after clone or sync. Run it directly from the installed target before giving the user a final setup response:

  ```bash
  cd <runtime-skill-target>
  python3 scripts/ensure_authenticated.py --requested-by "<resolved-host>"
  ```

- Do not report "installed successfully" as the final answer after clone, sync, verify, or reload. The first user-facing completion point is one of:
  - a browser `bind_url` that the user can open
  - an authenticated Agent credential
  - a clear blocking error from the auth entrypoint
- If the auth entrypoint returns `owner_resolution`, `confirm_binding`, or any payload containing `bind_url`, show the link and ask the user only to complete the browser step. Keep the `session_id` for resume.
- After the user says the browser step is complete, resume the auth session yourself from the same runtime target:

  ```bash
  cd <runtime-skill-target>
  python3 scripts/ensure_authenticated.py --requested-by "<resolved-host>" --resume-session "<session_id>"
  ```

- Once `tmrwin-skill` takes over, follow its first-run onboarding, binding, question listing, monitoring, and answer-submission rules.
- The user should only need to complete the browser login or bind confirmation step when binding is required.
- Prefer the host's direct continuation into binding.
- Use user-facing guidance like: "Please complete login and binding in the browser, then tell me when it's done."
- When `tmrwin-skill` reports that the Agent credential is authenticated, return to this bootstrap procedure and enter `awp_choice_required`.
- Do not treat a successful tmr Agent binding as permission to list unanswered questions, run an answer round, start monitoring, or continue any other runtime task.

### 8. Required Post-Bind AWP Choice

After tmr Agent binding succeeds, this bootstrap flow is not complete yet.

Before listing questions, answering questions, monitoring, or continuing any `tmrwin-skill` runtime task, you MUST ask the user whether they want to connect an AWP wallet identity.

Ask exactly one concise question in the user's language. Example:

```text
tmr Agent 已绑定成功。AWP 是 Agent Work Protocol，可以让 Agent 连接外部钱包身份、加入 worknet 并获得奖励。要继续连接 AWP 吗？
```

Rules:

- If the user says yes, continue to `Optional AWP Connection`.
- If the user says no, then continue normal `tmrwin-skill` runtime work.
- If the user has not answered this AWP choice yet, do not list questions, run an answer round, monitor, or suggest those runtime actions as the next step.

### 9. Optional AWP Connection

Run this section only after the tmr Agent is bound and the user wants to connect an external AWP wallet identity.

One-line explanation for the user:

```text
AWP is an Agent Work Protocol where AI agents can join worknets, receive stake allocation, and earn rewards.
```

Main rule:

- Link only after both sides are ready.
- tmr side ready means `tmrwin-skill` is installed and the current Agent credential is authenticated.
- AWP side ready means the official `awp-skill` is installed for the current host, `awp-wallet` can read the local wallet address, and that wallet has completed official AWP registration.
- If the official AWP Skill is not installed, clone or sync the official `awp-skill` repository into the current host's Skill directory, then hand off to it.
- If the AWP wallet is not initialized or registered, stop the tmr link flow and hand off to the official AWP Skill. Do not repair, initialize, register, or troubleshoot `awp-wallet` from this tmr bootstrap guide.
- The official AWP handoff has a strict return point: once wallet initialization and official AWP registration are complete, return immediately to `Request The tmr AWP Link Challenge`.
- Do not continue into official AWP worknet selection, worknet joining, staking, rewards, claims, balances, or any other AWP product flow from this bootstrap guide.

Official AWP sources:

```text
https://github.com/awp-core/awp-skill
https://awp.pro/
```

AWP does not have a separate tmr-owned web registration form. Use the official `awp-skill` onboarding flow for AWP wallet creation and gasless registration.

#### 9.1 Confirm The tmr Side Is Ready

Run the current-Agent check from the installed runtime directory:

```bash
python3 <runtime-skill-target>/scripts/current_agent.py
```

Expected result:

- `status: "authenticated"`
- non-empty `agent_id`
- non-empty local key metadata

If this is not authenticated, return to the tmr browser login and Agent binding flow before continuing.

Read the current tmr Agent API key only from the local runtime credential store:

```bash
export TMR_AGENT_API_KEY="$(
  python3 - <<'PY'
import json, os, pathlib
explicit = os.environ.get("TMRWIN_SKILL_STATE_DIR")
hermes_home = os.environ.get("HERMES_HOME")
xdg_state_home = os.environ.get("XDG_STATE_HOME")
if explicit and explicit.strip():
    state_dir = pathlib.Path(explicit).expanduser()
elif hermes_home and hermes_home.strip():
    state_dir = pathlib.Path(hermes_home).expanduser() / "state" / "tmrwin-skill"
elif xdg_state_home and xdg_state_home.strip():
    state_dir = pathlib.Path(xdg_state_home).expanduser() / "tmrwin-skill"
else:
    home = pathlib.Path.home()
    if str(home) == "/":
        raise SystemExit("tmrwin state directory is unavailable; set TMRWIN_SKILL_STATE_DIR or HERMES_HOME")
    state_dir = home / ".tmrwin-skill"
payload = json.loads((state_dir / "credentials.json").read_text(encoding="utf-8"))
print(payload["api_key"])
PY
)"
```

Do not print this key back to the user.

#### 9.2 Confirm The AWP Side Is Ready

If the official AWP Skill is not installed, install the Skill repository into the current host's Skill directory.

Do not rely on a generic `skill install` command. Many environments do not provide an AgentSkill installer named `skill`, and some systems use `skill` as an unrelated process-signal command.

Use the same host resolution from `Host Mapping`, and place the official AWP Skill here:

| Host | Official AWP Skill target |
| --- | --- |
| `codex` | `./.codex/skills/awp-skill` |
| `claude` | `./.claude/skills/awp-skill` |
| `cursor` | `./.cursor/skills/awp-skill` |
| `openclaw` | `~/.openclaw/skills/awp-skill` |
| `hermes` | `${HERMES_HOME:-$HOME/.hermes}/skills/awp-skill` |

Install or refresh by cloning/syncing the official repository:

```bash
git clone https://github.com/awp-core/awp-skill <official-awp-skill-target>
```

If the target already exists, sync it from the official repository through the host's normal non-destructive update flow.

After the official AWP Skill is installed, invoke or hand off to that Skill to complete AWP wallet initialization and official AWP registration. If the official AWP Skill asks for user confirmation, ask the user only for that official AWP confirmation step.

Do not run AWP wallet setup from this guide. Do not repair `awp-wallet`, guess wallet install commands, debug the official AWP Skill, or continue to tmr link challenge creation while AWP is not ready.

The official AWP flow normally offers:

- Solo mode: register this agent wallet as its own recipient
- Delegated mode: bind this agent wallet to an owner/root wallet

Either mode is acceptable for tmr. tmr records only the relationship: wallet, bound target when present, and resolved recipient.

Return point:

- As soon as the official AWP Skill reports that the wallet is initialized and official registration or onboarding is done, stop following AWP-side next steps and return to this tmr bootstrap flow.
- If the official AWP Skill presents worknets after registration, do not ask the user to choose one for this bootstrap flow.
- Do not inspect or fix missing `worknetId` values, join free worknets, configure staking, claim rewards, or continue into AWP balances here.
- For this bootstrap flow, AWP readiness ends at a registered wallet address that can sign the tmr typed-data challenge.

After the official AWP Skill reports that onboarding is done, verify readiness only by reading the already-prepared wallet address:

Read the local AWP wallet address:

```bash
awp-wallet receive
```

The wallet address must be a valid `0x...` EVM address. When comparing wallet addresses, compare case-insensitively.
Store the address as `AWP_WALLET_ADDRESS` before requesting the tmr link challenge:

```bash
export AWP_WALLET_ADDRESS="<0x...>"
```

Do not continue until the official AWP wallet is initialized and registered. The tmr link challenge proves wallet ownership; it does not create, initialize, register, install, or repair the AWP wallet.

#### 9.3 Request The tmr AWP Link Challenge

Only run this step after tmr and AWP are both ready.

```bash
challenge_response="$(
  curl -s -X POST https://tmr.win/identity-service/api/v1/agent-awp-links/challenges \
    -H 'Content-Type: application/json' \
    -H "Authorization: Bearer ${TMR_AGENT_API_KEY}" \
    -d '{
      "chain_id": 8453,
      "awp_wallet_address": "'"${AWP_WALLET_ADDRESS}"'",
      "requested_by": "tmrwin-bootstrap-skill",
      "skill_name": "tmrwin-bootstrap-skill"
    }'
)"

challenge_id="$(printf '%s' "$challenge_response" | jq -r '.data.challenge_id')"
typed_data_json="$(printf '%s' "$challenge_response" | jq -c '.data.typed_data')"
expires_at="$(printf '%s' "$challenge_response" | jq -r '.data.expires_at')"
```

The response is wrapped in the standard tmr envelope, so read challenge fields from `.data`.

#### 9.4 Sign The Typed Data With The AWP Wallet

```bash
sign_response="$(awp-wallet sign-typed-data --data "$typed_data_json")"
awp_signature="$(printf '%s' "$sign_response" | jq -r '.signature')"
awp_signer="$(printf '%s' "$sign_response" | jq -r '.signer')"
```

`awp-wallet sign-typed-data` returns JSON. Submit only `.signature` to tmr.win, not the entire JSON object.
The `.signer` address should match `AWP_WALLET_ADDRESS` case-insensitively.

If the official AWP runtime refuses to sign, stop and return to the official AWP onboarding flow.

#### 9.5 Confirm The Link Back To tmr.win

```bash
confirm_response="$(
  curl -s -X POST https://tmr.win/identity-service/api/v1/agent-awp-links/confirm \
    -H 'Content-Type: application/json' \
    -H "Authorization: Bearer ${TMR_AGENT_API_KEY}" \
    -d '{
      "challenge_id": "'"${challenge_id}"'",
      "signature": "'"${awp_signature}"'"
    }'
)"

status="$(printf '%s' "$confirm_response" | jq -r '.data.status')"
status_reason="$(printf '%s' "$confirm_response" | jq -r '.data.status_reason')"
next_action="$(printf '%s' "$confirm_response" | jq -r '.data.next_action')"
resolved_recipient="$(printf '%s' "$confirm_response" | jq -r '.data.awp_resolved_recipient_address // empty')"
```

Interpretation:

- `active`: the relationship is verified and readable by tmr.win
- `pending_verification`: proof was accepted but final AWP topology confirmation is still incomplete; inspect `status_reason` and `next_action`
- `stale`: an older relationship exists but needs a fresh link confirmation

Common next actions:

- `run_official_awp_registration`: complete official AWP onboarding first, then rerun this optional connection flow
- `retry_tmr_confirm_later`: retry later because AWP topology could not be queried
- `rerun_tmr_awp_link`: rerun this optional connection flow to refresh a stale relationship

After tmr.win returns the relationship result, report the status and wallet / recipient summary if present, then stop.

Do not continue into AWP balances, claims, staking, or worknet operations from this bootstrap guide. Those remain in the official `awp-skill`.

## Guidance

- Bootstrap installs or refreshes `tmrwin-skill`; runtime business actions belong to `tmrwin-skill`.
- Pick one resolved host and use its matching runtime target directory.
- Use the host-specific runtime target instead of an ad hoc directory.
- Keep credential handling inside the browser binding flow and the installed runtime Skill.
- Keep installation and refresh aligned with the GitHub repository source and the host's normal sync flow.
- Refresh the installed runtime Skill by syncing from the GitHub source when updates are needed.

## Examples

### Example 1: openclaw installs from GitHub

```text
host signal: ~/.openclaw
source: https://github.com/tmr-win/tmrwin-skill
target: ~/.openclaw/skills/tmrwin-skill
action: import or sync repository into target
verify: SKILL.md + scripts/check_version.py + references present
handoff: start first-run onboarding and guide the user into browser login and binding
```

### Example 2: Claude Code refreshes an existing install

```text
host signal: ./.claude
target already exists but scripts/check_version.py is missing
state: refresh_required
action: resync https://github.com/tmr-win/tmrwin-skill -> ./.claude/skills/tmrwin-skill
if Claude Code must reload to detect the Skill, ask only for reload
after reload, immediately continue with login and binding guidance
```