Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/marko-php/marko/releasenpx skills add marko-php/marko --skill releasegit clone --depth 1 https://github.com/marko-php/markoWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00093 | $0.02887 |
| Opus 5 | $0.00046 | $0.01443 |
| Sonnet 5 | $0.00019 | $0.00577 |
| Haiku 4.5 | $0.00009 | $0.00289 |
Grade A, and why
release scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 238 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Cut a Marko release
bin/release.sh already automates everything mechanical: the full test suite, the
develop → main merge, changelog generation, the tag, the GitHub Release, and the
merge-back to develop. It does not decide whether to release or what to call it.
That judgment is this skill's only job.
Two things must be right before a tag is pushed, and both are listed as manual in
.claude/release-process.md:
- Every merged PR is labeled, or its changes vanish into a generic "Other Changes" bucket in the release notes.
- The version number is correct, because all 70 packages share it and Composer constraints downstream depend on it.
There is exactly one approval gate: present the recommendation, stop, and wait. Do not tag on your own initiative — not even for an obviously-correct patch bump.
Arguments
None. /release takes no arguments; the version is settled at the approval gate in step 5.
If the user does type something after /release anyway, treat it as an authoritative
override and skip straight to validating it (same checks as an override at the gate).
Step 1 — Verify preconditions
git fetch --quiet --tags origin develop main
git status --short # must be empty
git rev-parse --abbrev-ref HEAD # must be develop
git rev-list --count origin/develop..develop # must be 0 (nothing unpushed)
git rev-list --count develop..origin/develop # must be 0 (nothing unpulled)
php -v # must be 8.5.x, else set PHP_BIN
command -v gh jq # both required by bin/release.sh
Also confirm there is something to release: git log $(git tag --sort=-v:refname | head -1)..develop --oneline must be non-empty.
If any check fails, say exactly which one and stop. Do not quietly fix it — an unpushed commit or a dirty tree usually means work is still in flight, which is the user's call, not yours.
If php -v is not 8.5, don't abandon the run — pass an explicit interpreter through to
the script instead: PHP_BIN=/path/to/php8.5 ./bin/release.sh X.Y.Z.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago First seen · 238 lines · 93 tokens per session scan A d0fe95d80f6f
release is a skill published in the GitHub repository marko-php/marko (393 stars, last pushed 3d ago), licensed MIT. It adds 93 tokens to every session and 2,887 once invoked, about $0.0005 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
system-web-components
ALWAYS use when creating, modifying, or reviewing ANY front-end web components, widgets, or custom elements in this repository. Mandatory for all web component work — creating new components, modifying existing ones, registering in zolinga.json, writing component docs, or debugging component…
system-create-mcp-resource
Use when creating or updating MCP resources — static files exposed to MCP clients via resources/list and resources/read. Covers .meta.json descriptors, tenant filtering, URI rewriting, dynamic resources via mcp:resources/list event hook, and the mcp-system scheme.
system-create-mcp-tool
Use when exposing a Zolinga event handler as an MCP (Model Context Protocol) tool — i.e. a method clients can invoke via JSON-RPC tools/call. Covers handler class, manifest binding, JSON Schemas, the Tools\CallEvent contract, and the schema.response requirement enforced by McpToolsListHandler::collectTools().
system-inspect
How to query the Zolinga system's runtime state — merged manifest cache, API service stubs, configuration layers, and log files — using jq, grep, tail, and PHP.
system-create-handler
Use when creating a new event handler/listener in a Zolinga module, including event naming, class placement, origin filtering, rights checks, and event object selection.
system-create-mcp-prompt
Use when creating or updating MCP prompts — reusable prompt templates exposed to MCP clients via prompts/list and prompts/get. Covers .meta.json definitions, tenant filtering, content.uri file references, {{arg}} substitution, and the mcp-system scheme.