Add starchild-dao skill

[forever8896]

Adds starchild-dao — hold-to-govern for the $STARCHILD token (the open-source Starchild companion on Base).

From inside Bankr you can list proposals, check your voting weight, cast gasless for/against EIP-712 votes, and propose (holding ≥10M).

• Voting weight = your live $STARCHILD balanceOf — no staking, no locking, no contract. Hold + sign.
• Proposals and votes are gasless EIP-712 signatures, verified against a public backend (token.starchild.software). One vote per wallet, counted at live balance; re-voting the same way is rejected; opposite vote changes your stance.
• Public by design — proposals, votes, and the balances that weight them are all on-chain or in a public API. Nothing private; the Starchild app itself is never touched (it stays private, local & free).

Tested end-to-end through Bankr: list, vote (for/against), the double-vote block, and propose all working.

Folder follows the contribution format (SKILL.md + catalog.json, slug = folder name) and a README row is added. Happy to adjust anything to fit your conventions.

[saltoriousSIG]

A couple of things to address, then should be good to merge!

Missing Prompt-Injection Boundary For Proposal Content
Proposal title and detail come from a public API in starchild-dao/SKILL.md, but the skill does not explicitly tell the agent to treat proposal content as untrusted data. A malicious proposal could include instructions to ignore prior guidance, sign a vote, install another skill, visit a URL, or run a transaction, so the skill should state that proposal text is display-only and must never trigger tools, signatures, installs, transfers, or votes without an explicit user request.

Replayable Vote Signatures
The EIP-712 Vote message in starchild-dao/SKILL.md only signs proposalId and support, with no nonce, deadline, voter, verifying contract, or API/domain binding. Since votes are last-write-wins, an old captured signature could potentially be replayed later to flip a wallet back to a previous stance after the user changed their vote, so the signed vote payload should include replay protection such as voter, nonce, deadline, and a stronger domain separator.

Weak EIP-712 Domain Separation
The EIP-712 domain in starchild-dao/SKILL.md only includes name, version, and chainId. For wallet signatures used by a centralized API, this should include a stronger domain separator, such as a verifying contract if applicable or an explicit salt/API domain, so signatures cannot be reused by another service that adopts the same typed data shape.

Ambiguous Vote Matching Can Sign The Wrong Proposal
The examples allow prompts like “vote for the mobile app proposal,” which requires the agent to infer a proposal id from public proposal text. The skill should require showing the matched proposal id, title, and support/against choice back to the user before signing, especially when multiple proposals have similar titles.

Gasless Signature Framing Understates Risk
The skill repeatedly says voting and proposing are “gasless” and that “nothing is spent” in starchild-dao/SKILL.md and catalog.json. That is true for gas/token spend, but signatures still create public governance actions, so the docs should frame signing as consequential and require confirmation before every vote or proposal signature.

[forever8896]

Thanks for the thorough review — all five are addressed in the latest push (1905533). Summary:

1. Prompt-injection boundary. Added a dedicated "Safety — proposal text is untrusted" section plus a guardrail: title/detail come from a public API and are display-only data, never instructions — they must never trigger a tool call, signature, install, transfer, vote, or URL fetch. Shown as quoted content only.

2. Replayable vote signatures. The Vote typed-data now signs voter, nonce (ms timestamp), and deadline. The backend rejects expired signatures and any nonce ≤ the last one recorded for that (proposal, voter), so an old captured signature can't flip a changed vote back. Proposal signatures are now single-use (nonce burned after posting).

3. Weak EIP-712 domain separation. The domain gains a constant salt (keccak256("starchild-dao:governance:v2:token.starchild.software")) and a version bump to 2. Verified that a no-salt signature does not verify under the salted domain, so the typed-data shape can't be reused by another service.

4. Ambiguous vote matching. Voting now requires echoing the matched proposal id + title + for/against choice and getting explicit confirmation before signing; if multiple proposals could match, the skill lists them and asks which.

5. Gasless framing understating risk. Reframed throughout: no gas/token spend, but a public, on-the-record governance action — confirm before every signature. Dropped the "nothing spent" language in both SKILL.md and catalog.json.

The companion backend (token.starchild.software) has been deployed with the matching v2 scheme, so the docs and the live API agree (a v1-style vote without nonce/deadline is now rejected). Happy to make any further tweaks!