​

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:

​

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: 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: 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/<name>/SKILL.md and .claude/commands/<name>.md;
• HITL-only or ambiguous mappings emit .claude/commands/<name>.md only, including trigger_confidence: candidate, missing_context_policy: request_context, or missing_context_policy: return_ambiguity;
• .claude/skills/<name>/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/<name>.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

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: 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.