Menu
Guidance preparing a release of the system core or any module, including updating the changelog and version number.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Use when creating or updating MCP resources — static files exposed to MCP clients via `resources/list` and `resources/read`. Covers `.meta.json` descriptors, URI rewriting, dynamic resources via `mcp:resources/list` event hook, and the `mcp-system` scheme.
Use when exposing an existing `origin: ["remote"]` listener as an MCP tool without rewriting the handler. Covers the one-line manifest pattern that re-uses the same class+method, plus the minimal schema work needed to satisfy `McpToolsListHandler::collectTools()`. Complements system-create-mcp-tool (which covers the greenfield case).
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()`.
Use when working with the JavaScript client-side event system in Zolinga. Covers the Event class, Api gateway, dispatching events from JS to PHP, receiving broadcastBack responses, inter-component communication via BroadcastChannel, and web component integration.
Use when adding localized strings in PHP or HTML, including gettext usage patterns and context-aware translation strings for Zolinga Intl.
Use when writing or reviewing PHP code in this repository to enforce strict typing, naming, file layout, and listener/service interface conventions.
| name | system-release |
| description | Guidance preparing a release of the system core or any module, including updating the changelog and version number. |
When preparing a release of the system core or any module, follow these steps to ensure a smooth and consistent release process:
git tag and git show <tag>. Versioning of tags follows the semantic versioning rules ("v.."). Note, you may be asked to relase something that is not commited yet but may have already been prepared (e.g. version is already bumped up) and is waiting for the final commit. In that case leave the version as it is if it was not commited yet.zolinga.json, update the version number according to semantic versioning rules (MAJOR.MINOR.PATCH) based on the changes made since the last release. It may have be already done so check git tag if it is the new version already updated or old one. If not sure, ask for confirmation.CHANGELOG.md reflects all the last release (see git tag), if not add or update a new section with the new version number and date, and list all the changes since the last release under appropriate categories (Added, Changed, Fixed, etc.). If there is no CHANGELOG.md, create one using the standard format. Note only the user-facing changes should be listed in the changelog, not internal refactors or non-user-facing changes. If they are some, mention them very briefly - high level only, without technical details.OTHER RULES: