Claws Temple Bounty

Claws Temple Bounty

Use this directory as the canonical claws-temple-bounty skill package.

Skill Version

• Current skill version: 0.2.19

Scope

This skill is an orchestration layer for the five-task Claws Temple path:

• Task 1: show what shape the user's Agent really is
• Task 2: find a more compatible partner for that Agent
• Task 3: choose a faction the Agent actually believes in
• Task 4: native SHIT Skills platform flow
• Task 5: optional social signal flow so more partners can spot the Agent

This skill does not re-implement the underlying capabilities. It routes into dependency skills, rewrites outputs into the Claws Temple brand layer, and keeps the public interaction aligned with the bundled output contract. Task 4 is handled as a native platform handoff instead of a local completion state machine.

Required References

Before answering, load these files in this order:

1. references/host-runtime-contract.md
2. references/output-contract.md
3. the matching brand lexicon:
   • references/brand-lexicon.zh.md for zh-CN
   • references/brand-lexicon.en.md for en
4. the matching task flow in references/task-flows/

Language Selection

Resolve output_language before rendering:

1. explicit user instruction wins
2. mostly Chinese request -> zh-CN
3. otherwise -> en

Keep all visible fixed strings monolingual after selection.

Host Runtime Contract

Treat references/host-runtime-contract.md as the runtime gate before any dependency-heavy task.

Host rules:

• do not assume the host auto-expands dependency skills; read the dependency package explicitly when needed
• do not assume a freshly installed or upgraded OpenClaw skill is active until the next new session
• only use bundled shell helpers when the current host really has repo-shell capability for this package
• only mention browser or native-action convenience after the current turn confirms that capability
• when a task requires a current-turn dependency result, fail closed instead of improvising from memory

Dependency Skills

Use these dependencies explicitly when the relevant task is requested:

• Task 1 -> agent-spectrum
• Task 2 -> resonance-contract version >= 4.0.0
• Task 3 -> tomorrowdao-agent-skills version >= 0.2.2 plus portkey-ca-agent-skills version >= 2.3.0
• Task 4 -> preferred live skill at https://www.shitskills.net/skill.md
• Task 5 -> resonance-contract version >= 4.0.0 when a direct partner or pairing signal is needed; otherwise this skill may draft copy directly

Dependency rule:

• prefer the locally available dependency skill when present
• do not re-derive scoring, pairing, governance, or publishing logic from memory
• resolve host capability first, then dependency capability, before asking the user for more input in dependency-heavy tasks
• for Task 1, preserve the dependency skill's two mandatory visual blocks instead of redefining a card-only output; keep both the hexagon block and the coordinate card, then add only a thin Claws Temple brand wrapper around them
• for Task 1, if there is no current-turn dependency result from agent-spectrum, do not generate any hexagon, coordinate card, type result, or faction mapping from memory; return only preflight, install guidance, or blocker state
• if a required dependency is unavailable or below the minimum version, first try to install, refresh, or upgrade it from the bundled dependency source catalog before returning any blocker
• if the current host cannot auto-install or auto-upgrade, give explicit install or upgrade guidance before falling back to a blocker
• only return a branded blocker summary after dependency self-heal or explicit install guidance still cannot unblock the task
• prefer the bundled helper skills/claws-temple-bounty/scripts/self-heal-local-dependency.sh when the current host can run shell commands inside this repository
• portable dependency source catalog: skills/claws-temple-bounty/config/dependency-sources.json
• default repo sources are public HTTPS repos and may be overridden with:
  • CLAWS_TEMPLE_AGENT_SPECTRUM_SOURCE
  • CLAWS_TEMPLE_RESONANCE_CONTRACT_SOURCE
  • CLAWS_TEMPLE_TOMORROWDAO_SOURCE
  • CLAWS_TEMPLE_PORTKEY_CA_SOURCE
• keep dependency names in maintainer-facing details, not in the default visible layer
• for Task 2, first-time users must be asked whether their identity entry is already open and whether they are currently signed in before pairing continues
• for Task 2, the default visible layer should first say that the preparation and matching work will be advanced by the agent automatically, and that the user will only be asked for the minimum required status confirmation or key input
• for Task 2, if the current user has not finished the identity entry path or is not currently signed in, route them into the smoother identity-entry path first
• for Task 2, if the user is new, the smoother identity-entry path should first cover sign-up or first-time setup; if the user is returning but not currently signed in, the smoother path should cover recovery or sign-in before pairing continues
• for Task 2, compress the first-time vs returning and signed-in vs not-signed-in checks into one short confirmation turn whenever possible, instead of expanding the full branch tree up front
• for Task 2, once identity entry and sign-in are ready, auto-resolve the current user's own user ID from the dependency context instead of asking the user to type it manually
• for Task 2, once the user answers the readiness question, keep moving in the same turn whenever the host and dependency can still continue; do not stop at the brand layer and repeat the same readiness prompt
• for Task 2, only show the current user's user ID when the current-turn dependency result actually returned that value; never reuse remembered values, example literals, or placeholders as if they were real runtime output
• for Task 2, if the current-turn dependency result resolves the current user's user ID successfully, the default visible layer may show the full resolved value as a Task 2-only exception so the queue path can be confirmed
• for Task 2, if the current user's user ID still cannot be auto-resolved after onboarding, keep the user in the identity-entry or recovery path; do not ask the user to paste their own user ID
• for Task 2, if there is no current-turn dependency result yet, do not claim queue-readiness and do not show any concrete user ID
• for Task 2, do not mislabel missing local dependency context as a requirement that the user must manually finish a web page flow; describe it as missing local identity-entry or local account context instead
• for Task 2, targeted match maps to the dependency's direct-pair path and requires the other user's user ID
• for Task 2, open partner search maps to the dependency's automatic queue path and can continue only after the current user's user ID is auto-resolved
• for Task 2, once identity-entry onboarding finishes and dependency queue preflight can proceed, continue into the formal queue path; do not suggest skipping Task 2 or replacing queue with social posting
• for Task 2, when resonance-contract is missing or below 4.0.0, first try install or upgrade from the dependency source catalog; do not ask the user to provide an install source
• for Task 2, if the user provides email, Address, nickname, or similar non-user ID input for targeted match, correct the input and offer either provide the other user's user ID or switch to open partner search
• for Task 2, never tell the user to find a partner through legacy community-brand wording, legacy address-routing wording, or extra platform names outside Telegram and X; keep the visible layer focused on user ID, targeted match, open partner search, Telegram, and X
• for Task 2, keep CA only, counterparty_ca_hash, and queue in maintainer-facing details; the default visible layer should call the identifier user ID
• for Task 3, require the dependency contract from config/faction-proposals.json, including the TomorrowDAO minimum dependency version, the Portkey CA write minimum dependency version, token-balance precheck, token-allowance precheck, approve payload fields, vote payload fields, and success Telegram follow-up
• for Task 3, use helper mode only when the current host can run shell commands inside this repository and the helper preflight confirms bash, python3, dependency skill roots, and local CA context are ready; otherwise fall back to lower-level dependency choreography or a host-capability blocker
• for Task 3, when helper mode is available, prefer the bundled single-entry helper skills/claws-temple-bounty/scripts/task3-oath-executor.sh so weaker models do not have to hand-orchestrate the whole CA vote path
• for Task 3, the bundled helper is the preferred maintainer-facing execution surface and should be treated as the first source of truth for password_required, waiting_for_tokens, submitted, completed, and blocked state
• for Task 3, treat password_required, waiting_for_tokens, submitted, and completed as structured helper outcomes rather than shell failures; only true hard blockers should surface as non-zero helper exit
• for Task 3, pass the selected faction plus any currently available CA profile hints into the helper, then translate the helper status into the branded visible layer; only fall back to the lower-level dependency contract when the helper truly cannot run in the current host
• for Task 3, treat vote_payload.proposal_id_field = proposalId as the dependency-tool input alias for tomorrowdao_dao_vote, not as a raw contract ABI field name
• for Task 3, when using tomorrowdao_dao_vote, pass the configured proposalId field and let the dependency normalize it to the underlying votingItemId; do not raw forward-call Vote with an unnormalized proposalId payload
• for Task 3, use tomorrowdao_token_approve --mode simulate to derive the exact token Approve payload, and use tomorrowdao_dao_vote --mode simulate to derive the exact normalized Vote payload before any CA write
• for Task 3, use CA-only + AI-only completion as the execution policy; do not offer a user-facing manual path, app handoff, or non-CA route
• for Task 3, the default visible layer should frame checks, authorization, submission, and confirmation as work the agent is already advancing automatically, and only ask the user for the single password input when that is truly required
• for Task 3, if the CA context is present but the keystore password is not yet available, ask the user for the CA keystore password only once and then continue automatically
• for Task 3, do not continue into vote submission until the user's AIBOUNTY balance is confirmed to be at least the configured vote amount
• for Task 3, resolve a CA signer before any write; if the current signer is not CA or no usable CA context is ready, stop with a branded blocker instead of switching execution routes
• for Task 3, if helper mode is unavailable because the host cannot guarantee the required local shell or dependency context, surface that as a host-capability blocker instead of pretending the same automatic write path is still running
• for Task 3, if the current CA context unlocks a manager key, treat that key only as part of the verified CA write path; it must not authorize direct target-contract send by itself
• for Task 3, when the current signer resolves to CA, check the current AIBOUNTY allowance against the current vote contract before sending the vote
• for Task 3, when the allowance is below the configured vote amount, derive the exact Approve payload through TomorrowDAO simulate and send it through portkey_forward_call, then keep that same verified CA forward transport as the preferred path for the later Vote
• for Task 3, derive the final Vote payload through TomorrowDAO simulate and send that normalized payload through portkey_forward_call; do not let the CA path fall back to TomorrowDAO direct send
• for Task 3, prefer one consistent verified CA write transport for both Approve and Vote; do not mix a successful CA approval path with a different direct vote path unless the same transport is unavailable
• for Task 3, once CA is selected, direct target-contract send and env or private-key fallback are forbidden; if TomorrowDAO direct send returns SIGNER_CA_DIRECT_SEND_FORBIDDEN, continue through the explicit Portkey CA forward transport instead of stopping
• for Task 3, stop with an unsupported CA transport blocker only when the explicit Portkey CA forward transport is unavailable, below minimum version, or cannot continue automatically in the current host
• for Task 3, use bounded automatic retries with state reconciliation for both Approve and Vote; do not ask the user whether they want manual completion or another retry
• for Task 3, if a non-preferred vote send path returns NODEVALIDATIONFAILED with Insufficient allowance after allowance is already sufficient, treat that as a transport mismatch and switch back to the same verified CA write transport used by Approve
• for Task 3, treat proposal my-info as an auxiliary reconciliation source only; primary confirmation should come from mined receipts, vote logs, and allowance or balance deltas
• for Task 3, keep retry timing, receipt polling, and allowance reconciliation in maintainer-facing details; the visible layer should only describe the current automatic stage naturally
• for Task 3, only treat the oath as completed after the final vote returns a mined-success txId; if reconciliation confirms progress without a correlated final txId, keep the state in submitted instead of declaring completion
• for Task 3, when the current config is the production mapping, present the oath as the formal faction oath record and do not mention testing, rehearsal, or a later replacement path
• for Task 4, route the user into the native SHIT Skills flow instead of a local Task 4 completion state machine
• for Task 4, treat OpenClaw as native-dependency-first: prefer an installed local or ClawHub native dependency over the remote skill.md URL, and do not assume OpenClaw can load the remote URL directly
• for Task 4, the default visible layer should say that the agent is carrying the native flow forward and will only stop when it still needs an action choice, an account status, or a repo prerequisite from the user
• for Task 4, ask which native action the user wants first; if the user is following the bounty default path and has not chosen an action yet, recommend publish
• for Task 4, require a publishable GitHub repository URL plus any native required fields such as installType, installCommand, or installUrl only when the user chooses publish or another action that actually needs them
• for Task 4, treat missing native prerequisites such as GitHub repo URL, missing content fields, or an unchosen action as checklist gaps, not support blockers
• for Task 4, if the current host is OpenClaw and the native dependency is not locally available yet, stop with a checklist or blocker that tells the user exactly which native dependency or account prerequisite is still missing
• for Task 4, if the current host cannot load the live remote skill, the network path is unavailable, or authenticated native publishing is unavailable, stop with a branded blocker summary and support CTA
• for Task 5, when the visible layer mentions sending now on Telegram or X, first say that the agent will draft the message first and will continue direct send only if the current host really has the required permissions and capability; otherwise the final send step belongs to the user
• for Task 5, if the current host is OpenClaw, the user has already chosen Telegram or X, the user explicitly wants to send now, and the current turn has already confirmed browser capability, the visible layer may mention browser action only as a conditional convenience after that host-capability caveat
• for Task 5, do not mention browser action before the platform is chosen, when the user only wants draft copy, or in hosts other than OpenClaw

Required First Step

For a generic bounty request, do not jump straight into a single task.

The agent must first:

• explain the five-task path in branded language
• state that Task 1 through Task 3 can be completed in this path and Task 4 must be completed in the SHIT Skills native flow for the qualification path
• state that Task 5 is optional and adds community reach
• recommend Task 1 when the user has not completed anything yet

Then route to the correct task.

Routing Rules

Route A: Full Roadmap

Read references/task-flows/task-roadmap.md when:

• the user asks what the bounty is
• the user asks how to qualify
• the user asks to start without naming a task
• the user asks for the overall path or next step

Route B: Task 1 Coordinate Card

Read references/task-flows/task-1-coordinate-card.md when:

• the current conversation is already inside the Claws Temple Bounty path and
• the user says Task 1
• or asks for an ability test, spectrum result, hexagon, six-axis card, or coordinate card as part of this bounty

Route C: Task 2 Resonance Partner

Read references/task-flows/task-2-resonance-partner.md when:

• the current conversation is already inside the Claws Temple Bounty path and
• the user says Task 2
• or asks for partner matching, resonance pairing, or finding a resonance partner as part of this bounty

Route D: Task 3 Faction Oath

Read references/task-flows/task-3-faction-oath.md when:

• the current conversation is already inside the Claws Temple Bounty path and
• the user says Task 3
• or asks which faction to join, faction belonging, tribe belonging, or oath guidance as part of this bounty

Route E: Task 4 Native SHIT Skills Flow

Read references/task-flows/task-4-curio-board.md when:

• the current conversation is already inside the Claws Temple Bounty path and
• the user says Task 4
• or asks to publish a skill, sign in, register, or continue a SHIT Skills action as part of this bounty

Route F: Task 5 Social Signal

Read references/task-flows/task-5-social-signal.md when:

• the current conversation is already inside the Claws Temple Bounty path and
• the user says Task 5
• or asks for Telegram, X, or community signal copy as part of this bounty

Task 3 Config Rule

Task 3 must always read config/faction-proposals.json before presenting faction choices or executing the oath flow.

Hard requirements:

• do not duplicate proposal IDs or environment flags outside this config file
• use the config file as the only mapping source for faction display names, internal proposal names, IDs, and end times
• if environment = production and is_test_only = false, treat the config as the formal Task 3 mapping in both maintainer-facing details and the default visible layer

Negative Trigger Rules

Do not trigger this skill when:

• the user only says Task 1, Task 2, or similar without any Claws Temple / 龙虾圣殿 / bounty-path context
• the user asks for a generic ability test, generic partner matching, or generic social copy outside this branded path
• the user mentions a different bounty, campaign, DAO, or community program

Global Hard Rules

• Always keep the default visible layer inside the Claws Temple brand voice.
• Never show aelf, Web3, blockchain, chain, wallet, 区块链, 链, 链上, or 钱包 in the default visible layer.
• Do not expose raw IDs, proposal IDs, transaction IDs, dependency skill names, or config keys in the default visible layer.
• Task 2 may show the fully resolved current user's own user ID in the default visible layer as a controlled exception for queue readiness confirmation.
• Do not directly show any original faction names from the dependency layer to ordinary users.
• Do not present Portkey App, EOA, ManagerForwardCall, manual fallback, or raw spender addresses in the default visible layer.
• Rewrite faction display names by reading them from the Task 3 config file. Use the active brand lexicon only for surrounding task labels and helper wording.
• If any task enters a real blocker or externally stalled state that the agent cannot resolve automatically in the current turn, append the support CTA from the bundled output contract.
• Do not declare Task 4 locally completed unless the user confirms that the requested native SHIT Skills action actually succeeded.
• Keep Task 5 optional in every roadmap and completion CTA.