القائمة
Invoke before committing user-facing changes (new features, bug fixes, behavior changes) to update CHANGELOG.md. Skip for internal refactors, CI, docs-only, or minor dependency bumps.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
MUST invoke before creating any git commit. Provides commit message format and safety rules.
Use when choosing or running JETLS tests after code changes. Prefer component-specific tests, avoid the full suite unless needed, and use TestRunner for focused iteration.
Use when adding or modifying JETLS tests. Covers test file and module structure, `@testset` organization, `let` blocks, `withserver` usage, and when subroutine tests are sufficient for language-server features.
When running as Zed's built-in coding agent in JETLS, prefer the faster built-in diagnostics tool for project instructions that require `jetls check` or `./scripts/selfcheck.sh`, with fallback to selfcheck when needed.
| name | changelog |
| description | Invoke before committing user-facing changes (new features, bug fixes, behavior changes) to update CHANGELOG.md. Skip for internal refactors, CI, docs-only, or minor dependency bumps. |
This project follows Keep a Changelog.
CHANGELOG.md is exempt from the 80-character Markdown line length rule because it is used for GitHub release notes, where hard line breaks disrupt rendering.
That said, do not put everything on a single line unconditionally. Break lines at natural points (sentence boundaries, after colons, etc.) when an entry is long enough to benefit from it. Short, single-sentence entries are fine as one line.
New entries go under the ## Unreleased section.
Use the following subsections as needed (in this order):
### Announcement -- important notices (always first if present)### Added -- new features### Changed -- changes to existing functionality### Fixed -- bug fixeslowering/undef-local-var now ...").(Closed https://github.com/aviatesk/JETLS.jl/issues/NNN).Write entries from the user's perspective. Describe what changed in terms of user-visible behavior — not implementation details.