القائمة
Use when preparing a Cities: Skylines II mod to package, upload, publish, distribute, or release to Paradox Mods or another public channel.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use when working on Cities: Skylines II modding, mod projects, C#/UI mods, localization, scaffold, analyze, build, package, or playtesting handoff requests.
Use when debugging Cities: Skylines II mod build failures, packaging failures, runtime errors, game logs, UI debugger issues, or mod behavior that does not work in game.
Use when reviewing a Cities: Skylines II mod for safety, maintainability, user value, packaging hygiene, verification gaps, or readiness to improve.
Use when answering Cities: Skylines II gameplay, city-management, mechanics, patch/update, or known-issue questions.
| name | cities2-mod-release |
| description | Use when preparing a Cities: Skylines II mod to package, upload, publish, distribute, or release to Paradox Mods or another public channel. |
| metadata | {"short-description":"Check CS2 mod release readiness"} |
Use this skill before packaging, uploading, publishing, distributing, or otherwise releasing a CS2 mod. The goal is to prevent ordinary release mistakes before they reach players.
Use MCP server wiki/reference lookup for CS2-specific packaging, toolchain, and modding claims before treating them as release requirements. Use project files, build output, package contents, logs, screenshots, and user playtesting notes as release evidence.
A successful build is not enough for distribution. Before public release, require local playtesting of the packaged mod in game, or an explicit user override that the release is not gameplay-verified.
An override is valid only if, after you restate that the mod has not been locally playtested, the user explicitly confirms they understand that risk and still want an unverified package. A casual request such as "release it now" or "it is tiny" is not enough. Without local playtesting or that explicit override, do not create a distribution package, final upload text, or any handoff that calls the mod ready for public upload.
If the user chooses the override, label the release notes or handoff as not gameplay-verified and list the missing checks. Do not imply Paradox Mods readiness from compile/package success alone.
For save-affecting mods, pause before release if testing used only a live save. Prefer backed-up saves, copied-save workflows, offline reproduction, and supported APIs.
Modding.log and game logs after launch and after exercising the main feature.Public source does not automatically grant redistribution rights. Before releasing copied, forked, derived, or bundled work, check the license and original mod/source terms.
Keep attribution, license files, copyright notices, asset credits, and required source links. Do not remove notices to make a package look original. If rights are unclear, pause and ask the user whether they have permission or want help replacing the dependency.
When adapting ideas without code/assets, still credit inspirations when the community context expects it, but distinguish courtesy attribution from legal license obligations.
Return a release decision first: ready, ready with explicit user override, or blocked. Then list concrete blockers, warnings, and the smallest next checks.
Use practical language: what must change before upload, what should change soon, and what can wait. Keep normative modding constraints separate from descriptive gameplay statements.