release-flow

Files (6)

• SKILL.md
• .gitkeep · assets/
• .gitkeep · examples/
• .gitkeep · references/
• .gitkeep · scripts/
• .gitkeep · templates/

SKILL.md (first lines)

# Release Flow

Prepare releases as verified, explainable changes rather than as version-only edits.

## Scope

- Apply this skill only while working in this template repository.
- Do not apply it to generated application projects or unrelated repositories.

## Release Execution Order

For an explicitly authorized release, follow this order:

1. Bump the package or artifact version and update matching release metadata.
2. Run the required validation, inspect the artifact, and commit the intended changes with hooks.
3. Push the release commit to the tracked remote branch.
4. Create a new annotated version tag at the release commit and push the tag.
5. Publish the artifact through the repository-approved package or release wrapper.

Do not publish before the release commit and its new tag have been pushed. Never bypass hooks or use
force-pushes during this sequence.

## Impact Review

1. Inspect the commits, diff, package manifests, generated artifacts, and current release metadata.
2. Identify public API, contract, database, migration, configuration, environment, dependency,
   security, observability, and operational changes.
3. Determine whether the change is breaking, additive, corrective, or internal.
4. Check required migration order, rollout sequencing, feature flags, backfills, compatibility windows,
   deprecations, and rollback constraints.

## Versioning and Notes

- Follow the repository's versioning policy and package ownership boundaries.
- Use semantic versioning only when the project treats the artifact as a semantic-versioned package.
- Write release notes for users and operators, not just implementation details.
- Include behavior changes, breaking changes, fixes, security notes, migrations, configuration changes,
  dependency requirements, known limitations, and required follow-up actions.
- Do not include secrets, private URLs, customer data, or unverifiable claims.

## Commit Messages

- Use a valid Conventional Commit subject in the form `<type>(<scope>): <subject>` with an allowed
  repository type. Subjects may be up to 120 characters, but keep them specific and concise.
- Add a blank line followed by a detailed body to every intentional commit. Body lines may be up to
  700 characters; this is a per-line limit, not a total body limit.
- Explain what changed and why, then include relevant user-visible, compatibility, migration, security,
  operational, or release impact and the validation or tests performed.
- Keep the body factual and useful. Do not include secrets, unverifiable claims, or filler.

## Verification

- Run the repository's required build, typecheck, lint, test, format, package, and artifact checks.
- Confirm generated files and package exports are current.
- Verify migrations are reversible or document the irreversible step and recovery plan.
- Verify changelog and release notes match the actual diff.
- Confirm the release can be reproduced from the intended commit and clean working tree.
- **Never use `--no-verify`, `--no-hooks`, `HUSKY=0`, skipped hooks, or disabled checks.** Fix the
  underlying failure instead.
- **Never commit, amend, push, force-push, tag, publish, release, or deploy without explicit user
  permission for that specific action.** Permission to prepare a release does not authorize execution.

From gowebknot/monorepo-template, MIT.

More from gowebknot/monorepo-template