القائمة
Establish lightweight release discipline: definition of merge-ready, versioning/changelog habits, and safe rollout/rollback practices.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | release-manager |
| description | Establish lightweight release discipline: definition of merge-ready, versioning/changelog habits, and safe rollout/rollback practices. |
Use this skill when:
Goal: make shipping predictable with minimal ceremony.
Document the chosen convention in a tracked release doc (e.g. RELEASE.md) and keep it consistent.
gh) playbookUse this section when you need boring, repeatable GitHub mechanics. Prefer gh over ad-hoc UI steps when it's available.
gh/git output as sensitive if it includes tokens or private URLs..gitignore does not fix history).Confirm auth
gh auth status
Create a new repo + push an existing local repo
gh repo create OWNER/REPO --private --source . --remote origin --push
If you already have commits locally, this should set origin and push your current branch. If origin already exists, use git remote -v and push normally.
Push all branches (after a clean history rewrite)
git push -u origin --all
Open a PR from the current branch
gh pr create --fill
Create a GitHub Release from a tag (optional)
gh release create v1.2.3 --notes-file RELEASE_NOTES.md
If you removed large files from history (e.g., ISOs), remember:
main/release branches and CI expectations after rewrite.Change-aware quality pass: diff scope, readability, function size and control flow, comments where non-obvious, and alignment with project linting. Use before merge or with handoff when the user wants industry-style maintainability beyond what tests assert.
Review code changes for correctness, security, project conventions, and maintainability. Use when reviewing a diff, before commit, or when the user asks for a code review.
Receiving-agent protocol. Boots a new agent into the minimum correct context (select + isolate) and produces a clear next-step plan without guessing.
Define and maintain lightweight evaluations (acceptance criteria, regression checks, golden tests) so "green" is objective and repeatable.
Validates a game or interactive product for playability, clarity, feedback, and scale-readiness. Use at milestones, before large scope changes, or when the user asks if the product feels ready or is ready to scale.
Short-lived feature branches; TDD + lint + merge-ready command as exit criteria before commit; push and merge to main (or user-directed flow). Do not default to asking the user to open a PR. Use when implementing a feature or non-trivial fix, when the user asks for branch/git workflow, or after substantial edits that should not stay uncommitted.