القائمة
Write conventional commits for the hyperfrontend monorepo — types, scopes (Nx project names), one-line subjects, atomic commits, versioning-harness boundaries. Use when committing, splitting work into commits, choosing a commit scope/type, or asked about commit format.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Register friction found while building hyperfrontend demos into the showcase findings registry. Use when a demo consuming @hyperfrontend/features surfaces an unclear API, confusing error, missing feature, docs gap, packaging snag, or DX papercut — file the finding before writing the workaround.
Write README.md files for hyperfrontend libraries and sub-modules. Use when creating library documentation, writing sub-module READMEs, documenting API tables, adding quick start guides, or reviewing README structure compliance.
Write ARCHITECTURE.md files for hyperfrontend libraries. Use when creating architecture documentation, documenting design decisions, adding system overview diagrams, or explaining module composition and data flow.
Coding conventions for the hyperfrontend Nx monorepo. Use when refactoring, adding features, fixing bugs, or writing any new code across libs/, apps/, tools/, or plugins/.
Achieve 100% code coverage for custom ESLint rules. Use when reviewing ESLint rules for coverage gaps, adding missing tests, or applying istanbul ignore comments.
Create custom ESLint rules for the hyperfrontend Nx monorepo.
| name | commit-messages |
| description | Write conventional commits for the hyperfrontend monorepo — types, scopes (Nx project names), one-line subjects, atomic commits, versioning-harness boundaries. Use when committing, splitting work into commits, choosing a commit scope/type, or asked about commit format. |
Format: type(scope): subject — one line, lowercase subject, no period, imperative mood.
| Role | Where |
|---|---|
Message lint (npx cl) | libs/versioning/src/bin/cl.ts (runs in commit-msg hook) |
Guided prompt (npx cz) | libs/versioning/src/bin/cz.js |
| Type list + bump semantics | libs/versioning/src/commits/models/commit-type.ts |
| Scope filtering | nx.json → targetDefaults.version.options.scopeFiltering |
| Hooks | lefthook.yml (pre-commit format, commit-msg cl, pre-push gates) |
feat fix docs style refactor perf test build ci chore revert
Version impact (computed at pre-push by nx version:all — never by hand): feat → minor · fix/perf/revert → patch · ! or BREAKING CHANGE: footer → major (minor while the package major is 0). Other types never bump.
A scope MUST be an Nx project name exactly as written in that project's project.json name field.
npx nx show projects | grep <hint> # verify before committing
✓ lib-features lib-nexus e2e-lib-features demo-clock docs-site tool-app
✗ package-e2e features nexus (directory names, npm names — not project names)
Workspace-level changes (nothing project-owned) use one of the versioning-excluded scopes — these never trigger a bump: @hyperfrontend/workspace (docs/roadmap precedent) · repo · ci · deps · release.
One project per commit. Touching two projects = two commits (see Atomic).
fix(lib-nexus): deliver messages between real broker windowsBREAKING CHANGE: footer) — never used to over-explain reasoning.Each commit is self-contained: it compiles, its tests pass, and it makes one logical change. Split by concern, order foundation → dependent. Never bundle unrelated fixes because they share a file-save.
git commit -m "type(scope): subject" or npx cz — both fine when the message meets the rules above.--no-verify is forbidden. Hooks are the contract: pre-commit formats (auto-stages fixes), commit-msg runs npx cl, pre-push runs typecheck/lint/test/build/e2e + nx version:all.The versioning harness owns these — committing them manually corrupts the release flow (when in doubt read libs/versioning/README.md + the version/version-check target defaults in nx.json):
CHANGELOG.md filespackage.json version fields (any project)lib-<name>@<version>)chore(e2e-lib-<name>): update target project version)project.json name (or a sanctioned workspace scope)!/footer only for real breaks--no-verify