Receiz AI Skills

Explore the public capability directory for user outcomes, every public SDK callable, MCP tools, and AI skills. Agents can read the machine-readable catalog. An inventory entry grants no access and does not imply an MCP execution adapter.

The 127.0.0 package at release coordinate v127.0.0 is a registry-bound operating-contract distribution beneath Receiz proof authority. AI instructions, MCP confirmations, OAuth/OIDC grants, JSON objects, database rows, staging references, and receipts never become proof or runtime authority.

KKSv1.0 is the single temporal authority for proof. New proof coordinates are computed locally from Genesis and the canonical pulse frequency; existing coordinates are carried by the verified sealed object. createdAt is descriptive Chronos only and is never proof, ordering, or causal authority. The SDK, MCP tools, all 37 machine manifests, and the shared KKSv1.0 temporal-authority contract enforce the same boundary.

Highest Cash-Out Frame

source + law + sequence + object + evidence. And the reader underneath them.

Every AI skill is the reader layer beneath those authorities. The manifests forbid reader-as-authority; an agent may inspect, verify, and project, but it may not author, reorder, replace, or outrank the actual sealed proof object.

V127 — Reality-Grade Infrastructure

V127 aligns the SDK, compiler, MCP and AI packages with complete source custody, first-seal ownership, deterministic coordinates and verified append continuity. The public function catalog covers 678 callable exports across the main, compiler, testing, React, offline sealing, local subject host and offline KaiSigil entry points. MCP capability reporting includes this catalog and the complete 425-method client inventory; 330 explicit tools retain their SDK authority boundaries.

V127 agents can create full KaiSigil proofs locally with packaged resources and use the source-bound local subject runtime. Temporal execution admits complete causal coordinates; bare pulse values, model reports and copied plans cannot advance authority. Offline file sealing runs without network after explicit signer enrollment; KaiSigil proving requires no enrollment or network. Portable history retains exact V120 snapshots and full temporal evidence under the enclosing sealed source.

Capability inventory is not a claim that every historical HTTP route exists. Of the 81 newly mapped JSON SDK adapters, 12 compose current routes and 69 require explicit historical HTTP compatibility; older media.upload, media.transform, and proof.query also require that transport. Default calls fail before requests or mutation previews. Agents must follow historical HTTP compatibility and the separate historical subject transport boundary in the local runtime guide. Neither compatibility configuration nor credentials become proof authority.

Preserved V125 economy contracts

Sealed Reality Becomes Spendable Value. Economic authority follows proof, not institution. V125 teaches agents to register a sealed lawful-action law, submit a separately sealed completed action whose causal claims are derived from a reverified portable execution-authority transition, and request deterministic current-Kai Settlement projection without inventing value. The exact micro-Phi law is (completionKai - startKai + 1) * (valuationKai - completionKai + 1). No AI, developer, government, institution, server, database, or model may supply a completion verdict, amount, multiplier, bonus, backfill, or proof exemption.

The current 330-tool MCP registry preserves the 169-tool v124.1 runtime inventory, 39 trust adapters, and thirteen v125 economy adapters alongside the new v127 tools. The thirteen economy adapters comprise three lawful-action operations plus the complete ten-operation sender/receiver edge lifecycle for planning, inspection, transition-set verification, commit preparation, recovery packaging, Settlement send/receive, and Reserve send/receive. Exact proof, plan, transition, commit, and recovery materials stay in trusted-host or same-runtime custody behind opaque references. The enclosing sealed artifact is verified before payload extraction. One admitted membership belongs to the current owner; transfer moves it without cloning Settlement value or erasing provenance. Reserve remains the legacy funding rail.

skills.json also binds all 425 callable methods on the public createReceizClient() surface by exact ordered inventory and digest. The union of the 37 machine manifests must contain every method and all 330 MCP tools; generation and validation fail if either distribution surface drifts. Three retained artifact-recovery methods are explicitly classified under historicalSdkOperations, remain callable, and are not mislabeled as v125 defaults. receiz_capabilities exposes the same SDK inventory, exact MCP tool inventory, and v125 capability families without turning capability description into proof or transaction authority.

All 37 current manifests use package/ruleset 127.0.0, SDK/MCP range >=127.0.0 <128.0.0, registry digest 8d0b5b839d02d9efbd4306cc99410595a183705c2670b76d2567eaaaade99065, and operation-matrix digest eadd171a45fcc51e275a1c57de1eb8e67614757a5723d141793641edf7207a10.

Historical V124 — Reality Becomes Infrastructure

The Production Runtime for Verified Civilization. V124 teaches every application to compose the canonical Kai clock, proof-authority challenges, server-custodied short-lived sessions, durable staged execution, exact recovery, verified replay/checkpoints, access-filtered private additions, atomic multi-domain mutations, privacy-safe recipient resolution, and evidence-based runtime qualification.

The edge verifies and retains the sealed proof object. Exact authenticated subject, domain, namespace, access-key, and revocation heads bind every remote projection. Server and database state provide subordinate coordination, compare-and-swap, indexing, sync, and recovery. A response is rejected unless authenticated and bound to its request; method presence never means a production dependency is operational.

Established artifact authority chain

V120 carries two established proof-object laws unchanged: receiz.native_capture.v1 binds exact bytes from Receiz's dedicated camera ceremony, and receiz.pbi.proof-object-authorship.v1 appends verified PBI authorship to an already verified predecessor. Signing is unavailable before canonical verification. Multi-signer history remains ordered forever, local settlement completes before optional global publication, and authorship never changes ownership, media bytes, capture provenance, or prior proof.

The exact current sequence is: verify exact bytes → profile admission → verified actor/history → transition → plan/domain/effects/idempotency → plan-bound capability → seal → durable stage → independent byte resolution → atomic named-domain acceptance → report-only receipt.

Exact bytes cross a process only as bytes and require reverify-exact-bytes. Verified artifacts, admissions, histories, actors, plans, verified capabilities, candidates, and stores require same-runtime-custody. Identity Seal signing uses local key custody, supports Ed25519 and P-256, and produces a signed claim—not verified capability authority. Private keys and passphrases are never serialized.

The single current MCP artifact inventory contains nine tools: receiz_artifact_verify, receiz_artifact_admit, receiz_artifact_append_plan, receiz_artifact_transition_seal_and_stage, receiz_artifact_transition_commit, receiz_artifact_global_resolve, receiz_artifact_reconcile_plan, receiz_artifact_reconcile_stage, and receiz_artifact_reconcile_commit. The first five are also the explicitly historical v112 compatibility inventory, not a second current surface. A sealed candidate is a proof object but not the accepted head. Stage writes no head and its reference is non-authoritative. Commit resolves and reverifies staged bytes before atomic named-domain acceptance. COMMIT_DOMAIN_MISMATCH is distinct from same-domain IDEMPOTENCY_CONFLICT; registry-derived effects stay outside the portable transition digest; unknown namespaces remain byte-preserved.

The same package carries 37 inherited living-subject MCP tools: subject resolve/state/history/memory/relationships/inventory; subject Twin profile/message/mind export/import planning; mandate get/plan/activate/pause/revoke; world additions/command plan/validate/execute/transaction plan/execute/receipt/replay; subject runtime enqueue/status/cancel; living-subject conformance; proof-brain head/search/resolve/stream; and bearer preview/issue/inspect/claim/cancel/status. Each generated skill map binds those exact names to SDK primitives, strict input/output types, source primitive, registry/reducer digests, zero-write failure, and the non-authority boundary.

The inherited v122 protocol adds 19 MCP operations for durable remote proof-object admission and authenticated subject state; edge-held proof bundles and append-only public access-key bindings; locally encrypted private/invited world commands; exact validation, execution, outcome recovery, and filtered additions; first-class mandate issue/state/revoke; atomic multi-world planning/execution; and explicit Phi Settlement/Reserve planning. Its stable v122 protocol identifiers remain intentionally unchanged in v123.

V124 introduced 22 universal production-runtime MCP adapters for live Kai, canonical proof-authority challenges, durable atomic execution, authority-session lifecycle, operational qualification, verified public/private additions and replay/checkpoints, unsealed replay-candidate export followed by canonical seal and sealed restore, namespace resolution, privacy-safe recipient resolution, and sealed-source publication. V124.1 added four source-carried adapters, producing the retained exact 26-tool family. The exact names, SDK methods, fixed/conditional scopes, input/output references, process-local handles, and trusted-host custody rules are published in the V124 runtime tool map.

client.admission.browserStore is durable admission coordination only: it stores no proof object or sealed artifact bytes and never blocks known-artifact first paint. V120 production reconciliation preserves the provider-neutral client.coordination rail and never exposes Supabase mechanics. Receiz-generated files retain declared ownership, while receiz.extensions.ts is developer-owned and must never be overwritten.

receiz-build-production-system remains the constitutional orchestration skill for substantial Receiz applications. Fifteen focused constitutional skills supply architecture, domain, law, command, authority, replay, offline, causal, artifact, migration, performance, observability, testing, and release contracts. The earlier nine domain skill names remain packaged for compatibility. Seven operation skill names first introduced in obsolete-versioned now describe current outcomes for identity profiles, portable continuity, bearer ownership, offline transport, proof media, cross-app state, and admission evidence. Their retired obsolete-versioned mechanisms are not active defaults. One dedicated receiz-global-reconciliation skill governs accepted-head resolution, verified offline reconciliation, structural divergence, first paint, indeterminate recovery, and effects. receiz-value-execution governs exact live Phi execution and retry recovery; receiz-proof-authority governs edge verification, explicit consent, and minimum-scope embedded authority. The v124 coordinates remain immutable historical evidence; the v127 manifest coordinates above are current.

This package teaches AI agents how to understand, verify, build with, and operate Receiz from the existing repository surfaces.

It is published as @receiz/ai-skills and is an exact-version dependency of both @receiz/sdk and @receiz/mcp-server. Installing either package places all 43 skills under node_modules/@receiz/ai-skills: 37 manifests and 34 OpenAI agent prompts are included for explicit loading by an agent host.

Receiz is a proof-native artifact system. Sealed proof/object truth is strongest: a Receiz object is not a database row, but a proof-carrying artifact whose witnessed history is the truth boundary. The proof object carries continuity; SDK and MCP may verify, extract, append, or project beneath that carried truth. Receiz.com reference behavior comes before SDK, MCP, AI, and other developer rails. Server state, database state, UI state, marketplace state, and model memory are projections only. Old witnessed truth is not stale. If a projection is wrong, rebuild it from object history. If truth is missing, append new truth. Never mutate witnessed truth.

A verified proof object is not limited to the platform that created it. Any lawful platform may append authenticated ownership and history only while preserving the same immutable object identity, payload, provenance root, prior history, and unknown namespaces, then returning a complete verified proof object. AI skills adapt to that continuity and never invent an origin-platform authority or parallel chain.

SDK, MCP, And Skills

• SDK: @receiz/sdk is the universal runtime; @receiz/sdk/react is React-only; @receiz/sdk/compiler is Node-only; @receiz/sdk/testing is browser-safe sandbox and conformance support.
• MCP: @receiz/mcp-server is for agent tool access. Its current 330-tool registry preserves the 169-tool v124.1 inventory, thirteen v125 lawful-action and edge-value tools, and 39 trust adapters alongside the v127 tools. The four V124.1 source-carried adapters remain unchanged and expose replay-family opening, Receiz-ID conversation-family opening, bounded private epoch-grant planning, and held material-family inspection while exact sources, secrets, locators, and large bytes remain in trusted-host custody.

skills.json carries the canonical v124_1CapabilityInventory, and each relevant manifest carries its exact v124_1CapabilityIds. This binds source-carried replay, unlimited invited-member conversation, exact large-material reconstruction, progressive verified playback, proof-derived memory/Twin response, and portable account continuity across SDK, MCP, and AI instructions without allowing the model layer to invent or outrank proof.

• Skills: this package is operating doctrine. It tells an AI which Receiz primitive is active, which source of truth wins, which SDK or MCP rail to use, and what must never be assumed.

Agents may acquire scoped delegated access through the official Receiz Connect/OIDC Authorization Code + PKCE flow or through the MCP delegated-agent setup path exposed by receiz_mcp_login. That acquired access is permission to call scoped SDK/MCP rails after user consent. It is not proof authority and must never outrank artifact truth.

How Agents Should Use This Package

Start with receiz-build-production-system when work spans multiple constitutional domains and receiz-global-reconciliation for named-domain coordination. Machine-readable manifests require the exact active canonical v127 registry and operation-matrix digests, command-only mutation, independent verification, MCP conformance, and a passing release lock. Use a focused operation skill for SDK/MCP implementation and a constitutional skill for broader system law. Stable obsolete-versioned wire schemas remain available only through the explicit historical @receiz/sdk/obsolete-versioned package entry; current skills never teach their key, head, receipt, reconcile, or signed-command mechanics as a current outcome.

The current operation skills are executable contracts. Current profile work uses the neutral authenticated same-UID profile operation. Current bearer ownership accepts a complete verified artifact, derives prior ownership from carried proof, and returns a native Record -> Seal artifact. Proof media uses the same native artifact custody and projects only a verified URL beneath it. These outcomes have no active identity-key, caller-head, claim-key, or receipt prerequisite. MCP calls the same SDK outcomes and never creates a parallel authority.

Stable obsolete-versioned schema names and their head/receipt mechanics remain explicitly historical compatibility, not the active/default profile, bearer, or proof-media contract.

Do not invent APIs. Use the SDK and MCP maps inside the skills, then inspect the repo when a requested operation is not listed.

Developer Install Or Reference

Install @receiz/sdk, @receiz/mcp-server, or @receiz/ai-skills directly. Reference node_modules/@receiz/ai-skills from an agent host, or copy the individual skill folders into an agent skill directory. Keep the package together when possible because the router skill depends on the domain skills.

When SDK or MCP changes:

1. Inspect packages/receiz-sdk/src/index.ts, packages/receiz-sdk/src/identity.ts, packages/receiz-sdk/src/react.ts, and packages/receiz-mcp-server/src/index.ts.
2. Update receiz-proof-skill/resources/sdk-reference.md, the inherited MCP maps, and receiz-mcp-agent-skill/resources/v124-runtime-tool-map.{md,json}.
3. Update domain skills only when the changed rail affects their primitive.
4. Run pnpm validate:ai-skills.
5. Run package tests when the SDK or MCP behavior changed.

Safety Boundaries

• Verify before claiming.
• Never invent ownership, witness IDs, rarity, transfer history, verification status, proof IDs, append IDs, or settlement state.
• Never treat a database, server, marketplace, UI, model response, or cache as final authority.
• Never mutate witnessed history.
• Never derive, recover, order, or override proof Kai from createdAt or another Chronos timestamp.
• Append new truth only.
• If a view is wrong, rebuild the projection from witnessed history.
• If history is missing, append the missing truth.
• Generated apps must preserve Receiz proof semantics.
• Generated apps should not require a traditional database unless the user explicitly asks for one.

Established living-subject skills

• receiz-living-subject governs immutable subject identity, byte-preserved namespaces, ownership continuity, state, history, additions, and portable proof artifacts.
• receiz-subject-twin governs subject-scoped profile, exact-head messaging, complete proof-brain retrieval, portable mind export/import, memory summaries, and the separation between speech, intentions, facts, memories, and performance.
• receiz-autonomous-mandate governs exact-digest owner authorization, bounded actions and regions, privacy, battle, inventory/value exposure, rate limits, provider/safety/application scope, expiry, pause, and immediate revocation.
• receiz-world-event-runtime governs typed command planning, exact-head validation, deterministic decision, event admission, receipts, durable ticks, idempotency, replay, and structured zero-write failure.
• receiz-multi-subject-transaction governs atomic meetings, relationships, battles, gifts, and trades so every participant head advances together or none do.
• receiz-event-derived-memory governs factual memories with admitted event citations and rebuildable AI summaries/projections.
• receiz-live-proof-character governs streamed reply, audio, viseme, gaze, blink, breath, emotion, gesture, proposed intention, and completion events as non-authoritative performance over exact proof context.

Every living-subject skill carries its SDK map, MCP map, authority rules, examples, tests, manifest, OpenAI metadata, and the exact current v127 registry and operation-matrix digests. The skills teach the same sequence as the implementation: canonical head → entire proof history → compact indexes → relevant references → exact primary proof objects → reasoning → cited answer. They never authorize a world event, transfer, mandate, or release claim by prose.

The updated constitutional skills bind living-subject behavior into app building, command construction, deterministic replay, causal sync, global reconciliation, portable continuity, authority/security, MCP operation, testing, release, constitutional law, and offline-first operation. Their examples cover exact proof-memory speech, absent-owner exploration, mutual relationship formation, bounded trade, atomic battle, cross-device restoration, mandate revocation during a queued action, partition convergence, rejection of an AI-invented event, and cross-application subject continuity.