원클릭으로
tenzir-ship
Use when adding changelog entries, creating release notes, cutting releases, and publishing them to GitHub.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
메뉴
Use when adding changelog entries, creating release notes, cutting releases, and publishing them to GitHub.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Answer questions about Microsoft Sentinel ASIM (Advanced Security Information Model). Use whenever the user asks about ASIM schemas, normalized Microsoft Sentinel fields, field classes, aliases, schema mapping, or mapping events and entities into ASIM.
Answer questions about OCSF (Open Cybersecurity Schema Framework). Use when the user asks about OCSF classes, objects, attributes, profiles, extensions, or event normalization.
Answer questions using the Tenzir documentation. Use whenever the user asks about TQL syntax, pipeline operators, functions, data parsing or transformation, normalization, OCSF mapping, enrichment, lookup tables, contexts, packages, nodes, platform setup, deployment, configuration, integrations with tools like Splunk, Kafka, S3, Elasticsearch, or any other Tenzir feature. Also use when the user asks how to collect, route, filter, aggregate, or export security data with Tenzir, or needs help writing or debugging TQL pipelines, even if they don't mention 'Tenzir' explicitly but are clearly working in a Tenzir context. Also use for questions about Tenzir the company or product, release notes and changelog, blog posts, and solution use cases.
Manage Tenzir packages across the full lifecycle: add new packages, inspect existing packages, update manifests, extend or remove package capabilities, refactor user-defined operators, maintain tests and examples, configure inputs and contexts, ship deployable pipelines, publish packages, and retire obsolete package surfaces. Use when the user is working in the context of a Tenzir package or wants to organize reusable capabilities as a package.
Ship changes via pull request in Tenzir projects. Use when the user wants to open a PR, push a branch, add or update changelog entries, create a pull request for review, or when they say "ship this", "open a PR", "send this for review", or "push and create a pull request." Also use for follow-up changes to an existing PR.
Coordinate documentation updates alongside code changes. Use when preparing the `.docs/` checkout, creating a matching docs branch, opening a `tenzir/content` documentation pull request, or cross-linking docs and code PRs. Also use when the user mentions "update the docs", "docs PR", ".docs/", or when a code change affects user-facing behavior that should be reflected in the documentation on tenzir.com.
| name | tenzir-ship |
| description | Use when adding changelog entries, creating release notes, cutting releases, and publishing them to GitHub. |
This skill bundles key release engineering use cases with tenzir-ship.
Treat released changelog data as published history. Files under
changelog/releases/, including release notes, manifests, and release entry
files, are immutable once published because they may already exist in GitHub
releases, package registries, documentation, and downstream copies.
For normal follow-up work, add a new changelog entry on top of the existing history. Edit historical release artifacts only for severe publication defects, such as legally or operationally unsafe content, and only when the user explicitly asks for that correction.
bash <skill-dir>/scripts/detect-change-scope.sh: Detects the current
changelog scope. Use this before adding a changelog entry to identify whether
staged, unstaged, or branch changes should drive the entry; the script prints
a suggested diff command and the files in scope.Set up a new changelog workspace before the first entry exists. Prefer the
explicit init command when the task is project setup rather than entry
creation.
Instructions: references/init-changelog-project.md
Add changelog entries as part of shipping bugfixes, changes, and features during day-to-day development.
Instructions: references/add-changelog-entry.md
We distinguish two types of releases:
Prefer a remote release if a workflow exists, and use a local release otherwise.
When running into errors during the release process, obtain additional help by reading the official documentation: