AgentStack
SKILL verified MIT Self-run

Release Workflow

skill-yipxiyi-openarc-release-workflow · by Yipxiyi

Use when cutting or merging branches, making commits, opening pull requests, preparing release notes, or triggering GitHub release updates in an OpenArc-governed repository.

No reviews yet
0 installs
11 views
0.0% view→install

Install

$ agentstack add skill-yipxiyi-openarc-release-workflow

✓ scanned · ✓ verified — works with Claude Code, Cursor, and more.

Security review

✓ Passed

No issues found. Passed automated security review. · v0.1.0 How review works →

  • Prompt-injection patterns
  • Secret / credential exfiltration
  • Dangerous shell & filesystem operations
  • Untrusted network calls
  • Known-malicious package signatures

What it can access

  • Network access No
  • Filesystem access No
  • Shell / process execution No
  • Environment & secrets No
  • Dynamic code execution No

From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.

Are you the author of Release Workflow? Claim this listing to set pricing, connect Stripe payouts, and keep 70% of every sale.
Sign up to claim

About

Release Workflow

Use this skill when the user wants standardized branch, commit, PR, merge, or GitHub release work.

Preconditions

Before changing git state:

  1. Inspect current branch and working tree.
  2. Identify user changes and do not overwrite them.
  3. Confirm the target base branch.
  4. Use version-governance when the change affects release version.
  5. Run relevant validation before PR or release.

Branch Rules

Default branch name:

/-

Allowed types:

  • feature
  • fix
  • docs
  • refactor
  • chore
  • release
  • migration

Examples:

  • feature/0.2.0-workspace-migration
  • fix/0.2.1-prd-clarification-flow
  • release/0.2.0

Commit Rules

Use conventional commits:

(): 

Examples:

  • feat(openarc): add workspace migration skill
  • docs(brand): clarify brainstorming flow
  • fix(release): require validation before pr

Keep commits focused. Do not mix unrelated changes.

PR Rules

PR body should include:

  • Summary
  • Version impact
  • Validation
  • Risks
  • Rollback
  • Release notes

Use templates/RELEASE.template.md for release-facing content when useful.

Update CHANGELOG.md for user-visible changes before opening the PR.

GitHub Release Update

After the PR is ready, trigger the repository's release update mechanism:

  1. Prefer the repo's existing GitHub Actions workflow, release-drafter config, semantic-release setup, or documented release script.
  2. If a workflow exists, trigger it with the confirmed version and release notes.
  3. If no release automation exists, create or update a draft GitHub release only after the user confirms.
  4. Never publish a final release without explicit user confirmation unless the repo automation already defines that behavior.

Merge Rules

  • Merge only after required checks pass or the user explicitly accepts the risk.
  • Use the repository's preferred merge strategy.
  • After merge, verify release automation ran or report why it did not.

Final Report

Report:

  • Branch
  • Commit(s)
  • PR URL
  • Confirmed version
  • Validation
  • Changelog entry
  • Release update trigger/result
  • Any blockers

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

Install and usage instructions live in the source repository linked above.

Reviews

No reviews yet — be the first.

Versions

  • v0.1.0 Imported from the upstream source.