Skip to content

2. Module Entrypoint

A bundled, self-contained capability with its own assets and a contract (frontmatter description = function signature; body = process; assets = lazy-loaded knowledge). The unit of REUSE.

INDUSTRY TERMS: “skill” (agentskills.io), “plugin”, “command bundle”.

The agentskills.io project is the canonical authority for the SKILL.md CONTAINER SURFACE — and ONLY that. Cite its rules for what it owns; do NOT promote its framing into Genesis ontology.

What agentskills.io owns (cite verbatim, fetch live):

  • SKILL.md frontmatter fields and limits
  • body size budget
  • the canonical directory layout (scripts/ + references/ + assets/)
  • script conventions
  • the evaluation discipline (content evals, trigger evals, with-skill vs without-skill baseline)

What agentskills.io does NOT own (Genesis is authoritative): the broader primitive taxonomy. The agentskills.io corpus uses “skill” as the unit, conflating the container surface with the agent’s whole behavior. Genesis treats MODULE ENTRYPOINT as ONE primitive type among PERSONA SCOPING, SCOPE-ATTACHED RULE, CHILD-THREAD SPAWN, ORCHESTRATOR, ASSET. Do not let the spec’s unit framing erase the other primitive types when designing.

Conflict resolution rule: where the two corpora disagree, the container surface follows agentskills.io; the primitive taxonomy and Genesis pattern catalogues stay Genesis-owned. If you are uncertain which side a question lands on, ask: “is this about how the SKILL.md file is shaped” (agentskills.io) or “is this about what kinds of primitives exist and how they compose” (Genesis).

Authority pages (load-bearing for the container surface)

Section titled “Authority pages (load-bearing for the container surface)”

A capability that needs its own dispatch trigger, may be invoked discoverably by the harness’s dispatcher, and bundles assets that should not pollute the parent context until needed.

The frontmatter description is preloaded by the harness into every session. It is the function signature the dispatcher LLM matches against. Treat it as code, not as marketing copy.

A MODULE ENTRYPOINT can be bound into a thread two distinct ways. Same primitive shape (markdown + frontmatter + body + lazy assets); different binding determines the substrate fields in play.

1. Agent-invoked (default; the agentskills.io case)

Section titled “1. Agent-invoked (default; the agentskills.io case)”

The harness’s dispatcher LLM matches the entrypoint’s description against the live session and lazy-loads the body as ADDITIVE context mid-session. The session was rooted by something else (operator prompt, slash command, prior turn). The KEY PROPERTY above governs: description is a function signature, dispatcher matches it.

2. Substrate-invoked (the trigger-orchestrator case)

Section titled “2. Substrate-invoked (the trigger-orchestrator case)”

A TRIGGER ORCHESTRATOR instantiates the entrypoint as the session ROOT in response to an external event. The body is the initial task; the dispatcher does not match anything — the trigger surface IS the matcher (event filter, slash command, schedule). Substrate fields like SANDBOXING, CAPABILITY_GATING, AUDIT_SURFACE may apply (when the trigger surface provides them; see per-trigger-surface adapters).

The substrate-invoked binding is the corpus mechanism that lets architectural patterns A6 EVENT-DRIVEN and A10 GOVERNED OUTER LOOP reuse the entrypoint primitive instead of inventing a new “workflow file” type. When you design an entrypoint for substrate invocation, the per-trigger-surface adapter (e.g. runtime-affordances/per-trigger-surface/gh-aw.md) prescribes the frontmatter shape; the body still follows the same authoring discipline as any other entrypoint.