plant-eprfs-agentdoc
Plants and maintains authoritative agent documentation files. Ensures content consistency through byte-identical projection.
Install
mkdir -p .claude/skills/plant-eprfs-agentdoc && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/18282" && unzip -o skill.zip -d .claude/skills/plant-eprfs-agentdoc && rm skill.zipInstalls to .claude/skills/plant-eprfs-agentdoc
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Plant ONE runtime-authored agent-doc (CLAUDE.md / AGENTS.md) in its elohim-native package on the eprfs layer. The package becomes the authoritative root for the gospel doc's frontmatter (cite envelopes preserved verbatim) + body; the doc file stays BYTE-IDENTICAL because the projection is verbatim passthrough, so cite-gen is untouched and the cite fingerprints survive intact. The agent-doc member of the plant-eprfs family; the most sensitive plant type (gospel / managed-memory surfaces).Key capabilities
- →Plant a runtime-authored agent-doc in its elohim-native package
- →Ensure the package becomes the authoritative root for the doc
- →Preserve the doc file as byte-identical
- →Record the composing model for the projection
- →Verify byte-identity of the planted doc
- →Record provenance in the compose-graph
How it works
The skill plants a runtime-authored agent-doc into its elohim-native package, making the package the authoritative source while ensuring the doc file remains byte-identical through a verbatim passthrough projection.
Inputs & outputs
When to use plant-eprfs-agentdoc
- →Updating agent docs
- →Synchronizing CLAUDE.md
- →Managing project governance
About this skill
Plant EPRFS Agent-Doc
Plant a runtime-authored agent-doc (CLAUDE.md / AGENTS.md) in its elohim-native package on the eprfs layer: the package under .epr-meta/elohim/packages/agentdocs/<id>.json becomes the authoritative root. Its source.body — the ENTIRE raw file, frontmatter (incl. cite envelopes) AND body — is the source of truth. The doc file grows from that root as a generated projection that traces back to it, byte-for-byte identical, content-addressed (eprfs BlobCid), with the composing model recorded.
This is the agent-doc member of the plant-eprfs family (siblings, grown one at a time: plant-eprfs-skill, plant-eprfs-agent, plant-eprfs-hook). It is the most safety-sensitive plant type: agent-docs are GOSPEL / managed-memory surfaces with existing cite tooling and .epr-meta compose-gate governance. A mangled CLAUDE.md or a broken cite envelope damages the memory substrate. For the shared authoring discipline see the elohim-package-authoring skill.
One capability type, one target per run. Plant ONE doc, prove it byte-identical, then the next. Never bulk-adopt the CLAUDE.md corpus — planting is package-driven and opt-in, one doc at a time.
The FLIP that composes with cite-gen
Agent-docs DO flip (the package becomes master, like every other plant type). The flip composes WITH cite-gen instead of fighting it, and this is the whole design:
- The doc's frontmatter is a LIVE index. cite-gen writes
id:+ content-addressedcites:envelopes (slug | desc | sha256:… | path: …) whose fingerprints are computed from the cited docs' content. A generate-from-metadata projector (the skill/agent flip) could never reproduce those, and would fight cite-gen. - So the projector is VERBATIM PASSTHROUGH, not generate-from-metadata.
project(package)returnssource.bodyunchanged — the entire raw file. The flip moves authority into the package; it rewrites zero bytes of the doc. cite-gen stays the sole author of the doc surface, and every cite fingerprint survives byte-identical. This is why the flip composes: the eprfs/epr-meta root is a content-addressed substrate (cites are sha256 envelopes, the package graph is BlobCid), so the package absorbing cite provenance is a natural extension, not a foreign burden. - The authority marker lives in the PACKAGE, never in the doc.
metadata.master: "package"goes in the package JSON only. The loader reads authority from the package (package-aware skip), never from the doc frontmatter — somaster: packageis never injected into the CLAUDE.md. cite-gen +managed_surfaces.py+ the.epr-metacompose-gate remain the EDIT authority over the doc file itself.
What planting does
- Origin preserved. The package keeps
metadata.sourceRuntime("claude"for CLAUDE.md,"codex"for AGENTS.md) — where the doc was born. - Authority rooted in the package. The package gains
metadata.master: "package". Editing the doc directly is still done through cite-gen (the doc is the cite surface), but the package is now the authoritative composition root and the freshness anchor. - Doc bytes untouched. The agent-doc projector is pure passthrough — it emits
source.bodyverbatim. There is no frontmatter to generate, no body to re-wrap, no authority-marker banner injected. This is the safety property that matters most for a gospel doc and its cite envelopes. - The composition note. The package carries a short authored
compositionnote describing how this doc composes / is-managed relative to the others — the one piece of authored intent that has nowhere to live in the doc's own frontmatter without perturbing cite-gen. - Provenance recorded.
eprfs-agent compose-graphrecords the content-addressed edge from the projected doc back to its native package (packageCid), attributed to the model that composed it (composedBy). Because master stays a verbatim mirror, the projection CID equals the source CID — the witness is exact, not a fork.
The floor this stands on
- Transform-free byte-identity.
project(import(doc)) === docholds for any bytes with zero transform — import copies the raw file intosource.body, project returns it unchanged. Strict===on the raw read (no trailing-newline normalization, notrim(), no YAML round-trip, no frontmatter re-emission). For an un-flipped adopted doc this isverifySourceFidelity; for a planted (flipped) doc it isverifyRuntimeProjectionIfPresent—project(package) === the doc file— both inscripts/package-projections.mjs, run byelohim-agent:packages:verify. - cite-gen is UNTOUCHED. Because the doc bytes never change on projection,
cite-gen.py --verify <doc>resolves exactly as before and everysha256:…fingerprint is preserved. Planting must never trip the cite gate. - CID is single-sourced in eprfs.
source.cid, when present, is the eprfsBlobCidstamped byeprfs-agent— never recomputed in JS. Byte-identity (floor 1) is the fidelity floor and needs no CID.
Procedure (one doc X)
- Author the AgentDocPackage at
.epr-meta/elohim/packages/agentdocs/<id>.json(adoption is creating the package — there is no bulk import). Set:kind: "AgentDocPackage",apiVersion: "elohim-agent/v1alpha1".source: { language: "markdown", path: "<repo-rel path to X>", body: "<the ENTIRE raw file, verbatim>" }. Copy the bytes exactly — frontmatter (incl. every cite envelope) and body.metadata:id(a globally-unique slug — 142 docs share the basename CLAUDE.md, so derive it from the directory, e.g.mishpat-domain-gospel),name=id,version,description,sourceRuntime(claude/codex),runtimeTargets,assetRefs: [],master: "package",composedBy: "<your model id>", andgovernance = { "eprRef": "epr:elohim-agent/agentdocs/<id>", "policy": "capability-governance@1", "gates": ["epr-meta-resolver","elohim-agent:packages:verify"], "ledger": ".claude/data/governance-findings.jsonl" }(hand-set — nothing generates it). Record the doc's own frontmatterid:asmetadata.gospelId.composition: a short authored note on how X composes / is-managed relative to the other docs.projections: { "<runtime>": { "path": "<repo-rel path to X>" } }— a single projection keyed by the doc's one runtime.
- Regenerate projections from the package:
node elohim/sdk/domains/elohim-agent/scripts/package-projections.mjs project --write-fixturesthen... project --write-runtime. For a doc this writes X back byte-identical to what was there (verbatim passthrough) —git diff <X>MUST be empty. A non-empty diff means the bytes were transformed somewhere and is a STOP condition. If the flip cannot preserve the cite envelopes byte-identically, STOP — never ship a mangled gospel doc. - Verify package-first.
... verifyis green: X takes the package-first path (the loader skips re-importing amaster: packagedoc), and the byte-identity assertion holds for both the fixture and the runtime doc. - Confirm cite-gen still resolves.
python3 .claude/scripts/memory-kit/cite-gen.py --verify <X>exits 0 — every cite is still content-addressed and resolvable. The flip touched nothing cite-gen cares about. - Confirm the doc is byte-identical.
git diff --exit-code <X>MUST be clean. Planting anchors authority; it never rewrites the doc. - Record composition.
eprfs-agent compose-graph .epr-meta/elohim/packages --projections-root .epr-meta/elohim/projections --composed-by "<your model id>"— X's node showskind: "AgentDocPackage",master: "package",packageCid<-> projection CID (equal, since the mirror is verbatim), andcomposedBy. (Agent-doc support in the Rust compose-graph adapter may still be pending — byte-identity is the floor that needs no CID.) - Commit path-scoped, then move to the next doc. Prove one byte-identical, then the next.
Which docs are pilot-safe
Plant small, self-contained, leaf gospel docs first (a domain CLAUDE.md with one or two cites), and confirm the cite gate before and after. Defer the high-fan-out root gospel surfaces (repo-root CLAUDE.md, the memory MEMORY.md) until the machinery has a track record — a projection regression on a root surface has the widest blast radius. Never risk the memory substrate for a plant.
Per-runtime adapters (the surface seam)
For skills and agents, the per-runtime projection is a frontmatter dialect over a shared markdown body — one identity, two projections. For an agent-doc it is different: the codex-runtime analog of a directory's CLAUDE.md is a different file (AGENTS.md) for the same directory, not a second projection of one identity. So an agent-doc has exactly one projection, keyed by its one runtime (claude for CLAUDE.md, codex for AGENTS.md). There is no cross-runtime fork to unify — the runtime is fixed by the basename.
Invariants
- Never rewrite doc bytes on project. The agent-doc projector is verbatim passthrough. A non-empty
git diffon the projected doc is a bug in the projector, not an acceptable reformatting — and on a gospel doc it is a memory-substrate hazard. - Never inject an authority marker into the doc.
master: packagelives in the package JSON only. The doc frontmatter stays exactly as cite-gen authored it, so thegospel-claude-mdclassifier and every cite envelope stay intact. - cite-gen owns the doc surface. Any change to the doc's frontmatter (
id:,cites:) goes through cite tooling, never a hand-edit and never the projector. Planting is orthogonal to authoring. - CID is single-sourced in eprfs (
eprfs-core::BlobCid::compute). Never recompute a CID in JS — calleprfs-agent. - Adoption is opt-in and one-at-a-time. Never bulk-adopt the CLAUDE.md corpus. A doc is a source package only once its AgentDocPackage exists.
- Identity never forks per runtime. One doc, one root, one runt
Content truncated.
When not to use it
- →When bulk-adopting the `CLAUDE.md` corpus
- →When the user wants to modify the doc bytes directly during planting
- →When the doc is not a `CLAUDE.md` or `AGENTS.md` file
Limitations
- →Plants only one doc at a time
- →Does not rewrite doc bytes on project
- →Does not inject an authority marker into the doc
How it compares
This workflow establishes the package as the authoritative root for agent documentation while preserving the byte-identity of the original doc, ensuring compatibility with existing cite tooling unlike a typical metadata-driven generation.
Compared to similar skills
plant-eprfs-agentdoc side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| plant-eprfs-agentdoc (this skill) | 0 | 17d | No flags | Advanced |
| add-provider-doc | 6 | 2mo | Review | Beginner |
| update-release-notes | 1 | 11d | Review | Advanced |
| higress-daily-report | 1 | 5mo | Review | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by ethosengine
View all by ethosengine →You might also like
add-provider-doc
lobehub
Guide for adding new AI provider documentation. Use when adding documentation for a new AI provider (like OpenAI, Anthropic, etc.), including usage docs, environment variables, Docker config, and image resources. Triggers on provider documentation tasks.
update-release-notes
tldraw
Update the release notes file at `apps/docs/content/releases/next.mdx` based on PRs merged to main since the previous release, or archive `next.mdx` to a versioned file when a new version is published.
higress-daily-report
alibaba
生成 Higress 项目每日报告,追踪 issue/PR 动态,沉淀问题处理经验,驱动社区问题闭环。用于生成日报、跟进 issue、记录解决方案。
sop-creator
coleam00
Create runbooks, playbooks, and technical documentation for engineering teams. Use when the user wants to document a process, create a runbook, build operational docs, or formalize any repeatable technical procedure. Triggers on requests like "create a runbook for...", "document this process", "write a playbook", or any technical documentation request.
release-prep
massgen
Prepare release documentation including CHANGELOG entry, announcement text, and validation. Run before tagging a new release.
update-api-docs
Agenta-AI
Update the API reference documentation by downloading the latest OpenAPI spec from production and regenerating the Docusaurus API docs