Agent Skills

Quick summary

Skills tell agents when and in what order to call tools. They are instructions, not a second runtime or a bypass around CLI approval and backend authorization.

Pick yetdapay-install, yetdapay-protect, yetdapay-license, or yetdapay-verify by task and require evidence after any change.

Four ready-made skill manifests live in skills/ — each is a SKILL.md with frontmatter (name, description) an agent runtime can load. They encode the honest-status discipline and the tool sequences; they carry no code of their own.

Skill	File	Use it when a user asks to…
yetdapay-install	skills/yetdapay-install/SKILL.md	Add donation/feedback surfaces to a website — hosted link (<a> to {SITE_ORIGIN}/h/{public_id}) or native SDK widget. Covers framework analysis, public_id handling, and the install checklist.
yetdapay-protect	skills/yetdapay-protect/SKILL.md	Run the protect pipeline on a module — init → analyze → plan → review → user approval → apply → verify, via yp-mcp tools or the yp CLI directly.
yetdapay-license	skills/yetdapay-license/SKILL.md	Inspect the server-side license lifecycle — list/get licenses, PoP bindings, usage, security events — plus public license verification.
yetdapay-verify	skills/yetdapay-verify/SKILL.md	Interpret evidence — read .devpay/evidence/*.record.json, run protect verify, interpret license-verify verdicts.

Common discipline encoded in all four

• Scope separation. Seller-scope work needs a credential; public surfaces get only public_id. Skills refuse to mix them.
• planned ≠ applied ≠ verified. Evidence words are propagated literally — PARTIALLY_VERIFIED is not upgraded to success.
• Read before write. Inspection tools run first; the apply stage is gated on the user approving the exact plan shas.
• Sandbox honesty. Donations are status:"sandbox" — never real money; the skills say so rather than implying payment capture.

How skills map to MCP servers

Skill	Primary surface
yetdapay-install	Gateway tools yetdapay_integration_* / yetdapay_*_configure + prompt setup_donation_and_feedback
yetdapay-protect	yp-mcp tools yetdapay_project_analyze … yetdapay_protection_verify + prompt protect_project
yetdapay-license	Gateway read tools yetdapay_license_*, yetdapay_usage_counters, yetdapay_security_events, yetdapay_license_verify (or the equivalent REST endpoints)
yetdapay-verify	yp-mcp verify + .devpay/evidence/ records + public /licenses/verify

Guardrails worth knowing

• yetdapay-protect requires the user to approve the current plan shas — yetdapay_protection_apply without approved:true is refused before the CLI runs, and sha drift re-binds only through a fresh plan.
• yetdapay-license distinguishes seller inspection (credential required) from buyer/public verification (key-in/verdict-out, unauthenticated) — there is no buyer self-service API; email is not a credential.
• yetdapay-install never invents credentials in generated code and treats AGENT/MANUAL_REVIEW outcomes as handoffs, not produced code.