القائمة
Use when creating, updating, reviewing, or releasing a CHANGELOG.md file, summarizing user-visible changes, or choosing the next semantic version for a release.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use when Codex works with Karpik.Memory, native containers, unmanaged allocation, NativeArray, NativeSlice, NativeResult, NativeLinearAllocator, NativePool, NativeArena, SimpleNativeArray migration, no-GC storage, allocation-budget tests, or memory ownership in KarpikEngine hot paths.
Dragon ECS rules for KarpikEngine. Use when Codex implements or reviews entities, IEcsComponent structs, EcsPool/EcsReadonlyPool access, EcsAspect filters, ECS systems, IEcsRun/IEcsInit/IEcsRunParallel, or ECS data layout.
Core KarpikEngine architecture rules. Use when Codex changes or reviews Client/Server/Shared boundaries, module lifecycle, Bootstrap, tick/update loops, DI, project structure, or cross-module APIs.
Real-time C# performance rules for KarpikEngine. Use when Codex works on hot paths, frame loops, ECS systems, allocation-sensitive code, cache locality, SIMD, NativeMemory, Unsafe, lock-free structures, or low-level optimization.
KarpikEngine Hot Reload rules. Use when Codex works on HotReloadHandler, IPC reload flow, IpcClient/IpcServer, PluginLoadContext, plugin assembly loading, reload-safe state, ECS state preservation, or module reload behavior.
KarpikEngine networking rules. Use when Codex works on RPC, Network.Codegen, IReader/IWriter serialization, client-server validation, IPeer, ITargetRpcSender, delivery methods, connection state, replication, prediction, or network hot paths.
| name | maintaining-changelogs |
| description | Use when creating, updating, reviewing, or releasing a CHANGELOG.md file, summarizing user-visible changes, or choosing the next semantic version for a release. |
Maintain a human-readable CHANGELOG.md using Keep a Changelog 1.1.0 and choose releases using Semantic Versioning 2.0.0. Write release notes for users and maintainers, not as a raw commit dump.
CHANGELOG.md and repository version/tag conventions.## [Unreleased]. Group entries by category.Unreleased into ## [X.Y.Z] - YYYY-MM-DD, and keep newest releases first.Use only categories that contain entries:
Added for new features.Changed for changes to existing behavior.Deprecated for features planned for removal.Removed for removed features.Fixed for bug fixes.Security for vulnerability fixes.Prefer concise bullets describing impact. Add migration instructions when users must change code, configuration, data, or deployment steps.
# Changelog
## [Unreleased]
### Added
- Added deterministic module dependency validation.
## [0.5.0] - 2026-06-02
### Changed
- Replaced direct module references with generated dependency metadata.
Use MAJOR.MINOR.PATCH:
| Increment | Choose when |
|---|---|
MAJOR | A public API or supported behavior changes incompatibly. |
MINOR | Backward-compatible functionality is added, including a backward-compatible deprecation. |
PATCH | Backward-compatible defects are fixed. |
Apply the highest required increment when a release contains multiple changes. Reset lower components after an increment. Treat 0.y.z as initial development: compatibility is not stable, but still explain breaking changes clearly.
Use pre-release suffixes such as 1.0.0-alpha.1 for unstable release candidates. Build metadata such as 1.0.0+build.17 does not affect precedence. Do not modify the contents of an already released version; publish a new version.
When the repository URL and tags are known, make versions linkable and add compare links at the bottom:
[Unreleased]: https://github.com/org/repo/compare/v0.5.0...HEAD
[0.5.0]: https://github.com/org/repo/compare/v0.4.0...v0.5.0
Respect an existing repository convention for a v prefix in Git tags. Keep the semantic version itself in X.Y.Z form.
Unreleased section for pending work.YYYY-MM-DD.misc fixes, implementation-only details, and duplicate entries.