القائمة
Use when preparing or reviewing a SHAFT release, dependency updates, static versions, or Maven Central safeguards.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use when analyzing SHAFT Allure results, Doctor reports, trace evidence, healer output, flaky locator/wait/assertion failures, retries, or test-fix recommendations.
Use when creating, reviewing, refactoring, repairing, or generating SHAFT web/mobile locators, smart locators, ARIA locators, XPath/CSS replacements, or codegen element identifiers.
Use when recording browser, Playwright, mobile, Appium Inspector, or user-performed flows into SHAFT tests with MCP Capture, replay, code blocks, or codegen insertion.
Use when reviewing, previewing, applying, guardrail-checking, or verifying generated SHAFT Java before or after inserting it into a repository, especially the coding-partner diff/apply/verify loop from IntelliJ.
Use when writing, reviewing, or repairing SHAFT Java tests, page objects, API tests, mobile tests, CLI/DB tests, assertions, waits, or TestNG/JUnit/Cucumber scenarios.
Forces the laziest solution that actually works, simplest, shortest, most minimal. Channels a senior dev who has seen everything: question whether the task needs to exist at all (YAGNI), reach for the standard library before custom code, native platform features before dependencies, one line before fifty. Supports intensity levels: lite, full (default), ultra. Use on ANY coding task: writing, adding, refactoring, fixing, reviewing, or designing code, and choosing libraries or dependencies. Also use whenever the user says "ponytail", "be lazy", "lazy mode", "simplest solution", "minimal solution", "yagni", "do less", or "shortest path", or complains about over-engineering, bloat, boilerplate, or unnecessary dependencies. Do NOT use for non-coding requests (general knowledge, prose, translation, summaries, recipes).
| name | release-dependency-guard |
| description | Use when preparing or reviewing a SHAFT release, dependency updates, static versions, or Maven Central safeguards. |
Use only for release preparation, release review, or dependency-currency work. Never run deployment or publication commands locally.
Inspect recent merged release PRs and executable workflows before relying on
prose. Compute versions as {major}.{quarter}.{YYYYMMDD}.
Keep the root project version, every reactor child parent, and SHAFT inter-module dependency aligned. Run:
python3 scripts/ci/validate_reactor_versions.py
Update shaft-engine/src/main/java/com/shaft/properties/internal/Internal.java
shaftEngineVersion. Verify allure3Version against the stable npm package
and nodeLtsVersion against the current LTS patch using primary sources.
Verify every other version default in Internal.java against its source
registry when it changes. Keep non-Maven static versions in Internal.java;
move stray version literals there.
Update all example and consumer-fixture <shaft.version> values found by:
rg -l "<shaft.version>" -g "pom.xml"
Check Maven dependency/plugin/property updates. Accept stable ones after compatibility review; do not treat alpha, beta, RC, milestone, or snapshot releases as upgrades.
Validate release metadata and publication rules with existing scripts, including Maven Central POM/JAR/classifier/signature, the IntelliJ IDEA plugin release candidate, and canonical, combined-module, and legacy-relocation consumer checks.
Run one compile/package pass after metadata is aligned. Do not rerun broad product tests for metadata-only changes unless source/test behavior changed.
Verify the release version is newer than any immutable Maven Central
coordinate it replaces. Merging to main triggers publication; local
deploy, signing, and scm-publish are prohibited.
List blockers first, then version alignment, stable updates considered, commands and results, source checks for volatile versions, and remaining publication risk.