Resource authoring standards

A resource is a non-executable, reusable artifact RBA has standardized — a project skeleton, a contract template, a reference architecture, a runbook, a checklist. Resources sit one level out from skills: they aren’t code or prompts, they’re the artifacts that work produces or starts from. Resources ship standalone at resources/<name>.md or bundled at plugins/<plugin>/resources/<name>.md.

This page is two layers: Anthropic’s official grounding, then the RBA convention on top.

Anthropic’s best practices

Source: Claude Code — Skills and Plugins.

Honest framing

Anthropic does not define a standalone “resource” as a first-class Claude Code artifact. The two closest official concepts are: (1) skill supporting files — the non-SKILL.md files in a skill directory (templates, references, schemas) that Claude loads on demand via progressive disclosure; and (2) files bundled inside a plugin and shipped with it. “Resource” is the RBA generalization of these.

What does carry over from Anthropic’s documented model:

• Progressive disclosure applies. A supporting file should be loaded only when needed and referenced by relative path from the skill or doc that uses it. A resource is no different — it earns its place by being something a skill or workflow points at, not something inlined everywhere.
• Reference by stable relative path. Inside a plugin, use ${CLAUDE_PLUGIN_ROOT} for any path a tool or hook resolves, so the reference survives installation.
• One concept per file. The same focus discipline Anthropic applies to skills applies here: a resource is one reusable thing, not a grab-bag.

Because there’s no official schema, the rules below are RBA convention — but they’re built so a resource behaves like a well-formed Anthropic supporting file: discoverable, single-purpose, referenced rather than duplicated.

How RBA tailors this

When something is a resource (RBA decision rule)

Reach for a resource when:

• The artifact is the same shape every time but adapted per project (SOW template, runbook).
• It captures institutional knowledge that doesn’t change per engagement (reference architecture).
• It is referenced by skills (a skill produces a Brief; the Brief Template lives here).

If the artifact is single-use or project-specific, it’s a deliverable, not a resource.

File format

Single-file resources are Markdown; multi-file resources use a folder.

---
name: <resource-name>             # required — matches the filename (RBA: slug = name)
description: <what it is + when to use it>  # required
primitive: true                   # optional — set only for cross-cutting foundation resources
kind: template | runbook | reference | checklist  # required — powers catalog filtering
---

# <Title Case Resource Name>

<2–3 sentences: what this is, who uses it, when.>

<The resource content — template body, runbook steps, reference material.>

## How to use
<Adapting / using this resource.>

## Related
<Links to skills that produce or consume this resource.>

Multi-file resource:

plugins/<plugin>/resources/<resource-name>/
├── README.md           # required — describes the resource
├── manifest.json       # optional — declares included files
└── <skeleton files>

Resource kinds (RBA taxonomy)

• template — fill-in-the-blank, has placeholders the user replaces.
• runbook — sequential operational guide with prerequisites and rollback.
• reference — read-only informational asset (architecture, decision framework).
• checklist — list of items to verify.

Placeholder convention (templates)

• {{UPPER_SNAKE_CASE}} for required placeholders.
• {{OPTIONAL_FIELD?}} for optional placeholders (trailing ?).
• Document every placeholder in the “How to use” section.

Documentation requirement (RBA)

Every resource states: what it is, who uses it, when to use it, how to adapt it, and which skills/agents produce or consume it (the “Related” links — this is the RBA stand-in for progressive-disclosure referencing).

Quality checklist

1. The resource is something a skill or workflow references, not inlined boilerplate (Anthropic spirit).
2. It is genuinely reusable — used on more than one engagement (RBA).
3. Frontmatter has name, description, and kind; standalone resources may set optional facets or primitive: true (RBA).
4. Slug = name = filename (RBA).
5. kind matches the actual shape (template / runbook / reference / checklist).
6. Templates document every placeholder; runbooks have prerequisites and a rollback path.
7. The “Related” section links to at least one skill or agent.

Anti-patterns

• A project-specific deliverable masquerading as a resource
• Vague filename (template.md, doc.md) instead of sow-template.md
• Template with undocumented placeholders
• Runbook without rollback / prerequisites
• A resource with no “Related” links — orphaned content (no skill points at it)
• A resource that duplicates existing content rather than referencing it
• Hard-coded paths inside a plugin resource instead of ${CLAUDE_PLUGIN_ROOT}