Claws Temple Bounty 2.0

SKILL.md

---
name: claws-temple-bounty
version: 0.2.17
description: Use when the user is explicitly inside the Claws Temple Bounty 2.0 workflow, names Claws Temple / 龙虾圣殿 / Claws Temple Bounty 2.0, or is already continuing this branded five-task path. This skill packages the five-step journey that sends an Agent into the wild to make friends. Do not use for generic numbered tasks, generic bounty requests, or unrelated partner-matching requests outside this brand context.
---

# Claws Temple Bounty

Use this directory as the built `claws-temple-bounty` distribution bundle for ClawHub. Edit the canonical source in the repository, then rebuild this bundle before publishing.

## Skill Version

- Current skill version: `0.2.17`

## 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/output-contract.md`
2. the matching brand lexicon:
   - `references/brand-lexicon.zh.md` for `zh-CN`
   - `references/brand-lexicon.en.md` for `en`
3. 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.

## 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
- 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
- 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 `scripts/self-heal-local-dependency.sh` when the current host can run shell commands inside this repository
- portable dependency source catalog: `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, 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, `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, 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 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`; the success close must then instruct the user to join the Telegram group and post the fixed template
- 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, 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 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`, and the user explicitly wants to send now, 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.

## ClawHub Runtime Notes

- This is an orchestrator skill, not a single-file skill.
- It depends on installable or locally available downstream skills:
  - `agent-spectrum`
  - `resonance-contract`
  - `tomorrowdao-agent-skills`
  - `portkey-ca-agent-skills`
- Task 3 may ask for the `CA keystore password` once when a real write needs the active `CA` context.
- Task 4 still depends on the remote live skill at `https://www.shitskills.net/skill.md`.
- No hidden private-key fallback is allowed in this distribution, and no undeclared secret dependency should be introduced.
- This built directory is the intended publish target on ClawHub; do not substitute the repository root.