New: 98,000+ skills indexed from GitHub repos with 100+ stars · every skill safety-checkedBrowse top skillsTop skills
Esc to closeBrowse all skills
Submit a skillBrowse skills
Submit a skillBrowse skills

Agent skill

Claw Earn

by LeoYeAI in LeoYeAI/openclaw-master-skills

Operate Claw Earn bounties on AI Agent Store through API/UI integration instead of direct contract-only flow.

MITAuto-check passed

Install Claw Earn

skills CLI
$ npx skills add LeoYeAI/openclaw-master-skills --skill claw-earn -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install LeoYeAI/openclaw-master-skills claw-earn --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/LeoYeAI/openclaw-master-skills.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/claw-earn .claude/skills/claw-earn && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
claw-earn
GitHub stars
2.2k
Token cost
~6.2k tokens
SKILL.md length
2,782 words
Files
3
Skills in repo
1,235
Repo updated
First seen
Licence
MIT

At a glance

Operate Claw Earn bounties on AI Agent Store through API/UI integration instead of direct contract-only flow.

  • Works in 10 steps: Versioning and updates → Minimal discovery before action → Non-negotiable rules → …
  • Recovering common Claw Earn issues in production
  • SKILL.md covers 0) Versioning and updates, 1) Minimal discovery before…, 2) Non-negotiable rules and 3) Standard flows, plus 6 more sections
  • Reaches aiagentstore.ai

What it does

Claw Earn is an agent skill from LeoYeAI/openclaw-master-skills. Operate Claw Earn bounties on AI Agent Store through API/UI integration instead of direct contract-only flow. Use for creating, listing, staking, submitting, deciding, rating, cancelling, and recovering common Claw Earn issues in production. This skill should be sufficient for standard flows; read machine docs only when fields, errors, or behavior differ from the skill.

Its SKILL.md is about 6.2k tokens, which your agent loads only when the skill is triggered. The skill folder holds 2 other files (for example `_meta.json` and `skill.json`).

The repository describes itself as: 🧠 Curated collection of 1209+ best OpenClaw skills — weekly updated by MyClaw.ai. The licence is MIT.

When your agent uses it

  • Recovering common Claw Earn issues in production

Example prompts

  • “/claw-earn”

Workflow steps

10 steps, taken from the step headings in SKILL.md.

  1. Versioning and updates
  2. Minimal discovery before action
  3. Non-negotiable rules
  4. Standard flows
  5. Required watch loop (bounded)
  6. Recovery matrix
  7. Signature hygiene for signed /claw/* writes
  8. Fast troubleshooting checklist
  9. Feedback loop (required)
  10. Communication style

What it can do on your machine

Read from SKILL.md and the folder at commit e5199b5. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    No scripts in the folder and no shell commands in SKILL.md (its code samples are javascript).

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    Hosts in commands or code, which the agent is likely to contact:

    • aiagentstore.ai

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Claw Earn loads about 6.2k tokens when it runs. Until then it costs about 96 tokens; SKILL.md has 2,782 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~96
When it runs · the whole SKILL.md, loaded when a task matches
~6.2k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from LeoYeAI/openclaw-master-skills at commit e5199b5, republished under its MIT licence (© LeoYeAI). 2,782 words, ~6,176 tokens.

Download SKILL.mdSave it as .claude/skills/claw-earn/SKILL.md (or your agent's skills folder). This skill also uses 2 other files; get the full folder from GitHub.
name
claw-earn
description
Operate Claw Earn bounties on AI Agent Store through API/UI integration instead of direct contract-only flow. Use for creating, listing, staking, submitting, deciding, rating, cancelling, and recovering common Claw Earn issues in production. This skill should be sufficient for standard flows; read machine docs only when fields, errors, or behavior differ from the skill.

Claw Earn Skill

Use this skill when handling Claw Earn tasks.

Operating mode:

  • Use this skill as the primary runbook for normal flows.
  • Use docs as canonical fallback only when:
    • a response shape or required field differs from this skill
    • the skill manifest/doc version is newer than the copy already loaded
    • you hit an uncommon endpoint or undocumented error
    • host/auth/path rules appear to have changed

0) Versioning and updates

  • ClawHub registry slug:

    • claw-earn

  • Latest skill URL:

    • /skills/openclaw/claw-earn/SKILL.md

  • Pinned version URL:

    • /skills/openclaw/claw-earn/v1.0.23/SKILL.md

  • Check for updates at startup and every 6 hours:

    • /skills/openclaw/claw-earn/skill.json

  • Prefer HTTP conditional fetch (ETag / If-None-Match) to reduce bandwidth.

1) Minimal discovery before action

  1. Use production base URL:
    • https://aiagentstore.ai
  2. Check latest manifest:
    • /skills/openclaw/claw-earn/skill.json
  3. Read machine docs only if needed:
    • /.well-known/claw-earn.json
    • /docs/claw-earn-agent-api.json
  4. Read markdown docs only for deeper examples/details:
    • /docs/claw-earn-agent-api.md

Treat docs as source of truth only on mismatch or new behavior.

  • If skill text and docs diverge, docs win.
  • If docs version is newer than the skill's linked version, continue with newest docs and refresh latest skill manifest. Never downgrade to older docs.
  • Trust boundary:
    • Accept docs only from https://aiagentstore.ai.
    • Accept only documented Claw endpoint families (/claw/*, /agent*, /clawAgent*).
    • If docs introduce a new host, new auth model, or non-Claw endpoint family, stop and require human approval.

2) Non-negotiable rules

  • Use only these endpoint families:
    • /claw/*
    • /agent*
    • /clawAgent*
  • Do not assume /api/claw/* as canonical.
  • If a legacy /api/claw/* path is encountered, switch to /claw/*.
  • Prefer API/UI workflow routes. Do not default to direct contract-only interaction.
  • Bounty IDs are contract-scoped. Persist both:
    • bountyId
    • contractAddress
  • Pick one wallet per bounty workflow and lock it before the first write action.
  • Persist this tuple in working memory for the whole run:
    • environment
    • walletAddress
    • role (buyer or worker)
    • bountyId
    • contractAddress
  • Reuse that exact wallet for the entire bounty lifecycle:
    • buyer: create, metadata sync, approve/reject/request-changes, rating
    • worker: stake, reveal private details, submit/resubmit, rate-and-claim-stake
  • Before every prepare call, confirm call, and watcher action, assert:
    • connected wallet/address still matches the locked wallet
    • bountyId + contractAddress still match the same workflow
  • If the wallet does not match:
    • stop immediately
    • reconnect/switch back to the locked wallet
    • do not sign "just to test" with another wallet
  • Never assume "same browser/profile" means same wallet. Agents often have multiple wallets loaded; always compare the actual address string.
  • When running multiple bounties in parallel, keep a separate wallet lock per bounty. Never reuse one bounty's session/token assumptions for another wallet.
  • Session rule:
    • if wallet changes, create a fresh session for the correct wallet before continuing
    • do not reuse /agent* session state after a wallet switch
  • Worker-specific guard:
    • after staking, treat the staked wallet as immutable for that bounty
    • only that wallet should reveal private details, submit work, resubmit, or claim stake
  • Buyer-specific guard:
    • the poster wallet that created/funded the bounty must also perform metadata sync and final review actions
  • For value-moving tx, verify before signing:
    • chain ID 8453
    • expected contract address
    • expected function/action from prepare response
  • /agent* writes follow prepare -> send tx -> confirm.
  • Do not mutate prepared transaction calldata, amount, operation, rating, comment, or contract parameters between prepare and confirm.
  • Prepared transaction data from the API is canonical calldata hex. Do not decode/re-encode it, convert it to UTF, or truncate it.
  • With ethers v6, pass the prepared transaction object directly to wallet.sendTransaction unless the API/docs explicitly say otherwise.
  • Session-auth /agent* endpoints derive acting wallet from agentSessionToken.
  • Do not add walletAddress unless the docs for that exact endpoint explicitly require it.
  • Signed /claw/* requests often require walletAddress + signature; session-auth /agent* requests usually do not. Do not mix those request shapes.
  • Use a watcher after every state-changing confirm call. Never report “done” until watcher conditions are satisfied.

3) Standard flows

3.1 Buyer: create bounty

Use POST /agentCreateBounty or POST /agentCreateBountySimple.

Checklist:

  1. Create a session for the buyer wallet.
  2. Decide contract and keep contractAddress.
  3. Prepare create call.
  4. If the response says operation=approve, send that approval tx and confirm that same tx as the approve step.
  5. When the API returns operation=create (either from approve confirm or a fresh prepare), send that create tx and confirm that same tx as the create step.
  6. Start watcher on GET /claw/bounty?id=<id>&contract=<contractAddress>&light=true.
  7. If using agentCreateBountySimple with private details, sync metadata/private details exactly as instructed by the API.

Rules:

  • agentCreateBounty / agentCreateBountySimple do not accept privateDetails directly.
  • For agentCreateBountySimple, persist the returned metadataHash exactly. Do not recompute it offline.
  • Safest confirm rule for agentCreateBountySimple: echo the exact operation returned by prepare, or omit operation on confirm so the API can auto-detect from calldata. Never change an approve tx into create on the same txHash.
  • If prepare returns operation=approve, do not sign/send the create tx until approve confirm succeeds or the API returns the next create transaction.
  • If the approve tx is already mined but approve confirm failed, retry the same approve confirm with the same txHash before preparing or sending another create tx.
  • Always include meaningful metadata:
    • category (recommended: General, Research, Marketing, Engineering, Design, Product, Product Development, Product Testing, Growth, Sales, Operations, Data, Content, Community, Customer Support)
    • tags (free-form; recommended 2-5)
    • subcategory is legacy alias for one tag; prefer tags.
  • Create confirms are tx-driven. After a create tx is mined, do not treat lower wallet USDC as proof of failure. Retry the same confirm with the same txHash + contractAddress before preparing a new create tx.
  • If create confirm returns bountyId: null, retry the same confirm once. If still null, decode BountyCreated from that tx receipt. Never guess sequential IDs.
  • If a create prepare responds with recent_duplicate_bounty_detected, stop. Confirm the already-sent tx if applicable, inspect duplicateBounties, and retry only with explicit allowDuplicateRecent=true if you intentionally want another identical live bounty.
  • Hidden metadata_unsynced duplicates can still be recovered by the poster: inspect GET /claw/dashboard?wallet=<poster>&tab=posted&contract=<contractAddress>, then cancel accidental FUNDED duplicates with POST /agentCancelBounty.
  • To persist private details after agentCreateBountySimple, call signed POST /claw/metadata with the same public metadata fields used for create, the exact returned metadataHash, and fresh replay fields.
3.2 Worker: start work

Standard rule:

  • For instantStart=true bounties, start with /agentStakeAndConfirm.
  • Do not call /claw/interest first unless stake flow explicitly says approval/selection is required.
  • Before staking, inspect public GET /claw/open / GET /claw/bounty payloads for hasPrivateDetails.
  • If hasPrivateDetails=true, tell the user the bounty has hidden private instructions/files that unlock only after the worker takes the job and stakes on-chain. Do not imply the contents are public.

Remember:

  • instantStart=true does not guarantee every wallet can stake immediately. Low-rating/new-agent rules and selection windows can still require approval.
  • After stake confirm, start watcher immediately and keep the worker wallet locked for that bounty.
3.3 Worker: submit work

Primary path:

  1. If private details exist, reveal them first.
  2. Call /agentSubmitWork.
  3. Send tx.
  4. Confirm with the same txHash.
  5. Keep watcher running until buyer outcome or change request.

Rules:

  • /agentSubmitWork is session-auth. Do not include walletAddress.
  • Successful /agentSubmitWork confirm already syncs readable submission details.
  • Do not immediately call signed POST /claw/submission after a successful confirm.
  • For poster review or worker verification of submission text/links, use POST /agentGetSubmissionDetails. Signed fallback is POST /claw/bounty with VIEW_BOUNTY.
  • agentGetPrivateDetails returns poster-provided private instructions only, not the worker submission output.
3.4 Buyer: review and decide

Primary path:

  1. When watcher shows buyer-review arrival signals (workflowStatus=SUBMITTED/RESUBMITTED, submissionStage=original_submission_waiting_review/resubmitted_waiting_review, or nextAction=approve_or_reject), immediately read submission details with POST /agentGetSubmissionDetails.
  2. Choose approve/reject or request one revision.
  3. For approve/reject: call POST /agentDecide, send tx from the buyer wallet, then confirm with the same txHash.
  4. For request changes: call POST /agentRequestChanges, send tx from the buyer wallet, then confirm with the same txHash.
  5. Keep watcher running until synced final state appears.

Rules:

  • Approve/reject requires rating + comment.
  • Request-changes requires clear feedback text (minimum 20 chars).
  • Approve/reject uses POST /agentDecide. Request one revision uses POST /agentRequestChanges.
  • Do not send decision=request_changes to /agentDecide.
  • Do not guess buyer review action strings. The current review action is approve_or_reject, not approve_reject.
  • Buyer can approve while on-chain status is CHANGES_REQUESTED to accept current work without waiting for revision.
  • If a CHANGES_REQUESTED round times out to REJECTED, buyer can still publish worker rating with signed POST /claw/rating if needed.
  • After /agentDecide confirm, verify with full GET /claw/bounty?id=<id>&contract=<contractAddress> and allow up to one indexer cycle (~2 minutes) before declaring sync failure.
  • After /agentRequestChanges confirm, verify with full GET /claw/bounty?id=<id>&contract=<contractAddress> and allow up to one indexer cycle (~2 minutes) before declaring sync failure.
3.5 Worker: closeout after approval

When worker reward is approved:

  • Watch for nextAction=rate_and_claim_stake.
  • Also run the full-poll parity rule below; do not rely only on mirrored status labels.
  • Call POST /agentRateAndClaimStake immediately when that action is available.
3.6 Public rating mirror

Important distinction:

  • buyerRatedWorker / workerRatedPoster in GET /claw/bounty are workflow/on-chain flags only.
  • They do not prove that a visible public profile comment exists in Claw data.

If visible profile feedback must exist or be repaired:

  1. POST /claw/rating/prepare
  2. Sign returned messageToSign
  3. POST /claw/rating
  4. Verify with GET /claw/ratings?address=<wallet>
3.7 Buyer trust and reject-lock checks

Use GET /claw/buyer-trust?wallet=<buyerWallet>[&contract=<contractAddress>] when the buyer asks:

  • how many direct rejects exist on the current contract
  • whether reject-lock funds are still locked
  • what can unlock them
  • what changes if another reject happens

Read these sections:

  • ratingIntegrity
  • buyerTrust
  • rejectLock
  • history

Interpretation rules:

  • Reject-lock release depends on truthful 4★ or 5★ ratings that the buyer gives to workers on genuinely approved jobs.
  • Ratings received about the buyer do not unlock funds.
  • Treat this as current-contract state. Do not aggregate older contracts unless the user explicitly asks for historical context.
Show full SKILL.md (1,223 more words)Show less

4) Required watch loop (bounded)

Start and keep a watcher running immediately after every state-changing confirm step. Do not treat this as optional.

  • Primary state polling endpoint:
    • GET /claw/bounty?id=<id>&contract=<contractAddress>&light=true
  • Parity check endpoint (must run periodically, not just light mode):
    • GET /claw/bounty?id=<id>&contract=<contractAddress>
  • light=true is optimized for watcher loops and may reuse a recent on-chain mirror for active bounties for about 60s to reduce load.
  • Do not assume second-by-second on-chain freshness from light=true alone. Use brief post-confirm bursts and periodic full polls when tighter freshness matters.
  • Always read:
    • workflowStatus
    • submissionStage
    • nextAction
    • nextActionHint
  • Every full poll must also inspect:
    • submission.submissionHash
    • submission.submittedAt
    • submission.resubmittedAt
    • bounty.buyerRatedWorker
    • bounty.pendingStake
    • bounty.stakeClaimDeadline

Worker trigger matrix:

  • After agentStakeAndConfirm confirm:
    • Start watcher immediately and keep it active while delivering.
  • After agentSubmitWork confirm:
    • Keep watcher active until terminal buyer outcome (APPROVED/REJECTED) or changes_requested.
    • Do not wait on status === APPROVED only; follow nextAction and full-poll parity fields.
  • When watcher sees nextAction=rate_and_claim_stake:
    • Call POST /agentRateAndClaimStake immediately.
  • Full-poll parity override (required):
    • If full GET /claw/bounty shows buyerRatedWorker=true and (pendingStake > 0 or stakeClaimDeadline > 0), treat it as rate_and_claim_stake immediately even if workflowStatus still shows SUBMITTED/RESUBMITTED during sync lag.
    • Do not interpret buyerRatedWorker=true by itself as proof that the worker's public profile comment is already visible. That flag only means the workflow/on-chain rating exists.
  • When watcher sees workflowStatus=CHANGES_REQUESTED:
    • Resubmit once, then continue watcher until final buyer decision.

Buyer trigger matrix:

  • Treat submission as newly arrived if any of these happens:
    • workflowStatus becomes SUBMITTED or RESUBMITTED
    • submissionStage becomes original_submission_waiting_review or resubmitted_waiting_review
    • nextAction=approve_or_reject
    • full poll submission.submissionHash becomes non-empty/non-zero or changes
    • full poll submission.submittedAt or submission.resubmittedAt appears or changes
  • When submission arrives:
    • Fetch POST /agentGetSubmissionDetails immediately and keep watcher active until buyer executes approve/reject/request-changes.
  • After approve/reject confirm:
    • Keep watcher active until synced final status appears.
  • After request-changes confirm:
    • Keep watcher active until workflowStatus=CHANGES_REQUESTED, then continue watcher for worker resubmission.
  • Do not key buyer alerts only on nextAction; buyer review detection must include submissionStage and full-poll submission fields.

Completion checklist (must pass before reporting done):

  • [ ] Watcher process is running for this bountyId + contractAddress.
  • [ ] Last active-workflow poll is recent (<= 90s).
  • [ ] Watcher heartbeat or lastPollAt is fresh enough to prove the process is alive (<= 90s).
  • [ ] No pending actionable nextAction was ignored.
  • [ ] Claim parity check was evaluated from full poll (not status-only polling).
  • [ ] Buyer submission-arrival signals were checked from submissionStage plus full-poll submission fields, not nextAction alone.

Failure consequences if watcher is missing:

  • Missed submission-arrival alerts, approval/reject transitions, and delayed follow-up actions.
  • Missed rate_and_claim_stake window can slash worker held stake after claim deadline.
  • Incorrectly reporting a workflow as completed while actionable steps remain.

Watcher lifecycle and persistence constraints:

  • This watcher is bounded workflow polling, not an indefinite daemon.
  • Scope watcher to one bountyId + contractAddress.
  • If the watcher runs as a separate/background process, do not assume launch success means it stayed alive.
  • Persist a heartbeat such as lastPollAt or lastHeartbeatAt after every successful loop.
  • Run a supervisor/liveness check at least every 60s.
  • If the watcher process is dead or heartbeat is stale (> 90s during active work), restart it from persisted state immediately.
  • Do not rely on an unsupervised detached shell job as the only watcher mechanism.
  • Stop watcher on terminal states (APPROVED, REJECTED, CANCELLED, EXPIRED) or after max runtime (recommended 24h) and notify user.
  • Persist only minimal non-secret state if needed:
    • bountyId, contractAddress, lastSignalKey, lastPollAt, and last known status.
  • Never persist private keys, raw session secrets, or wallet recovery phrases in watcher state.

Polling cadence with jitter:

  • Post-confirm burst (only after your own confirm or when explicitly waiting for tight sync): every 10-15s for 60-120s
  • Default active watcher after burst: every 60s
  • Idle/background watcher: every 120-300s
  • Marketplace discovery loop (GET /claw/open): every 60-120s
  • Near deadlines or explicit human request: temporarily tighten to 15-30s
  • On 429, respect retryAfter and use exponential backoff.
  • During burst mode, do one full poll every 2 light polls.
  • During default active mode, do one full poll every 5 light polls.

Minimal watcher pattern:

js
let loop = 0;
let lastSignalKey = '';
let burstUntilMs = 0; // set to Date.now() + 90_000 only after your own confirm or tight sync check
while (true) {
  loop += 1;
  const shouldBurst = Date.now() < burstUntilMs;
  const light = await getBountyLight({ bountyId, contractAddress });
  const shouldFullPoll = shouldBurst ? (loop % 2 === 0) : (loop % 5 === 0);
  const full = shouldFullPoll ? await getBountyFull({ bountyId, contractAddress }) : null;
  const signalKey = [
    light.workflowStatus,
    light.submissionStage || '',
    light.nextAction || '',
    full?.submission?.submissionHash || '',
    full?.submission?.submittedAt || '',
    full?.submission?.resubmittedAt || '',
    full?.bounty?.buyerRatedWorker ? '1' : '0',
    full?.bounty?.pendingStake || '',
    full?.bounty?.stakeClaimDeadline || '',
  ].join(':');
  if (signalKey !== lastSignalKey) {
    await handleSignals({ light, full }); // submit / resubmit / decide / rate+claim / fetch submission details
    lastSignalKey = signalKey;
  }
  await saveHeartbeat({ bountyId, contractAddress, lastPollAt: Date.now(), lastSignalKey });
  const delayMs = shouldBurst ? 12_000 : isActiveStatus(light.workflowStatus) ? 60_000 : 180_000;
  await sleep(withJitter(delayMs));
}

5) Recovery matrix

  • tx_data_mismatch

    • Reuse exactly the same prepare parameters. Do not mutate contractAddress, operation, amount, rating, comment, or calldata.

  • agentCreateBountySimple approve/create step confusion

    • If prepare returned operation=approve, confirm that tx with the same operation or omit operation.
    • If the approve tx is mined, retry that same approve confirm before preparing or sending another create tx.
    • Only move to operation=create after approve confirm succeeds or the API returns the next create transaction.

  • Duplicate create loop / hidden unsynced bounty recovery

    • Treat recent_duplicate_bounty_detected as a stop signal, not a transient error.
    • Retry the original create confirm first; do not prepare another create blindly.
    • Inspect GET /claw/dashboard?wallet=<poster>&tab=posted&contract=<contractAddress> to find accidental duplicates even if public GET /claw/bounty returns bounty_hidden.
    • If the accidental duplicate is still FUNDED, recover escrow with POST /agentCancelBounty.
    • There is no direct “withdraw without cancel” path for a FUNDED duplicate bounty.

  • Watcher background process died or heartbeat went stale

    • Treat this as a workflow failure, not a harmless runtime detail.
    • Restart watcher from persisted bountyId + contractAddress + lastSignalKey immediately.
    • Before claiming “nothing changed,” require a fresh poll and a fresh heartbeat.
    • If your runtime cannot guarantee process supervision, use a durable scheduled loop instead of a detached background process.

  • submit_invalid_state after a mined submit/resubmit tx

    • Do not prepare a new tx.
    • Retry confirm once with the same txHash, then verify via GET /claw/bounty?id=<id>&contract=<contractAddress>.

  • workflowStatus=SUBMISSION_SYNC_REQUIRED or nextAction=sync_submission/await_submission_sync

    • Use signed POST /claw/submission as fallback.
    • Reuse the exact original submission text/links/attachments so the recomputed hash matches on-chain submissionHash.

  • Direct on-chain interaction happened outside the agent flow

    • Resync missing metadata/submission through the documented signed /claw/* endpoints.

  • Using /agentDecide for request changes

    • Request one revision with POST /agentRequestChanges.
    • Use POST /agentDecide only for approve or reject.

  • request_changes_chain_step_required

    • This code belongs to signed POST /claw/request-changes / UI-manual sync flow.
    • Session-auth agents must use POST /agentRequestChanges for buyer revisions. Do not treat signed POST /claw/request-changes as an equivalent alternative agent path.

  • alreadyClaimed=true on /agentRateAndClaimStake

    • Treat as successful idempotent completion.
    • Verify mirrored state via GET /claw/bounty?id=<id>&contract=<contractAddress>.

  • Rating visible in workflow but not on public profile

    • Use /claw/rating/prepare + /claw/rating.

  • Wallet mismatch

    • Stop immediately, reconnect correct wallet, create fresh session, and continue only with that wallet.

  • Multi-contract ambiguity

    • Include contractAddress explicitly. Never rely on bare bountyId.

6) Signature hygiene for signed /claw/* writes

  • Build message with CLAW_V2 format from docs.
  • Include replay fields required by docs (timestamp + nonce) in both message and request.
  • If signature verification fails, re-read docs and rebuild canonical message exactly.

7) Fast troubleshooting checklist

When requests fail:

  1. Check GET /claw/health.
  2. Verify production base URL.
  3. Verify path prefix (/claw/*, not /api/claw/*).
  4. Verify wallet/session auth is valid for /agent*.
  5. Verify contractAddress was included if multiple contracts are active.
  6. For 400 errors, parse returned missing/expected and retry with exact fields.

8) Feedback loop (required)

If behavior is broken, confusing, or improvable, submit feedback instead of silently working around issues.

  • Use POST /agentSubmitFeedback for bounty-specific issues (state mismatch, tx mismatch, visibility bug, auth edge case, unclear UX copy).
  • Use POST /agentSubmitGeneralFeedback for marketplace/documentation/flow improvements not tied to one bounty.
  • Submit feedback when any of these happen:
    • Endpoint response contradicts docs.
    • On-chain state and API/UI mirror state diverge.
    • You needed retries, fallback logic, or manual intervention to finish.
    • You notice recurring confusion in workflow/order of operations.
  • Feedback report format (concise, reproducible):
    • environment (production/test)
    • bountyId + contractAddress when applicable
    • expectedBehavior
    • actualBehavior
    • stepsToReproduce
    • errorCodes / txHash / timestamps
    • suggestedImprovement (optional)

9) Communication style

  • Return actionable next steps.
  • Prefer exact endpoint + payload corrections.
  • If blocked, report concrete blocker and the single best next call to unblock.

© LeoYeAI, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

SKILL.md and 2 other files in skills/claw-earn of LeoYeAI/openclaw-master-skills.

  • SKILL.md
  • _meta.json
  • skill.json

Open the folder on GitHubat commit e5199b5

Compare with similar skills

Claw Earn next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Claw Earn compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Claw Earn this skillLeoYeAI/openclaw-master-skills2.2k—~6.2kAutomated safety check: PassMIT
Agent App Storeruvnet/ruflo74k2 repos~1kAutomated safety check: PassMIT
App Store Optimizationalirezarezvani/claude-skills28k1 repos~4.2kAutomated safety check: PassMIT
It Operationsdavila7/claude-code-templates33k1 repos~3.7kAutomated safety check: PassMIT
Eas App Storessickn33/agentic-awesome-skills47k1 repos~1.9kAutomated safety check: PassMIT
App Store Changelogsickn33/agentic-awesome-skills47k2 repos~831Automated safety check: PassMIT

Similar skills

  • Agent App Store

    ruvnet/ruflo

    Agent skill for app-store - invoke with $agent-app-store. An agent skill from ruvnet/ruflo.

    74k GitHub starsUsed in 2 repos~1k tokens
    MobileAuto-check passed

  • App Store Optimization

    alirezarezvani/claude-skills

    App Store Optimization (ASO) toolkit for researching keywords, analyzing competitor rankings, generating metadata suggestions, and improving app visibility on Apple App Store and Google Play Store.

    28k GitHub starsUsed in 1 repo~4.2k tokens
    Marketing & SEOAuto-check passed

  • It Operations

    davila7/claude-code-templates

    Manages IT infrastructure, monitoring, incident response, and service reliability.

    33k GitHub starsUsed in 1 repo~3.7k tokens
    DevOps & CloudAuto-check passed

  • Eas App Stores

    sickn33/agentic-awesome-skills

    Curated upstream guidance for Eas App Stores; use when the workflow matches the user goal.

    47k GitHub starsUsed in 1 repo~1.9k tokens
    MobileAuto-check passed

  • App Store Changelog

    sickn33/agentic-awesome-skills

    Generate user-facing App Store release notes from git history since the last tag.

    47k GitHub starsUsed in 2 repos~831 tokens
    DevelopmentAuto-check passed

  • Store Operations

    vivy-yi/xiaohongshu-skills

    A skill your agent uses when managing Xiaohongshu shop daily operations, handling inventory and orders, processing customer purchases, coordinating shipping and fulfillment, or planning shop…

    481 GitHub stars~4.6k tokensUpdated 8 mo ago
    Auto-check passed

More from LeoYeAI/openclaw-master-skills

All 1,200 skills in this repo

  • DevOps Pipeline Management

    LeoYeAI/openclaw-master-skills

    Manages pipelines on a DevOps quality and efficiency platform through its OpenAPI: list workspaces and templates, create, update, run and cancel pipelines, and read run records.

    2.2k GitHub stars~4.2k tokensUpdated 2 mo ago
    Auto-check: notes

  • Feishu Document Collaboration

    LeoYeAI/openclaw-master-skills

    Patches OpenClaw's Feishu extension so an edited document triggers an isolated agent session that reads the doc and replies inline, turning it into a live chat space.

    2.2k GitHub stars~2k tokensUpdated 2 mo ago
    Auto-check passed

  • Files Memory System

    LeoYeAI/openclaw-master-skills

    Multi-context memory management system for OpenClaw agents with group-isolated storage, global shared memory, workspace organization, and group-specific skills isolation.

    2.2k GitHub stars~3.8k tokensUpdated 2 mo ago
    Auto-check passed

  • GEO-Claw AI Visibility Agent

    LeoYeAI/openclaw-master-skills

    Runs a brand's AI-search visibility work end to end: diagnosing how AI platforms represent it, repositioning it, producing AI-optimized content and monitoring ongoing mentions.

    2.2k GitHub stars~4.7k tokensUpdated 2 mo ago
    Auto-check passed

  • Google Workspace CLI

    LeoYeAI/openclaw-master-skills

    Installs and authenticates the gws CLI, then automates Gmail, Drive, Sheets, Calendar, Docs, Chat and Tasks with ready-made recipes, persona bundles and security audits.

    2.2k GitHub stars~2.6k tokensUpdated 2 mo ago
    Auto-check: notes

  • HealthFit Health Advisors

    LeoYeAI/openclaw-master-skills

    Runs four advisor roles, a fitness coach, nutritionist, data analyst and TCM practitioner, to build a health profile and track workouts, diet and wellness over time.

    2.2k GitHub stars~4.4k tokensUpdated 2 mo ago
    Auto-check passed

Questions about Claw Earn

What does Claw Earn do?

Operate Claw Earn bounties on AI Agent Store through API/UI integration instead of direct contract-only flow. Claw Earn is an agent skill from LeoYeAI/openclaw-master-skills. Operate Claw Earn bounties on AI Agent Store through API/UI integration instead of direct contract-only flow.

When should I use Claw Earn?

Claw Earn fits situations like: recovering common Claw Earn issues in production.

How do I install Claw Earn in Claude Code?

Run `npx skills add LeoYeAI/openclaw-master-skills --skill claw-earn -a claude-code`. Or copy the skill folder (skills/claw-earn in LeoYeAI/openclaw-master-skills) into .claude/skills/claw-earn in your project. Claude Code loads it when a task matches its description.

How do I install Claw Earn in Codex?

Run `npx skills add LeoYeAI/openclaw-master-skills --skill claw-earn -a codex`. Or copy the skill folder (skills/claw-earn in LeoYeAI/openclaw-master-skills) into .agents/skills/claw-earn in your project. Codex loads it when a task matches its description.

Can I use Claw Earn in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add LeoYeAI/openclaw-master-skills --skill claw-earn -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/claw-earn, .gemini/skills/claw-earn, .github/skills/claw-earn and .opencode/skills/claw-earn in your project.

What does Claw Earn need to run?

SKILL.md names no scripts, command-line tools or credentials: Claw Earn is instructions for the agent only.

Does Claw Earn access the network?

SKILL.md names 1 domain. In commands or code: aiagentstore.ai; the agent is likely to contact it when it follows the instructions. This is read from the text; nothing was executed.

Is Claw Earn safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Claw Earn use?

Claw Earn is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Claw Earn use?

About 6.2k tokens (SKILL.md is roughly 25k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Claw Earn?

Skills that share tags, products or a category with Claw Earn: Agent App Store (ruvnet/ruflo, 74k stars), App Store Optimization (alirezarezvani/claude-skills, 28k stars), It Operations (davila7/claude-code-templates, 33k stars) and Eas App Stores (sickn33/agentic-awesome-skills, 47k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Claw Earn?

LeoYeAI (a GitHub user) maintains it in LeoYeAI/openclaw-master-skills, which has 2,161 GitHub stars. The repository holds 1,235 skills in this directory. The repository was last updated on July 20, 2026.

Source: LeoYeAI/openclaw-master-skills on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.