> ## Documentation Index > Fetch the complete documentation index at: https://prism.ntecdev.ai/llms.txt > Use this file to discover all available pages before exploring further. # Prism Skills > Skills are customer-facing invocation packages that help agents discover and invoke authoritative Prism process bodies. They generate pointer artifacts for each surface. They are not the process body and do not carry authority. # Prism Skills > Operator and agent reference for the Prism skills layer. > Governing SPECs: SPEC-138 v0.1 (authority model), > SPEC-137 v0.1 (generation contract). ## What a Prism Skill Is A **Prism skill** is a customer-facing invocation package. It gives a human or agent a stable handle, description, trigger hints, expected output shape, and pointer metadata for resolving an authoritative Prism process body or method fragment. It is not the process body and it does not carry authority. Skills live in a governed registry. For each surface target, the skill generates a **pointer artifact** (a surface-specific shim file) that carries only invocation metadata. A skill points; the process body executes. The distinction is structural and enforced: a skill or pointer artifact that duplicates process steps, prerequisites, gates, or rollback text is malformed. The governed record linking a skill to one or more process bodies or method fragments is the **SkillProcessMapping** — a registry entry that specifies the mapping type (one-to-one, many-to-one, one-to-many, fragment, or outer-loop stage), the target, and the authority and fetch policy. Mappings are not embedded in the skill or the pointer artifact. ### What a Skill Contains A well-formed skill invocation package and its generated pointer artifacts include only: | Field | Purpose | | --------------------- | ------------------------------------------------------------ | | `shim_id` | Stable pointer id, e.g. `process-shim:release.merge_lane.v1` | | `shim_schema_version` | Schema version for the pointer format | | `generator_version` | Version of the tool that produced this pointer | | `generated_at` | ISO timestamp | | `process_id` | Target process id, e.g. `release.merge_lane.v1` | | `process_version` | Exact or bounded version of the target process | | `body_hash` | Expected hash of the authoritative process body | | `source_ref` | Reference to where the authoritative body lives | | `title` | Human-readable label | | `applies_when` | One-line discovery summary (not executable instructions) | | `trigger_hints` | Tags that help the agent decide when to fetch the process | | `authority_required` | Minimum authority level to invoke | | `fetch.prism_rpc` | Symbolic Prism-owned operation name to fetch the body | | `invocation` | Instruction type: always `fetch_process_body` | ### What a Skill Must Not Contain A skill pointer must not carry: * Process steps, prerequisites, gates, or rollback instructions * Timeout or skip-policy prose copied from the process body * Governance or safety text from the process body * Raw URLs, filesystem paths, shell snippets, or executable commands * Inline credentials, headers, query secrets, or environment-variable interpolation * Any instruction that bypasses the fetch-and-verify flow The prohibition on duplicated process text is absolute. A pointer artifact that copies body content is treated as malformed by the runtime and by acceptance tests. ## Authority Model Skills and their generated pointer artifacts sit below all authoritative Prism layers. When any conflict arises, the skill or pointer artifact loses: | Layer | Source | Note | | -------------------------------------------- | -------------------------------------------------------------------------------- | ------------------------------------- | | 1 — Ring 0 BIOS + committed governance chain | `AGENTS.md` / `CLAUDE.md`, `PRISM.md`, `ORG.md`, `PROJECT.md` | Non-negotiable; operator-locked | | 2 — Ratified Prism artifacts | SPECs, ADRs, role contracts, persona contracts, process bodies, method fragments | Beats everything below | | 3 — Runtime Prism services | `prism_start`, signals, semantic recall, process lookup, Team Memory | Live operational state and evidence | | 4 — Skill registry + SkillProcessMapping | Governed registry records linking skills to process bodies | Governed pointers only | | 5 — Generated pointer artifacts | Surface-specific shims, slash commands, editor helpers, local caches | Invocation conveniences; no authority | A skill registry record (layer 4) beats a generated pointer artifact (layer 5) when they conflict. A process body (layer 2) beats a mapping (layer 4) when they conflict. A skill may not grant approval, merge, deploy, security, or RTE authority that its layer does not have. ## Fetch-and-Verify Flow No process runs directly from a pointer artifact. Before any process body is applied, the runtime must: 1. Read the pointer artifact metadata. 2. Resolve `process_id` and `process_version` against the Prism process registry or repo source of record (`docs/processes/`). 3. Fetch the authoritative process body using `fetch.prism_rpc`. 4. Verify the fetched body against `body_hash`. Mismatch is a hard stop. 5. Check authority: the invoking identity must meet `authority_required`. 6. Apply the process body. The pointer artifact is not consulted again after fetch. 7. Record invocation evidence (see below). The pointer artifact is consumed at step 1 only. Steps 2–6 are driven by the fetched authoritative body and Prism runtime state. ## Invocation Evidence Every invocation from a pointer artifact must record: * `invocation_id`, `shim_id`, `shim_hash`, `generator_version` * `process_id`, requested version, resolved version, resolved `body_hash` * `body_source` and `fetch_trace_id` * trigger id and trigger evidence * `auto_invoke_reason` when auto-invoked * authority-resolution result * body mismatch or cache-drift notes, if any * `no_dup_text_check` result * operator or specialist override id, if any This evidence is queryable by `process_id` and invocation id. ## Per-Surface Invocation Prism supports generated pointer artifacts on multiple host-local surfaces. Each surface has a different physical format, but the pointer-only content rule applies equally to all: | Surface | Pointer location | Pointer format | | ---------------- | -------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | | `claude_code` | `.claude/skills//SKILL.md` and/or `.claude/commands/.md` | Skill pointer only for intent-safe mappings; command pointer for HITL or ambiguous invocation; both must satisfy Claude Code host frontmatter | | `codex` | `SKILL.md` companion in a skills bundle directory | YAML + Markdown | | `cursor` | `.cursor/rules/.mdc` | MDC pointer file | | `claude_desktop` | Future: native skills panel | TBD | | API worker | Context bundle field | Structured JSON pointer | All surface formats are generated from the same source pointer definition under SPEC-137. Manual edits to generated surface files are flagged as drift. For Claude Code, pointer emission depends on mapping safety: * intent-safe mappings emit both `.claude/skills//SKILL.md` and `.claude/commands/.md`; * HITL-only or ambiguous mappings emit `.claude/commands/.md` only, including `trigger_confidence: candidate`, `missing_context_policy: request_context`, or `missing_context_policy: return_ambiguity`; * `.claude/skills//SKILL.md` must not be generated unless the mapping is safe for inference and auto-surfacing. Claude Code files must also satisfy the host's real file contract: * `SKILL.md` must declare required `name` and `description` frontmatter; * `name` must be lowercase hyphen format, equal the skill directory, and be at most 64 characters; * `name` must not be the dotted Prism process id unless a future ratified host contract permits that form; * `description` must be at most 1024 characters and must describe what the skill does and when Claude Code should use it for auto-surface matching; * `.claude/commands/.md` must follow the same host-conformance rule for its frontmatter or metadata surface. ## Auto-Invocation Rules A process may be auto-invoked from a pointer artifact only when all of the following hold: 1. Exactly one process candidate matches at required confidence. 2. The process trigger's `default_run_policy` permits auto-start. 3. `missing_context_policy` is satisfied. 4. Authority requirements are met by the current identity or delegation. 5. The authoritative body fetch and hash verification pass. 6. The process body itself does not require an additional gate before start. Auto-invocation is blocked when multiple candidates match, required context is missing, fetch fails, hash fails, the invoking identity lacks authority, or unsafe fetch metadata is detected in the pointer. An agent must not use broad keyword matching as proxy for trigger confidence. ## Skill Lifecycle States | State | Meaning | | -------------- | ------------------------------------------------------- | | `proposed` | Candidate pointer; no invocation yet | | `experimental` | One successful authored invocation recorded | | `active` | Repeated use across projects; no unresolved postmortems | | `deprecated` | Superseded; links to successor; owner review required | | `retired` | Removed from surfaces; invocation blocked | Promotion between states requires evidence in the Prism evidence graph. Deprecation requires a superseder reference. ## Process Body Index The authoritative process bodies that skills may point to live in `docs/processes/`. Current registered process bodies: | Process ID | Version | Applies when | | --------------------------- | ------- | -------------------------------------- | | `deploy.cloud.v1` | v1 | Deploying to cloud infrastructure | | `deploy.lan.v1` | v1 | Deploying to LAN hosts | | `docs.publish.v1` | v1 | Publishing docs to the Mintlify site | | `docs.release_update.v1` | v1 | Updating docs on a release | | `fleet.sync_after_merge.v1` | v1 | Syncing fleet after a merge to main | | `release.merge_lane.v1` | v2 | PR review, approval, and merge to main | | `windows.validation.v1` | v1 | Windows host validation | Skills that target a process not listed here are treated as pointing to an unknown body. The runtime must not auto-invoke against an unregistered target. ## Memory Operations and Checkpoints Process bodies carry `memory_op_slots` — structured definitions of the memory, journal, and checkpoint operations the process expects the agent to execute at specific steps. This is Frank's memory-discipline mandate: memory operations belong in the authoritative process body, not in the skill invocation package or its generated pointer artifacts. The pointer artifact is silent on memory operations. When the runtime fetches a process body and applies it, the body's `memory_op_slots` drive any `prism_journal`, `prism_checkpoint`, `prism_remember`, or Team Memory writes that occur during execution. The skill did not author those operations; the body did. This means: if you want to add, change, or remove a memory or checkpoint operation from a process, update the process body under `docs/processes/` (or the Prism process registry). Do not patch the pointer artifact. ## What Skills Are Not * Skills are not a second process registry. Process bodies live in `docs/processes/` and the Prism process registry only. * Skills are not an authority layer. They cannot grant or override authority. * Skills are not operator instructions. The agent consults the fetched process body, not the pointer artifact, for what to do. * Skills are not permanent. A generated pointer artifact becomes stale the moment the process body it references changes its hash. Stale pointer artifacts are regenerated from the registry, not hand-patched. ## Relationship to Method Fragments Method fragments (`docs/method-fragments/`) carry contextual operating instructions — guidance for how an agent should think and act. Skills carry invocation pointers — guidance for which process to fetch and when. Both live below the authority of committed Ring files and ratified Prism artifacts. They are complementary, not substitutes. ## References * SPEC-139 v0.1 — Skill, Process, and Mapping Registry (vocabulary, SkillProcessMapping, MEMORY\_OP\_SLOTS schema). * SPEC-138 v0.1 — PTrends Process-Shim Model (authority boundary). * SPEC-137 v0.1 — Process-Shim Generation Contract (fetch, hash, invocation tests). * SPEC-078 v0.2 — Consensus-First Parallelism and Method Fragments. * SPEC-126 — Process Registry and Body SOR. * `docs/processes/` — authoritative process body definitions. * `docs/architecture/process-shims.mdx` — operator explanation of the PTrends process-shim model. * Plan #31 — Prism Skills Layer.