메뉴
Use for this repository when the maintainer asks to prepare or publish a release — «подготовь релиз», «выпусти релиз», "prepare a release", "publish the release". Do not use for ordinary changelog edits, package validation, commits, pushes, or pull requests that are not explicitly a release.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Use when browser work requires choosing between a connector, a local browser, and an existing authenticated session, or when an agent must safely operate the user's logged-in browser - «открой в моём браузере», «используй мою сессию», «поработай в залогиненном браузере», "use my logged-in browser". Do not use for ordinary web research that can be completed with direct HTTP/search tools or for browser implementation details already owned by a project-specific test skill.
Use only when the user explicitly asks to criticize, red-team, pressure-test, or find reasons an idea may fail — «раскритикуй идею», «найди слабые места», «red-team this idea». Do not trigger for ordinary brainstorming, balanced evaluation, implementation review, or when the user only asks to improve an idea.
Use when designing a repeated agent loop, manager/orchestrator skill, multi-agent workflow, evaluator/optimizer cycle, or long-running autonomous process, including turning a recurring manual workflow into one reusable skill — «спроектируй агентный цикл», «оберни ручной процесс в скилл», «сделай скилл-оркестратор», «спроектируй multi-agent workflow», "design an agent loop", "design a graph-structured workflow". Do not use for auditing ordinary Agent Skills, one-off delegation, simple linear scripts, ordinary project planning, or adding multiple agents without a demonstrated coordination need.
Use when the user explicitly invokes x9-diagrams, needs a choice between diagram formats, converts or reviews diagrams across formats, or needs one visual method with native creation and verification in Excalidraw, Mermaid, or draw.io/diagrams.net. Also use for requests such as “choose the right diagram format”, “convert this Mermaid diagram to editable draw.io”, «выбери формат схемы», «проверь и улучши диаграмму». A Mermaid-only syntax request may remain with an installed specialized Mermaid skill. Do not use for data charts, UI mockups, raster illustration, or unsupported diagram formats.
Use when creating or substantively editing documentation in an OKF repository, adopting OKF for Markdown, repairing or migrating legacy metadata, or when repository instructions still name the former x9-okf-adapt skill — «создай OKF-документ», «обнови этот документ», «адаптируй папку под OKF», "migrate docs to OKF". Do not use for reading documents, ordinary Markdown cleanup, rewriting body prose without an OKF requirement, or treating repository instruction files as OKF documents.
Use when the user wants a genuinely researched answer from current or primary sources, including X/Twitter or Reddit — «разберись в вопросе», «изучи тему», «собери факты», "research this", "verify this claim". Also use for durable research intent in varied wording — «создай ресерч в папке», «сохрани исследование», «обнови ресерч», "save/update this research" — and for explicit HTML delivery — «ресерч по теме X + html», «подготовь HTML-отчёт с источниками», «нужна HTML-версия», "research X and deliver it as HTML". Infer semantic intent rather than requiring an exact trigger phrase. Do not use for library/API documentation (find-docs), product search owned by another skill, personal advice, or questions answerable from stable supplied context. Mentioning HTML only as the research subject does not request HTML files.
| name | release |
| description | Use for this repository when the maintainer asks to prepare or publish a release — «подготовь релиз», «выпусти релиз», "prepare a release", "publish the release". Do not use for ordinary changelog edits, package validation, commits, pushes, or pull requests that are not explicitly a release. |
| metadata | {"internal":true} |
Prepare or publish a version of x9-agent-skills from the complete repository state. The latest public tag, the diff to the release candidate, CHANGELOG.md, both plugin manifests, the validation workflow, and the release workflow are the sources of truth; do not infer release scope from the current conversation or recent commits alone.
This is a private repository-local skill for Claude Code and Codex. Its canonical source is .claude/skills/release; .agents/skills exposes that source through a repository-relative symlink. Do not add it to the public skills/ package or its manifests and READMEs.
main, and monitoring until the matching GitHub Release is visible or a concrete failure is reported.An ordinary request to commit, push, merge, edit the changelog, or validate the package is not release authority. Never create or move a tag manually; .github/workflows/release.yml owns tag and GitHub Release creation after the pushed main commit passes validation.
Resolve the repository root from this skill's location, then inspect:
v* tag;README.md, README.ru.md, CHANGELOG.md, .claude-plugin/plugin.json, .codex-plugin/plugin.json;~/.claude/CLAUDE.md and ~/.codex/AGENTS.md plus the published examples in global-files/;scripts/prepare_release.py, .github/workflows/validate.yml, and .github/workflows/release.yml.Preserve unrelated and user-owned changes. If the candidate cannot be separated from unrelated work, the current branch cannot safely produce the intended main release, or the remote state conflicts with the local history, stop and report the exact blocker instead of rewriting history, discarding files, merging, or force-pushing.
Reconcile every user-visible change since the latest public tag with the release notes. Treat the AUDIT file list from python3 scripts/prepare_release.py --check as a backstop, not a substitute for reading the semantic diff.
Read both READMEs completely and trace every public skill, installation route, compatibility claim, renamed concept, and removed behavior in the candidate to its documentation. A changed public contract must have an accurate corresponding section or an explicit, evidence-backed determination that the change has no README impact. Do not infer coverage from whether a README file appears in the diff.
Keep README.md as the canonical English presentation and README.ru.md materially equivalent. Plan corrections before proposing the version; after confirmation, update the English structure and facts first, then synchronize the Russian localization. Preserve verified commands, identifiers, links, and claims. Do not document this private release skill in either README.
Load the installed humanizer-ru skill for the final Russian text. Apply its documentation-level editing rules without changing meaning or manufacturing facts, then run its bundled scanner against the complete README.ru.md, even when the file did not require a release-specific edit. Resolve the skill and scanner from the live runtime rather than a personal absolute path. If optional packages are missing, use an ephemeral environment instead of changing global Python state. Treat scanner findings as evidence to review, not permission to damage technical accuracy for a score.
Load x9-agent-instructions, then compare the installed personal global files with global-files/AGENTS.md and global-files/CLAUDE.md. The repository files are sanitized published examples: update them from the current personal contracts, preserving the byte-identical shared core and keeping Codex-only and Claude Code-only behavior in their respective runtime adapters.
Never copy credentials, personal paths, machine-specific state, private project names, or unverified runtime observations into global-files/. Replace local installation details with discoverable public instructions and retain the meaning of authority and safety boundaries. Keep the README descriptions of the global files accurate in both languages.
Release authority permits reading the personal global files and updating their repository examples; it does not permit editing files under ~/.claude/ or ~/.codex/. If the personal shared cores disagree or their intended public form is ambiguous, mark preparation BLOCKED instead of choosing a source or modifying home-directory files.
Propose the version from the strongest change in the full candidate and cite the changes that determine the bump:
1.0.0, use PATCH for backward-compatible corrections that do not intentionally change a skill's capability, trigger, workflow, output contract, installation route, or supported runtime behavior; use MINOR for a new capability or any intentional change to those public contracts.1.0.0 only after an explicit maintainer decision that public names, installation and update routes, and supported behavior are stable enough for normal compatibility guarantees.1.0.0, use MAJOR for incompatible public-contract changes, MINOR for backward-compatible capabilities, and PATCH for backward-compatible fixes.Obtain the maintainer's confirmation through the runtime's structured question tool as defined in version-confirmation.md, even when the initial request names a version. Never use a plain chat question for this gate. If the proposed version already has a public tag or GitHub Release, stop; a released version is immutable and must be corrected with a new version.
After version confirmation:
Unreleased content into ## X.Y.Z - YYYY-MM-DD;Unreleased template with Highlights, Install / update, Compatibility, and Breaking changes;None. explicitly when there are no breaking changes;global-files/ with the current personal global contracts;X.Y.Z in both plugin manifests.Do not include private paths, credentials, tokens, cookies, fabricated evidence, or changes outside the confirmed candidate.
Run the complete command set in checks.md. A failed command blocks preparation and publication until it is fixed or the maintainer explicitly changes scope; never present a partial gate as a successful release.
Preparation is complete when the release diff contains the confirmed version and date, both manifests agree, Unreleased is reset, the notes cover the tag-to-candidate diff, every public change is accurately represented in both READMEs or has a justified no-impact determination, the global examples match the sanitized current personal contracts, and every required check passes.
Publication requires all preparation conditions plus explicit publish authority. Commit the coherent release candidate without absorbing unrelated changes, push the release commit to main without force, and monitor the repository's validation and release workflows.
Publication is complete only when the GitHub Release for vX.Y.Z is visible and points to the released commit. If a workflow fails, the tag points elsewhere, GitHub is unreachable, or the release does not appear after the workflows terminate, report the concrete state and stop without manufacturing or moving the tag.