oss-change-workflow

Maintainer-quality workflow for open-source code, documentation, examples, feature requests, bug fixes, regressions, compatibility fixes, or issue-backed patches. Use when changing an OSS repository and the task needs scope control, validation, docs/changelog sync, maturity-aware commit/push or PR handoff, monitored CI closure, and review-comment closure. Pure content changes use a lightweight self-review path; mature-project changes that touch code, behavior, tests, tooling, configuration, dependencies, builds, or runnable examples use mandatory subagent and independent cross-agent-tool review. Do not use for issue triage without repository changes, release preparation, or standalone GitHub CI debugging.

Jump to install

Repository: eunomia-bpf/agent-skills
Last source activity: August 24, 2026 at 09:15
Detected SKILL.md language: English
Stars: 0
Forks: 0

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

A direct command skips the review prompt. Inspect the source before running it.

npx skills add https://github.com/eunomia-bpf/agent-skills --skill oss-change-workflow

The command stays on one line. Scroll horizontally to inspect it before copying.

Prefer a local copy? Download the files currently available to SkillsMP.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

SKILL.md

Source instructions · Read-only preview

Back to search Back to installation

OSS Change Workflow

Use this skill to make an OSS repository change look like a maintainer would accept it. It complements GitHub PR/CI tools; it does not replace them.

Default Mode

Implement the requested change unless the user asks for analysis only. After validation, use the project maturity policy to decide whether to direct-push or use a PR.

Do not merge branches or PRs, force-push, tag releases, publish packages, write changelog entries, or create report files unless the user explicitly asks.

Project Maturity And Branch Policy

Start new work from the repository default branch, main or master, unless the user names another branch, but do not treat this as permission to switch away from an active checkout. Before any branch, worktree, stash, rebase, reset, or commit operation, run git status --short --branch, identify the current branch, upstream state, dirty tracked files, and untracked files, then decide whether moving branches is safe.

When the worktree contains uncommitted changes, untracked files, or signs of another person or agent working in parallel, preserve that state in place. Continue on the current branch if it matches the requested task. If the task needs a different base, ask first or create an explicitly requested separate worktree; do not silently switch branches, stash, reset, or move someone else's work to make the workspace look clean.