# Agent GM Skill

Use this skill when an agent needs to perform the simplest recurring GM behavior on Ink: call `gm()` once every 24 hours for both `DailyAgentGM` and `DailyGM`.

## Scope

- Network: Ink Mainnet (`57073`)
- This skill is only for calling `gm()`
- Do not call `gmTo(address)`
- Do not build recipient-selection logic
- Do not add extra product-service integrations unless explicitly requested

## Contracts

- `DailyAgentGM`: `0x2B9DD9Eede2AeCB095455ce45122101109E4AeC7`
- `DailyGM`: `0x9F500d075118272B3564ac6Ef2c70a9067Fd2d3F`
- `gm()` selector: `0xc0129d43`

## Wallets

- API wallet: `0x44cF07CD26611823002eC2376b27609BfF12ad95`
- Railway env-backed wallet: `0x7e8258b31328d98eB291b2F0BFc18cF452c91661`

## Required Behavior

For each wallet, call `gm()` on both contracts:

1. API wallet -> `DailyAgentGM.gm()`
2. API wallet -> `DailyGM.gm()`
3. Railway wallet -> `DailyAgentGM.gm()`
4. Railway wallet -> `DailyGM.gm()`

Each action should run no earlier than 24 hours after its own last successful call.

## Timing Rule

- Do not use a fixed UTC schedule as the only guard.
- Persist `last_success_at` separately for each of the four actions.
- Compute `next_eligible_at = last_success_at + 24 hours + small safety buffer`.
- A buffer of a few minutes is preferred over sending exactly at the 24-hour mark.
- Manual runs count as real runs and must update the persisted timing state.
- On restart, reload persisted state before attempting any call.

## Preconditions

Before attempting any `gm()` call:

1. Verify Ink RPC connectivity.
2. Verify the correct signer is available for the wallet being used.
3. For `DailyAgentGM`, verify the caller satisfies the `8004` identity registration NFT requirement.
4. Simulate or estimate gas when possible.
5. If the call is still in cooldown or would revert, skip it and record why.

## Execution Flow

For each of the four actions:

1. Check persisted `next_eligible_at`.
2. If not yet eligible, skip.
3. If the action targets `DailyAgentGM`, verify identity eligibility.
4. Simulate `gm()`.
5. If simulation succeeds, send the transaction.
6. Wait for the receipt.
7. On success, update `last_success_at`, `next_eligible_at`, and `last_tx_hash`.

## Failure Handling

- If one action fails, continue with the others unless there is a shared blocker such as RPC failure or wrong network.
- Do not spam retries on deterministic failures.
- Report revert reasons when available.
- Prefer skipping over risking duplicate or too-early sends.

## Required Output

Return a concise summary containing:

- which of the four actions were eligible
- which were skipped
- which were submitted
- tx hash for each submitted call
- receipt status for each submitted call
- revert reason or likely cause for any skipped or failed call
- the next eligible time for each action