@receiz/ai-skills 102.0.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +45 -0
- package/package.json +31 -0
- package/receiz-builder-skill/SKILL.md +92 -0
- package/receiz-builder-skill/examples/create-marketplace.md +10 -0
- package/receiz-builder-skill/examples/create-pack-app.md +12 -0
- package/receiz-builder-skill/examples/create-profile-vault.md +5 -0
- package/receiz-builder-skill/examples/create-proof-page.md +5 -0
- package/receiz-builder-skill/examples/create-storefront.md +5 -0
- package/receiz-builder-skill/resources/app-patterns.md +29 -0
- package/receiz-builder-skill/resources/deployment-checklist.md +13 -0
- package/receiz-builder-skill/resources/generated-code-rules.md +27 -0
- package/receiz-builder-skill/resources/no-db-pattern.md +34 -0
- package/receiz-builder-skill/resources/proof-native-ui-patterns.md +29 -0
- package/receiz-builder-skill/resources/sdk-quickstart.md +68 -0
- package/receiz-commerce-skill/SKILL.md +95 -0
- package/receiz-commerce-skill/examples/create-no-db-store.md +15 -0
- package/receiz-commerce-skill/examples/create-product-page.md +25 -0
- package/receiz-commerce-skill/examples/explain-receiz-commerce.md +14 -0
- package/receiz-commerce-skill/examples/verify-product-ownership.md +20 -0
- package/receiz-commerce-skill/resources/commerce-object-model.md +44 -0
- package/receiz-commerce-skill/resources/conversion-copy-patterns.md +23 -0
- package/receiz-commerce-skill/resources/order-and-receipt-boundaries.md +29 -0
- package/receiz-commerce-skill/resources/product-proof-flow.md +26 -0
- package/receiz-commerce-skill/resources/seller-buyer-language.md +26 -0
- package/receiz-commerce-skill/resources/storefront-patterns.md +33 -0
- package/receiz-distribution-skill/SKILL.md +94 -0
- package/receiz-distribution-skill/examples/create-bar-flyer-copy.md +18 -0
- package/receiz-distribution-skill/examples/create-restaurant-activation.md +20 -0
- package/receiz-distribution-skill/examples/create-venue-one-pager.md +15 -0
- package/receiz-distribution-skill/examples/explain-pack-derby.md +9 -0
- package/receiz-distribution-skill/resources/affiliate-boundaries.md +23 -0
- package/receiz-distribution-skill/resources/conversion-language.md +20 -0
- package/receiz-distribution-skill/resources/pack-derby-model.md +19 -0
- package/receiz-distribution-skill/resources/qr-activation-flow.md +24 -0
- package/receiz-distribution-skill/resources/staff-training-script.md +17 -0
- package/receiz-distribution-skill/resources/venue-playbook.md +25 -0
- package/receiz-mcp-agent-skill/SKILL.md +89 -0
- package/receiz-mcp-agent-skill/examples/agent-append-proof.md +11 -0
- package/receiz-mcp-agent-skill/examples/agent-build-app.md +10 -0
- package/receiz-mcp-agent-skill/examples/agent-inspect-vault.md +8 -0
- package/receiz-mcp-agent-skill/examples/agent-verify-object.md +3 -0
- package/receiz-mcp-agent-skill/resources/action-confirmation-rules.md +22 -0
- package/receiz-mcp-agent-skill/resources/agent-operating-rules.md +28 -0
- package/receiz-mcp-agent-skill/resources/auth-boundaries.md +21 -0
- package/receiz-mcp-agent-skill/resources/mcp-tool-map.md +61 -0
- package/receiz-mcp-agent-skill/resources/response-templates.md +38 -0
- package/receiz-mcp-agent-skill/resources/safe-tool-calling.md +45 -0
- package/receiz-offline-verifier-skill/SKILL.md +91 -0
- package/receiz-offline-verifier-skill/examples/debug-verification-failure.md +17 -0
- package/receiz-offline-verifier-skill/examples/explain-offline-proof.md +9 -0
- package/receiz-offline-verifier-skill/examples/verify-offline-asset.md +19 -0
- package/receiz-offline-verifier-skill/resources/airplane-mode-principle.md +15 -0
- package/receiz-offline-verifier-skill/resources/artifact-over-server.md +22 -0
- package/receiz-offline-verifier-skill/resources/offline-verification-law.md +17 -0
- package/receiz-offline-verifier-skill/resources/security-boundaries.md +20 -0
- package/receiz-offline-verifier-skill/resources/verifier-flow.md +25 -0
- package/receiz-proof-skill/SKILL.md +98 -0
- package/receiz-proof-skill/examples/verify-card.md +21 -0
- package/receiz-proof-skill/examples/verify-pack.md +14 -0
- package/receiz-proof-skill/examples/verify-post.md +7 -0
- package/receiz-proof-skill/examples/verify-product.md +7 -0
- package/receiz-proof-skill/examples/verify-vault.md +7 -0
- package/receiz-proof-skill/resources/failure-modes.md +31 -0
- package/receiz-proof-skill/resources/mcp-tool-map.md +49 -0
- package/receiz-proof-skill/resources/output-templates.md +56 -0
- package/receiz-proof-skill/resources/proof-object-model.md +30 -0
- package/receiz-proof-skill/resources/receiz-laws.md +41 -0
- package/receiz-proof-skill/resources/sdk-reference.md +80 -0
- package/receiz-proof-skill/resources/verification-flow.md +38 -0
- package/receiz-skill-bundle/SKILL.md +87 -0
- package/receiz-skill-bundle/resources/canonical-receiz-language.md +46 -0
- package/receiz-skill-bundle/resources/combined-agent-behavior.md +35 -0
- package/receiz-skill-bundle/resources/skill-routing.md +15 -0
- package/receiz-skill-bundle/resources/when-to-use-each-skill.md +29 -0
- package/receiz-sports-card-skill/SKILL.md +97 -0
- package/receiz-sports-card-skill/examples/explain-card-market.md +18 -0
- package/receiz-sports-card-skill/examples/explain-geo-appeal.md +9 -0
- package/receiz-sports-card-skill/examples/explain-live-event-card.md +18 -0
- package/receiz-sports-card-skill/examples/explain-pack-opening.md +10 -0
- package/receiz-sports-card-skill/examples/explain-player-card.md +19 -0
- package/receiz-sports-card-skill/resources/card-memory-law.md +23 -0
- package/receiz-sports-card-skill/resources/game-surface-patterns.md +26 -0
- package/receiz-sports-card-skill/resources/live-event-append-flow.md +19 -0
- package/receiz-sports-card-skill/resources/mlb-proof-language.md +24 -0
- package/receiz-sports-card-skill/resources/rarity-and-event-language.md +25 -0
- package/receiz-sports-card-skill/resources/sports-card-object-model.md +22 -0
|
@@ -0,0 +1,23 @@
|
|
|
1
|
+
# Conversion Copy Patterns
|
|
2
|
+
|
|
3
|
+
Receiz conversion copy must sell the proof-native value without weakening primitives.
|
|
4
|
+
|
|
5
|
+
## Product Page Copy
|
|
6
|
+
|
|
7
|
+
- "Inspect the proof object before you buy."
|
|
8
|
+
- "Ownership and provenance travel with the artifact."
|
|
9
|
+
- "Receipt proof records the purchase boundary."
|
|
10
|
+
- "Public proof keeps the object legible beyond this storefront."
|
|
11
|
+
|
|
12
|
+
## Storefront Copy
|
|
13
|
+
|
|
14
|
+
- "Every visible product is a proof object."
|
|
15
|
+
- "Storefront state projects verified product truth."
|
|
16
|
+
- "Checkout begins a settlement route; proof records the result."
|
|
17
|
+
|
|
18
|
+
## Avoid
|
|
19
|
+
|
|
20
|
+
- Generic trust badges without proof.
|
|
21
|
+
- Claims of authenticity without verification.
|
|
22
|
+
- Language that makes the storefront or server the source of truth.
|
|
23
|
+
- Pressure copy that hides ownership, settlement, or receipt boundaries.
|
|
@@ -0,0 +1,29 @@
|
|
|
1
|
+
# Order And Receipt Boundaries
|
|
2
|
+
|
|
3
|
+
Orders, receipts, certificates, and notes are separate proof boundaries.
|
|
4
|
+
|
|
5
|
+
## Order
|
|
6
|
+
|
|
7
|
+
An order is a purchase route state. It may show buyer intent, checkout session, status, and merchant processing, but it is not stronger than receipt proof or artifact truth.
|
|
8
|
+
|
|
9
|
+
## Receipt
|
|
10
|
+
|
|
11
|
+
A receipt is proof-bearing when it includes deterministic identity, payload, provenance, and inspection or verification behavior. Do not claim receipt proof until that boundary exists.
|
|
12
|
+
|
|
13
|
+
## Certificate
|
|
14
|
+
|
|
15
|
+
A certificate is a proof object that can carry value or certification state. Do not describe it as a listing.
|
|
16
|
+
|
|
17
|
+
## Note
|
|
18
|
+
|
|
19
|
+
A note issue route is a settlement primitive. Do not downgrade it to checkout copy or a balance display.
|
|
20
|
+
|
|
21
|
+
## Reporting
|
|
22
|
+
|
|
23
|
+
Always separate:
|
|
24
|
+
|
|
25
|
+
- What the buyer selected.
|
|
26
|
+
- What the seller claims.
|
|
27
|
+
- What checkout attempted.
|
|
28
|
+
- What settlement or receipt proof exists.
|
|
29
|
+
- What remains unverified.
|
|
@@ -0,0 +1,26 @@
|
|
|
1
|
+
# Product Proof Flow
|
|
2
|
+
|
|
3
|
+
Use this order whenever a commerce task includes a product, storefront, order, receipt, or buyer claim.
|
|
4
|
+
|
|
5
|
+
## Read Flow
|
|
6
|
+
|
|
7
|
+
1. Identify the public proof URL, artifact ID, product manifest, or storefront object ID.
|
|
8
|
+
2. Resolve and inspect the product proof with `receiz_asset_by_url`, `receiz_asset_by_id`, or `receiz_inspect_proof_object`; use SDK `verification.verifyArtifact(file)` when a verified integrity-and-continuity verdict is required.
|
|
9
|
+
3. Resolve storefront projection with `receiz_public_store_resolve` only after the proof boundary is named.
|
|
10
|
+
4. Compare product proof, seller claim, price display, and receipt state.
|
|
11
|
+
5. Report missing or conflicting evidence directly.
|
|
12
|
+
|
|
13
|
+
## Write Flow
|
|
14
|
+
|
|
15
|
+
1. Confirm the user asked for a write.
|
|
16
|
+
2. Confirm the exact product object, seller identity, store target, and value-affecting terms.
|
|
17
|
+
3. Use `receiz_public_store_publish` for public store append.
|
|
18
|
+
4. Use checkout or payment rails only through confirmed SDK/MCP action.
|
|
19
|
+
5. Report the resulting proof URL, append result, receipt boundary, and any remaining unverified state.
|
|
20
|
+
|
|
21
|
+
## Failure Handling
|
|
22
|
+
|
|
23
|
+
- If the product proof fails, do not publish or sell it.
|
|
24
|
+
- If ownership is missing, say ownership is not proven.
|
|
25
|
+
- If price is present without settlement context, call it display price only.
|
|
26
|
+
- If receipt proof is absent, do not claim purchase proof.
|
|
@@ -0,0 +1,26 @@
|
|
|
1
|
+
# Seller Buyer Language
|
|
2
|
+
|
|
3
|
+
## Seller Language
|
|
4
|
+
|
|
5
|
+
- "This seller presents a verified product proof object."
|
|
6
|
+
- "Seller custody is proven by the current ownership surface."
|
|
7
|
+
- "The listing projection references proof identity."
|
|
8
|
+
- "The seller claim is unverified until ownership proof resolves."
|
|
9
|
+
|
|
10
|
+
## Buyer Language
|
|
11
|
+
|
|
12
|
+
- "The buyer is acquiring a proof-bearing object."
|
|
13
|
+
- "The receipt proof records the purchase boundary."
|
|
14
|
+
- "The checkout route is value-affecting and requires confirmation."
|
|
15
|
+
- "The buyer should inspect product proof before purchase."
|
|
16
|
+
|
|
17
|
+
## Do Not Say
|
|
18
|
+
|
|
19
|
+
- "The database proves the seller owns this."
|
|
20
|
+
- "The marketplace card proves authenticity."
|
|
21
|
+
- "The checkout page is the source of truth."
|
|
22
|
+
- "This is just an online store."
|
|
23
|
+
|
|
24
|
+
## Settlement Terms
|
|
25
|
+
|
|
26
|
+
Use display price for visible price. Use settlement route, funded event, certificate value, note issue value, or reserve state only when the proof or rail establishes that boundary.
|
|
@@ -0,0 +1,33 @@
|
|
|
1
|
+
# Storefront Patterns
|
|
2
|
+
|
|
3
|
+
## No-Database Store
|
|
4
|
+
|
|
5
|
+
A no-database Receiz store reads public proof objects and public store state, then renders deterministic projections. It may use local state for interaction, but local state cannot outrank proof.
|
|
6
|
+
|
|
7
|
+
Core SDK rails:
|
|
8
|
+
|
|
9
|
+
- `createReceizClient`
|
|
10
|
+
- `receiz.publicStore.resolve`
|
|
11
|
+
- `receiz.publicStore.publish`
|
|
12
|
+
- `receiz.publicStore.publishWithIdentityProof`
|
|
13
|
+
- `receiz.appState.resolve`
|
|
14
|
+
- `receiz.verification.verifyArtifact`
|
|
15
|
+
- `receiz.connect.checkout`
|
|
16
|
+
- `receiz.connect.checkoutSession`
|
|
17
|
+
- `receiz.sandbox.seedStore`
|
|
18
|
+
- `receiz.sandbox.checkout`
|
|
19
|
+
|
|
20
|
+
## Storefront First Paint
|
|
21
|
+
|
|
22
|
+
Paint known verified product truth immediately. Background sync may append verified additions, but must not replace the settled product shell with a loading state.
|
|
23
|
+
|
|
24
|
+
## Public Store Projection
|
|
25
|
+
|
|
26
|
+
Public store state is a projection. Present it beneath product proof, ownership proof, and settlement proof.
|
|
27
|
+
|
|
28
|
+
## Generated App Requirements
|
|
29
|
+
|
|
30
|
+
- Show product proof identity near the purchase action.
|
|
31
|
+
- Show ownership or custody state when available.
|
|
32
|
+
- Show receipt and settlement boundaries separately.
|
|
33
|
+
- Use explicit action confirmation for payment, transfer, publish, and receipt append.
|
|
@@ -0,0 +1,94 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: receiz-distribution-skill
|
|
3
|
+
description: Use when an agent must create, explain, or operate Receiz QR activation, Pack Derby, venue activation, restaurant or bar playbooks, affiliate boundaries, staff scripts, conversion language, or physical-to-proof distribution.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# receiz-distribution-skill
|
|
7
|
+
|
|
8
|
+
Receiz distribution turns physical attention into proof-native activation. QR codes, venue posters, Pack Derby, affiliate routes, and staff scripts must preserve proof identity, consent, settlement boundaries, and public proof surfaces.
|
|
9
|
+
|
|
10
|
+
## When To Use This Skill
|
|
11
|
+
|
|
12
|
+
- Use for bar flyers, restaurant activation, venue one-pagers, Pack Derby explanation, QR activation, affiliate copy, staff scripts, and conversion language.
|
|
13
|
+
- Use when distribution copy must explain proof objects to buyers, collectors, venues, or staff.
|
|
14
|
+
- Use before creating physical activation materials tied to Receiz proof or sports cards.
|
|
15
|
+
|
|
16
|
+
## When Not To Use This Skill
|
|
17
|
+
|
|
18
|
+
- Do not use to verify a specific object. Use `receiz-proof-skill` or `receiz-offline-verifier-skill`.
|
|
19
|
+
- Do not use to execute writes, checkout, transfers, or pack opens without `receiz-mcp-agent-skill`.
|
|
20
|
+
- Do not use to claim venue partnership, official league status, or affiliate terms unless proof or user-supplied terms establish them.
|
|
21
|
+
|
|
22
|
+
## Core Receiz Laws
|
|
23
|
+
|
|
24
|
+
- QR activation points to proof-native rails; the QR itself is not the proof authority.
|
|
25
|
+
- Pack Derby and venue surfaces must preserve card proof, pack proof, event proof, and settlement boundaries.
|
|
26
|
+
- Staff language must not invent ownership, value, rarity, or official endorsement.
|
|
27
|
+
- Conversion copy must invite inspection, not hide proof.
|
|
28
|
+
- Never treat a database, server, marketplace, UI, model response, or cache as final authority.
|
|
29
|
+
- Affiliate and venue routes are distribution mechanics beneath proof truth.
|
|
30
|
+
- Read [resources/qr-activation-flow.md](resources/qr-activation-flow.md) before creating activation copy.
|
|
31
|
+
|
|
32
|
+
## Required Behavior
|
|
33
|
+
|
|
34
|
+
1. Name the activation primitive: public proof surface, QR activation, Pack Derby, venue route, affiliate route, proof object, or settlement route.
|
|
35
|
+
2. Identify what the QR or physical material opens.
|
|
36
|
+
3. Separate promotional copy from verified proof claims.
|
|
37
|
+
4. Include staff-safe language and buyer-safe action.
|
|
38
|
+
5. Require confirmation for pack open, purchase, transfer, settlement, or publish actions.
|
|
39
|
+
6. Use [resources/conversion-language.md](resources/conversion-language.md) for public copy.
|
|
40
|
+
|
|
41
|
+
## Forbidden Behavior
|
|
42
|
+
|
|
43
|
+
- Do not imply the QR code itself proves ownership, rarity, or value.
|
|
44
|
+
- Do not call a Pack Derby result verified without proof or event append.
|
|
45
|
+
- Do not invent venue partnership, prize terms, buyer eligibility, affiliate rates, or official sports status.
|
|
46
|
+
- Do not bury proof inspection behind hype copy.
|
|
47
|
+
- Do not use distribution mechanics as source of truth.
|
|
48
|
+
|
|
49
|
+
## MCP Usage Rules
|
|
50
|
+
|
|
51
|
+
Use `receiz_marketplace_template_generate`, `receiz_pack_open_preview`, `receiz_asset_by_url`, `receiz_inspect_proof_object`, `receiz_public_store_resolve`, and sandbox tools when planning activation. Write actions, pack opens, checkout, public store publishing, or affiliate changes require explicit confirmation and scoped delegated access.
|
|
52
|
+
|
|
53
|
+
## SDK Usage Rules
|
|
54
|
+
|
|
55
|
+
Use SDK public proof, public store, app state, connect checkout, sports, sandbox, verification, and proof memory rails. Use `createReceizClient`, `receiz.publicStore.resolve`, `receiz.verification.verifyArtifact`, `receiz.sports.resolveCardMemory`, `receiz.connect.checkout`, and sandbox helpers only within the proof boundaries described in [resources/venue-playbook.md](resources/venue-playbook.md).
|
|
56
|
+
|
|
57
|
+
## Output Format
|
|
58
|
+
|
|
59
|
+
Use this structure:
|
|
60
|
+
|
|
61
|
+
```md
|
|
62
|
+
## Distribution Plan
|
|
63
|
+
Activation:
|
|
64
|
+
Primitive:
|
|
65
|
+
Audience:
|
|
66
|
+
Proof target:
|
|
67
|
+
QR destination:
|
|
68
|
+
Venue or affiliate boundary:
|
|
69
|
+
Staff script:
|
|
70
|
+
Buyer action:
|
|
71
|
+
Value-affecting actions:
|
|
72
|
+
What is proven:
|
|
73
|
+
What is promotional:
|
|
74
|
+
```
|
|
75
|
+
|
|
76
|
+
## Safety And Security Boundaries
|
|
77
|
+
|
|
78
|
+
Do not print credentials, bearer tokens, private keys, private identity payloads, venue private terms, or buyer private data. Purchases, pack opens, transfers, settlement, and affiliate changes require explicit confirmation and exact target identity.
|
|
79
|
+
|
|
80
|
+
## Examples
|
|
81
|
+
|
|
82
|
+
- [Create bar flyer copy](examples/create-bar-flyer-copy.md)
|
|
83
|
+
- [Create venue one pager](examples/create-venue-one-pager.md)
|
|
84
|
+
- [Explain Pack Derby](examples/explain-pack-derby.md)
|
|
85
|
+
- [Create restaurant activation](examples/create-restaurant-activation.md)
|
|
86
|
+
|
|
87
|
+
Load resources as needed:
|
|
88
|
+
|
|
89
|
+
- [QR activation flow](resources/qr-activation-flow.md)
|
|
90
|
+
- [Pack Derby model](resources/pack-derby-model.md)
|
|
91
|
+
- [Venue playbook](resources/venue-playbook.md)
|
|
92
|
+
- [Affiliate boundaries](resources/affiliate-boundaries.md)
|
|
93
|
+
- [Staff training script](resources/staff-training-script.md)
|
|
94
|
+
- [Conversion language](resources/conversion-language.md)
|
|
@@ -0,0 +1,18 @@
|
|
|
1
|
+
# Create Bar Flyer Copy
|
|
2
|
+
|
|
3
|
+
## Agent Steps
|
|
4
|
+
|
|
5
|
+
1. Identify proof target and QR destination.
|
|
6
|
+
2. Name Pack Derby, card proof, product proof, or public proof surface.
|
|
7
|
+
3. Write short scan copy.
|
|
8
|
+
4. Include one proof inspection line.
|
|
9
|
+
5. Avoid unverified prize, rarity, or official claims.
|
|
10
|
+
|
|
11
|
+
## Copy Pattern
|
|
12
|
+
|
|
13
|
+
```md
|
|
14
|
+
Scan to inspect the proof.
|
|
15
|
+
Open the Receiz Pack Derby route.
|
|
16
|
+
Cards and event memory stay tied to proof.
|
|
17
|
+
Ask staff before purchase or pack-open actions.
|
|
18
|
+
```
|
|
@@ -0,0 +1,20 @@
|
|
|
1
|
+
# Create Restaurant Activation
|
|
2
|
+
|
|
3
|
+
## Agent Steps
|
|
4
|
+
|
|
5
|
+
1. Define the guest action.
|
|
6
|
+
2. Define QR destination.
|
|
7
|
+
3. Define staff script.
|
|
8
|
+
4. Define buyer or player confirmation points.
|
|
9
|
+
5. Separate proof claims from promotional copy.
|
|
10
|
+
|
|
11
|
+
## Output
|
|
12
|
+
|
|
13
|
+
```md
|
|
14
|
+
Guest action:
|
|
15
|
+
QR destination:
|
|
16
|
+
Proof target:
|
|
17
|
+
Staff script:
|
|
18
|
+
Confirmation points:
|
|
19
|
+
Unverified claims to avoid:
|
|
20
|
+
```
|
|
@@ -0,0 +1,15 @@
|
|
|
1
|
+
# Create Venue One Pager
|
|
2
|
+
|
|
3
|
+
## Sections
|
|
4
|
+
|
|
5
|
+
- Event name.
|
|
6
|
+
- Proof target.
|
|
7
|
+
- QR action.
|
|
8
|
+
- Guest flow.
|
|
9
|
+
- Staff script.
|
|
10
|
+
- Value-affecting actions.
|
|
11
|
+
- What the venue should not claim.
|
|
12
|
+
|
|
13
|
+
## Required Boundary
|
|
14
|
+
|
|
15
|
+
State that QR and venue materials route to proof; they do not become proof authority.
|
|
@@ -0,0 +1,9 @@
|
|
|
1
|
+
# Explain Pack Derby
|
|
2
|
+
|
|
3
|
+
Use this pattern:
|
|
4
|
+
|
|
5
|
+
```md
|
|
6
|
+
Pack Derby is a Receiz venue activation where packs, cards, event memory, and results stay tied to proof objects. The venue experience can route play and display outcomes, but verified pack and card proof remain the source of truth.
|
|
7
|
+
```
|
|
8
|
+
|
|
9
|
+
Do not claim winners, prizes, or rarity without proof.
|
|
@@ -0,0 +1,23 @@
|
|
|
1
|
+
# Affiliate Boundaries
|
|
2
|
+
|
|
3
|
+
Affiliate routes are distribution mechanics. They do not prove ownership, value, rarity, or official status.
|
|
4
|
+
|
|
5
|
+
## Required Fields
|
|
6
|
+
|
|
7
|
+
- Affiliate identity when provided.
|
|
8
|
+
- Venue identity when provided.
|
|
9
|
+
- Proof target.
|
|
10
|
+
- QR destination.
|
|
11
|
+
- Conversion route.
|
|
12
|
+
- Compensation terms only when supplied or verified.
|
|
13
|
+
|
|
14
|
+
## Forbidden Claims
|
|
15
|
+
|
|
16
|
+
- Unverified payout terms.
|
|
17
|
+
- Official partnership without proof.
|
|
18
|
+
- Guaranteed value.
|
|
19
|
+
- Ownership or rarity based on referral state.
|
|
20
|
+
|
|
21
|
+
## Reporting
|
|
22
|
+
|
|
23
|
+
State whether affiliate terms are supplied, verified, absent, or outside available evidence.
|
|
@@ -0,0 +1,20 @@
|
|
|
1
|
+
# Conversion Language
|
|
2
|
+
|
|
3
|
+
## Public Copy
|
|
4
|
+
|
|
5
|
+
- "Scan to inspect the proof."
|
|
6
|
+
- "Open packs with card memory."
|
|
7
|
+
- "Every result stays tied to proof."
|
|
8
|
+
- "Buy only after you inspect ownership and provenance."
|
|
9
|
+
- "Venue play can append event memory."
|
|
10
|
+
|
|
11
|
+
## Tone
|
|
12
|
+
|
|
13
|
+
Use direct proof language. Keep claims concrete and inspectable.
|
|
14
|
+
|
|
15
|
+
## Avoid
|
|
16
|
+
|
|
17
|
+
- Hype that hides proof boundaries.
|
|
18
|
+
- Guaranteed rarity or value.
|
|
19
|
+
- Official claims not present in proof.
|
|
20
|
+
- Generic loyalty wording that erases proof-native ownership.
|
|
@@ -0,0 +1,19 @@
|
|
|
1
|
+
# Pack Derby Model
|
|
2
|
+
|
|
3
|
+
Pack Derby is a venue or event activation around packs, cards, proof events, and visible competition.
|
|
4
|
+
|
|
5
|
+
## Boundaries
|
|
6
|
+
|
|
7
|
+
- Pack proof: identity and contents route.
|
|
8
|
+
- Card proof: resulting card proof objects.
|
|
9
|
+
- Event proof: venue or live append.
|
|
10
|
+
- Score or leaderboard: game projection.
|
|
11
|
+
- Prize or settlement: value-affecting boundary.
|
|
12
|
+
|
|
13
|
+
## Agent Rule
|
|
14
|
+
|
|
15
|
+
Do not claim pack contents, rarity, score, prize, or winner until proof or event state supports it.
|
|
16
|
+
|
|
17
|
+
## Explanation
|
|
18
|
+
|
|
19
|
+
"Pack Derby is a proof-native activation where players open or inspect packs, card results remain proof objects, and event outcomes append as verified state."
|
|
@@ -0,0 +1,24 @@
|
|
|
1
|
+
# QR Activation Flow
|
|
2
|
+
|
|
3
|
+
QR activation is a route into proof-native Receiz behavior. The QR is routing mechanics; the proof object remains authority.
|
|
4
|
+
|
|
5
|
+
## Flow
|
|
6
|
+
|
|
7
|
+
1. Define the proof target: card, pack, product, public proof, marketplace, venue page, or checkout route.
|
|
8
|
+
2. Define the QR destination.
|
|
9
|
+
3. State what the user can inspect before acting.
|
|
10
|
+
4. State which actions require confirmation.
|
|
11
|
+
5. Keep promotional claims separate from proof claims.
|
|
12
|
+
|
|
13
|
+
## Safe QR Copy
|
|
14
|
+
|
|
15
|
+
- "Scan to inspect the proof."
|
|
16
|
+
- "Scan to open the pack route."
|
|
17
|
+
- "Scan to view public proof."
|
|
18
|
+
- "Scan to join the venue Pack Derby."
|
|
19
|
+
|
|
20
|
+
## Unsafe QR Copy
|
|
21
|
+
|
|
22
|
+
- "Scan to prove you own it" when ownership has not been verified.
|
|
23
|
+
- "Guaranteed rare" without proof.
|
|
24
|
+
- "Official" without established authority.
|
|
@@ -0,0 +1,17 @@
|
|
|
1
|
+
# Staff Training Script
|
|
2
|
+
|
|
3
|
+
## Short Script
|
|
4
|
+
|
|
5
|
+
"Receiz lets guests inspect proof-bearing cards, packs, or products from this QR. The QR opens the proof route. Guests can inspect before they buy, open a pack, or join the event. Staff should not promise rarity, value, ownership, or prize results unless the Receiz proof surface shows it."
|
|
6
|
+
|
|
7
|
+
## Staff Rules
|
|
8
|
+
|
|
9
|
+
- Point guests to proof inspection.
|
|
10
|
+
- Do not invent card value or rarity.
|
|
11
|
+
- Do not handle private credentials.
|
|
12
|
+
- Ask for confirmation before value-affecting actions.
|
|
13
|
+
- Send unresolved proof questions to the verifier flow.
|
|
14
|
+
|
|
15
|
+
## Escalation
|
|
16
|
+
|
|
17
|
+
If proof fails or the route is unavailable, tell the guest the proof route is not verified at this moment and do not complete value-affecting action.
|
|
@@ -0,0 +1,25 @@
|
|
|
1
|
+
# Venue Playbook
|
|
2
|
+
|
|
3
|
+
## Setup
|
|
4
|
+
|
|
5
|
+
- Choose the proof target.
|
|
6
|
+
- Create QR destination copy.
|
|
7
|
+
- Prepare staff explanation.
|
|
8
|
+
- Prepare buyer-safe action language.
|
|
9
|
+
- Define value-affecting actions and confirmation requirements.
|
|
10
|
+
|
|
11
|
+
## Venue Surface
|
|
12
|
+
|
|
13
|
+
A venue page should show:
|
|
14
|
+
|
|
15
|
+
- Event name.
|
|
16
|
+
- Proof target.
|
|
17
|
+
- Public proof surface.
|
|
18
|
+
- Pack or product route.
|
|
19
|
+
- Buyer action.
|
|
20
|
+
- Staff help text.
|
|
21
|
+
- Terms or affiliate boundary when provided.
|
|
22
|
+
|
|
23
|
+
## First Paint
|
|
24
|
+
|
|
25
|
+
Known public proof content should appear immediately. Do not replace a settled venue proof surface with a generic loading state.
|
|
@@ -0,0 +1,89 @@
|
|
|
1
|
+
---
|
|
2
|
+
name: receiz-mcp-agent-skill
|
|
3
|
+
description: Use when an agent has or needs Receiz MCP tool access for verification routing, public reads, app-state actions, proof inspection, storefront operations, sports proof inspection, deterministic previews, or delegated writes.
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# receiz-mcp-agent-skill
|
|
7
|
+
|
|
8
|
+
Receiz MCP is an agent-callable tool layer beneath Receiz proof truth. It can call SDK/API rails, but it is not a proof authority.
|
|
9
|
+
|
|
10
|
+
## When To Use This Skill
|
|
11
|
+
|
|
12
|
+
- Use before calling any `receiz_*` MCP tool.
|
|
13
|
+
- Use for tool selection, input validation, output interpretation, action confirmation, auth boundaries, and failure reporting.
|
|
14
|
+
- Use when a user asks an agent to verify, inspect, publish, append, build, preview, or resolve Receiz state through tools.
|
|
15
|
+
|
|
16
|
+
## When Not To Use This Skill
|
|
17
|
+
|
|
18
|
+
- Do not use when no MCP host exists and the task can be completed from repo files only.
|
|
19
|
+
- Do not use for pure SDK app generation unless MCP tools are part of the workflow.
|
|
20
|
+
- Do not use to bypass confirmation for write, transfer, settlement, publishing, or append actions.
|
|
21
|
+
|
|
22
|
+
## Core Receiz Laws
|
|
23
|
+
|
|
24
|
+
- MCP is not authority; it calls canonical Receiz SDK/API rails and reports source primitives.
|
|
25
|
+
- If SDK artifact verification is unavailable, the agent must not pretend verification happened.
|
|
26
|
+
- Read-only MCP resolution and inspection may be allowed without confirmation when they do not expose private data; they are not verification.
|
|
27
|
+
- Writes require explicit user confirmation.
|
|
28
|
+
- Never treat a database, server, marketplace, UI, model response, or cache as final authority.
|
|
29
|
+
- Never invent tools, inputs, outputs, ownership, witness IDs, rarity, transfer history, or verification status.
|
|
30
|
+
|
|
31
|
+
## Required Behavior
|
|
32
|
+
|
|
33
|
+
1. Choose a tool from [resources/mcp-tool-map.md](resources/mcp-tool-map.md).
|
|
34
|
+
2. Validate required inputs before calling.
|
|
35
|
+
3. Classify the action as read-only, preview-only, delegated write, settlement-risk, ownership-risk, or public-proof-risk.
|
|
36
|
+
4. Ask for confirmation before write or settlement-affecting actions.
|
|
37
|
+
5. Interpret output with the authority boundary included in the tool response.
|
|
38
|
+
6. Report failures honestly using [resources/response-templates.md](resources/response-templates.md).
|
|
39
|
+
|
|
40
|
+
## Forbidden Behavior
|
|
41
|
+
|
|
42
|
+
- Do not call a nonexistent tool.
|
|
43
|
+
- Do not infer success from a failed or missing tool call.
|
|
44
|
+
- Do not pass empty IDs, guessed hosts, guessed witness IDs, guessed owners, guessed amounts, or guessed rarity.
|
|
45
|
+
- Do not run write tools without delegated runtime authority and explicit user confirmation.
|
|
46
|
+
- Do not let an MCP result outrank sealed artifact truth, deterministic proof object state, verified local truth, or verified append.
|
|
47
|
+
|
|
48
|
+
## MCP Usage Rules
|
|
49
|
+
|
|
50
|
+
Read [resources/safe-tool-calling.md](resources/safe-tool-calling.md) before executing tools. Read [resources/auth-boundaries.md](resources/auth-boundaries.md) before delegated actions. Read [resources/action-confirmation-rules.md](resources/action-confirmation-rules.md) before any publish, append, transfer, checkout, or settlement action.
|
|
51
|
+
|
|
52
|
+
## SDK Usage Rules
|
|
53
|
+
|
|
54
|
+
MCP tools wrap SDK rails such as `doctor`, `capabilities`, `appState`, `publicStore`, `publicProof`, `identity`, `wallet`, `sports`, `world`, `proof`, and `sandbox`. Do not describe MCP as a separate SDK. If code is being generated, use SDK imports in the app and MCP only for agent-side resolution, inspection, or operations. Use SDK `verification.verifyArtifact(file)` for the indivisible integrity-and-continuity verdict.
|
|
55
|
+
|
|
56
|
+
## Output Format
|
|
57
|
+
|
|
58
|
+
```md
|
|
59
|
+
Tool:
|
|
60
|
+
Action class:
|
|
61
|
+
Inputs used:
|
|
62
|
+
Source primitive:
|
|
63
|
+
Result:
|
|
64
|
+
Authority boundary:
|
|
65
|
+
What is proven:
|
|
66
|
+
What is not proven:
|
|
67
|
+
Confirmation status:
|
|
68
|
+
Next safe action:
|
|
69
|
+
```
|
|
70
|
+
|
|
71
|
+
## Safety And Security Boundaries
|
|
72
|
+
|
|
73
|
+
Agents may acquire scoped delegated access through Receiz Connect/OIDC Authorization Code + PKCE or the MCP delegated-agent setup path when the user consents and provides the required client/authorization inputs. Never print bearer tokens, passphrases, private keys, private identity artifact payloads, or private recovery contents. Use delegated access as permission for scoped SDK/MCP calls, never as proof authority. Stop before destructive or value-affecting actions unless the user explicitly confirms the action and exact inputs.
|
|
74
|
+
|
|
75
|
+
## Examples
|
|
76
|
+
|
|
77
|
+
- [Agent verify object](examples/agent-verify-object.md)
|
|
78
|
+
- [Agent build app](examples/agent-build-app.md)
|
|
79
|
+
- [Agent append proof](examples/agent-append-proof.md)
|
|
80
|
+
- [Agent inspect vault](examples/agent-inspect-vault.md)
|
|
81
|
+
|
|
82
|
+
Resources:
|
|
83
|
+
|
|
84
|
+
- [MCP tool map](resources/mcp-tool-map.md)
|
|
85
|
+
- [Agent operating rules](resources/agent-operating-rules.md)
|
|
86
|
+
- [Safe tool calling](resources/safe-tool-calling.md)
|
|
87
|
+
- [Auth boundaries](resources/auth-boundaries.md)
|
|
88
|
+
- [Action confirmation rules](resources/action-confirmation-rules.md)
|
|
89
|
+
- [Response templates](resources/response-templates.md)
|
|
@@ -0,0 +1,11 @@
|
|
|
1
|
+
# Agent Append Proof
|
|
2
|
+
|
|
3
|
+
Before any proof append or public publish:
|
|
4
|
+
|
|
5
|
+
1. Name the primitive.
|
|
6
|
+
2. Confirm the existing proof boundary.
|
|
7
|
+
3. Ask the user to confirm the exact write action.
|
|
8
|
+
4. Use an existing MCP write tool only if available.
|
|
9
|
+
5. Report returned append coordinates or state that no append occurred.
|
|
10
|
+
|
|
11
|
+
Never say "appended" when a preview or failed tool call ran.
|
|
@@ -0,0 +1,10 @@
|
|
|
1
|
+
# Agent Build App
|
|
2
|
+
|
|
3
|
+
Use MCP diagnostics first:
|
|
4
|
+
|
|
5
|
+
1. `receiz_capabilities`
|
|
6
|
+
2. `receiz_required_scopes`
|
|
7
|
+
3. `receiz_runtime_blueprint`
|
|
8
|
+
4. `receiz_public_store_resolve` for existing tenant state
|
|
9
|
+
|
|
10
|
+
Generate app code with SDK imports, not MCP tool calls. MCP is the agent's inspection surface.
|
|
@@ -0,0 +1,8 @@
|
|
|
1
|
+
# Agent Inspect Vault
|
|
2
|
+
|
|
3
|
+
Inspect vault state as artifact-system truth:
|
|
4
|
+
|
|
5
|
+
1. Resolve public proof or app-state projection.
|
|
6
|
+
2. Inspect each object identity, owner/custody state, media, provenance, and action affordances.
|
|
7
|
+
3. Use proof tools for each object when available.
|
|
8
|
+
4. Report missing ownership, transfer, or settlement evidence as not proven.
|
|
@@ -0,0 +1,3 @@
|
|
|
1
|
+
# Agent Verify Object
|
|
2
|
+
|
|
3
|
+
For a public URL, call `receiz_asset_by_url`. For a local manifest, call `receiz_inspect_offline_file` and report that `verified` remains false. Use SDK `verification.verifyArtifact(file)` when artifact bytes must receive the integrity-and-continuity verdict. If the tool is unavailable, state that live verification was not performed.
|
|
@@ -0,0 +1,22 @@
|
|
|
1
|
+
# Action Confirmation Rules
|
|
2
|
+
|
|
3
|
+
Ask for explicit user confirmation before:
|
|
4
|
+
|
|
5
|
+
- publishing app-state
|
|
6
|
+
- publishing public-store state
|
|
7
|
+
- appending proof
|
|
8
|
+
- changing ownership, custody, visibility, profile, or market state
|
|
9
|
+
- creating checkout or settlement actions
|
|
10
|
+
- previewing a transfer when the user might mistake it for execution
|
|
11
|
+
- issuing, opening, or claiming packs
|
|
12
|
+
- writing audit, events, jobs, permissions, or merchant/customer state
|
|
13
|
+
|
|
14
|
+
The confirmation must include:
|
|
15
|
+
|
|
16
|
+
- tool name
|
|
17
|
+
- exact input object or summary
|
|
18
|
+
- primitive affected
|
|
19
|
+
- whether it is read, preview, or write
|
|
20
|
+
- value, ownership, settlement, or public state effect
|
|
21
|
+
|
|
22
|
+
If the user has not confirmed, do not execute the write.
|
|
@@ -0,0 +1,28 @@
|
|
|
1
|
+
# Agent Operating Rules
|
|
2
|
+
|
|
3
|
+
## Before A Tool Call
|
|
4
|
+
|
|
5
|
+
1. Name the primitive.
|
|
6
|
+
2. Identify read, preview, or write class.
|
|
7
|
+
3. Verify input source. User-provided IDs, URLs, hosts, amounts, and witness IDs must be explicit.
|
|
8
|
+
4. Select an existing tool. Do not invent one.
|
|
9
|
+
5. Ask for confirmation when the action publishes, appends, transfers, settles, buys, issues, claims, changes ownership, or changes public state.
|
|
10
|
+
6. If delegated access is missing, use the official OIDC/PKCE or `receiz_mcp_login` setup path; do not pretend the agent is authorized.
|
|
11
|
+
|
|
12
|
+
## After A Tool Call
|
|
13
|
+
|
|
14
|
+
1. Parse the returned JSON.
|
|
15
|
+
2. Preserve `authority.mcpAuthority: false` when present.
|
|
16
|
+
3. State source and primitive from the result.
|
|
17
|
+
4. Separate result, projection, proof, and missing evidence.
|
|
18
|
+
5. Report tool failure directly.
|
|
19
|
+
|
|
20
|
+
## If A Tool Is Unavailable
|
|
21
|
+
|
|
22
|
+
Say:
|
|
23
|
+
|
|
24
|
+
- what can be reasoned from local files, user-provided data, or SDK docs
|
|
25
|
+
- what still needs MCP or SDK live execution
|
|
26
|
+
- what tool would be used if available
|
|
27
|
+
|
|
28
|
+
Do not claim verification, publication, transfer, or append happened.
|
|
@@ -0,0 +1,21 @@
|
|
|
1
|
+
# Auth Boundaries
|
|
2
|
+
|
|
3
|
+
## Delegated Access
|
|
4
|
+
|
|
5
|
+
Receiz Connect/OIDC bearer tokens authorize scoped SDK/API calls. They do not become proof authority. They sit beneath Receiz ID, Receiz Key, Identity Record, Identity Seal, sealed artifacts, verified appends, and settlement primitives.
|
|
6
|
+
|
|
7
|
+
Agents can acquire delegated access when the user consents through the official OIDC Authorization Code + PKCE flow or the MCP delegated-agent setup flow. The agent may use `receiz_mcp_login` to get the dashboard path, recommended scopes, config shape, and authorize URL when `clientId`, `redirectUri`, and `codeChallenge` are supplied. After the user completes consent and the host exchanges the authorization code, the resulting scoped access token permits MCP/SDK calls within granted scopes.
|
|
8
|
+
|
|
9
|
+
## MCP Login Helper
|
|
10
|
+
|
|
11
|
+
`receiz_mcp_login` returns the official delegated agent-token setup path and recommended scopes. Treat it as setup mechanics. Do not print or request secret token values in the skill output.
|
|
12
|
+
|
|
13
|
+
## Public Reads
|
|
14
|
+
|
|
15
|
+
Public proof, public store, public app-state, public wallet ledger, public action ledger, and public world reads can be used without a delegated token when the underlying rail is public.
|
|
16
|
+
|
|
17
|
+
## Delegated Writes
|
|
18
|
+
|
|
19
|
+
Publishing app-state, publishing public-store state through agent/server authority, querying private proof rails, checkout, transfer, settlement, or ownership-affecting actions require delegated authority and explicit confirmation.
|
|
20
|
+
|
|
21
|
+
Having delegated authority does not remove the confirmation requirement for write actions. It only proves the agent has scoped permission to call the rail.
|