oss-maintainer-workflow

OSS Maintainer Workflow

Run one small, verifiable maintenance cycle for a public repository. The goal is

not activity volume. The goal is a real maintainer outcome backed by public

issues, pull requests, CI, security checks, release notes, and honest adoption

evidence.

Input Artifacts

• Public repository URL and license
• Current issue and pull request queue
• Latest release and changelog
• CI and dependency/security status
• Real user feedback, external listings, or downstream references when they exist

Output Artifact

• docs/oss-maintenance/<cycle>/01-intake-and-signals.md
• docs/oss-maintenance/<cycle>/02-maintenance-plan.md
• docs/oss-maintenance/<cycle>/03-change-and-review-evidence.md
• docs/oss-maintenance/<cycle>/04-release-readiness.md
• docs/oss-maintenance/<cycle>/05-adoption-follow-up.md

Required MCP Tool

• plan_oss_maintenance_cycle
• review_oss_release_readiness

Required Flow

1. Inspect the public repository, open issues, open pull requests, last release,

CI, dependency audit, and security policy.

1. Call plan_oss_maintenance_cycle with source-backed counts. Do not estimate

stars, downloads, users, or vulnerabilities.

1. Select the smallest meaningful change. Security fixes and maintainer-requested

review changes outrank speculative features.

1. Record either a real issue link or a concise rationale. Do not manufacture an

issue solely to make the repository look active.

1. Implement on a reviewable branch and run the repository's relevant tests,

build, validation, and security audit.

1. Open or update a pull request. Link the diff, checks, review findings, and

rollback path in the maintenance evidence.

1. Update user documentation and CHANGELOG.md.
2. Call review_oss_release_readiness. Do not tag or publish while it reports

blocked.

1. After the pull request is merged, tag and publish the documented version.
2. Record only real adoption signals in the follow-up artifact.

Evidence Rules

• Prefer GitHub URLs and reproducible command output over prose claims.
• A directory listing is ecosystem evidence; it is not proof of active users.
• A star is a repository signal; it is not automatically a user or deployment.
• A normal contribution to someone else's project does not make the contributor

a primary or core maintainer.

• If no user feedback exists, say so and invite real testing. Never fabricate it.

Hard Stops

• No release with unresolved critical or high security findings.
• No release without fresh passing tests and required build or plugin validation.
• No release without documentation, changelog, and review evidence.
• No invented stars, downloads, users, issues, pull requests, or maintainer roles.
• No large speculative feature when a smaller security, compatibility, or

maintainer-requested fix is available.

Pressure Test Responsibility

• Block a cosmetic release whose only purpose is repository activity.
• Block a release supported only by stale CI or an old security scan.
• Block adoption claims that cannot be linked to a public source.
• Block a claim of core-maintainer status without repository permission or

sustained review and release responsibility.

Next Gate

• review_oss_release_readiness.nextAllowedAction

Reference

Read references/maintenance-evidence-contract.md before preparing the release

gate or reporting ecosystem and adoption signals.