القائمة
Use when cutting a NativeProof release, bumping the package version, or writing a CHANGELOG entry. Covers the Keep a Changelog entry format and the GitHub-Release-driven npm publish flow.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | release-changelog |
| description | Use when cutting a NativeProof release, bumping the package version, or writing a CHANGELOG entry. Covers the Keep a Changelog entry format and the GitHub-Release-driven npm publish flow. |
Publishing is CI-owned: cutting a GitHub Release (or a manual run of the
publish workflow) runs npm run check + npm test on a clean checkout and
then npm publish. Never publish from a laptop — that skips the clean-checkout
gate and the Automation-token auth.
Bump version in package.json following semver.
Add a CHANGELOG entry at the top, matching the existing house style:
## <version>
One headline sentence naming the release's main story.
**Added**
- Consumer-visible additions, written for the person running NativeProof.
**Changed**
- Behaviour changes and their reason.
**Fixed**
- Bugs fixed, described by symptom.
Include only the groups that apply. Minor releases lead with the headline sentence; a patch-only entry may go straight to the groups. Write entries for consumers, not for reviewers of the diff — name the command or API a user touches.
Land the bump + changelog on main through a normal PR (all Definition of
Done gates apply).
Cut a GitHub Release with the tag equal to the version (e.g. 0.10.15)
targeting the merged commit on main. Publishing then happens in
.github/workflows/publish.yml; watch the run to completion.
npm publish run locally.package.json version.npm view nativeproof version reports the new version after the publish
workflow succeeds, and the CHANGELOG's top entry matches the released tag.
Use when a change touches device or Appium behaviour (driver, gestures, locators, ios/adb helpers, runner) and the Definition of Done requires running the focused device lane, or when a PR needs on-device screenshot proof. Explains how to run a real spec on a booted simulator/emulator and where the evidence lands.
Use when a change touches the CLI, init/onboard scaffolding, or the generated project surface (src/cli.ts, templates, runner-config) and the Definition of Done requires proof that the generated project still works. Produces that proof from the packed tarball, not from the repo checkout.
Use when opening or updating a GitHub pull request that needs screenshots, videos, or proof artifacts rendered inline in the PR description instead of shown as plain links.