oss-signal
v0.9.8
Published
Maintainer-readiness CLI and GitHub Action for OSS triage, CI evidence, inventory reports, SARIF, issue-ready cleanup, workflow trials, adoption packs, transparent rule catalogs, and JSON schemas.
Maintainers
Readme
OSS Maintainer Signal (oss-signal)
oss-signal is a dependency-light maintainer-readiness CLI and GitHub Action for OSS projects that need repeatable triage, CI evidence, SARIF, inventory reports, issue-ready cleanup notes, adoption packs, a transparent rule catalog, and no-fail workflow trials.
It checks the files and automation that reduce maintainer load: README, license, contributing guide, security policy, maintainer ownership, CI, tests, issue templates, pull request templates, Dependabot, and release notes. The output is a score plus concrete next steps in Markdown, JSON, SARIF, inventory, GitHub Issue-ready Markdown, PR-sized maintainer plan, no-fail workflow, adoption-pack, or rule-catalog formats.
30-Second Quick Start
Run a maintainer-readiness report against any public GitHub repository:
npx oss-signal owner/repo --format markdown --output oss-signal-report.mdGenerate an editable issue body before posting a cleanup suggestion:
npx oss-signal owner/repo --format issue --output maintainer-follow-up.mdGenerate a no-fail GitHub Actions trial workflow:
npx oss-signal owner/repo --format workflow --output .github/workflows/oss-signal-trial.ymlGenerate a copyable maintainer adoption pack:
npx oss-signal owner/repo --format adoption --output adoption-pack.mdInspect the rule weights before posting feedback:
npx oss-signal --list-rulesFor the full first-run path, see docs/quickstart.md.
Who It Helps
- Maintainers who want a quick view of missing workflow signals before a release.
- Contributors who want to open small, reviewable documentation or automation PRs.
- Teams that need a repeatable CI artifact for repository health and maintainer-readiness.
- Foundations or working groups that need inventory reports across multiple repositories.
Maintainer Evidence Snapshot
The shortest reviewer path is REVIEWER_PACKET.md. Public evidence for the maintainer workflow is also collected in docs/index.md, docs/quickstart.md, docs/evidence-ledger.md, docs/trust-center.md, docs/reviewer-evidence.md, docs/adoption-evidence.md, docs/codex-for-oss-fit-gap.md, docs/selection-update-2026-06-08.md, docs/adoption-kit.md, docs/maintainer-trial.md, docs/maintainer-feedback.md, docs/social-launch.md, docs/architecture.md, docs/security-model.md, docs/json-output.md, docs/plan-output.md, docs/sarif-code-scanning.md, docs/roadmap.md, docs/post-submission-update.md, and docs/brand.md.
- Landing page: https://salmonplays.github.io/oss-signal/
- Published package:
[email protected], withlatestpointing at0.9.8. - Published GitHub Action:
SalmonPlays/[email protected]. - GitHub Marketplace listing: https://github.com/marketplace/actions/oss-signal
- Trust center: docs/trust-center.md
- Quickstart: docs/quickstart.md
- Root reviewer packet: REVIEWER_PACKET.md
- Reviewer packet: docs/reviewer-packet-2026-06-08.md
- Evidence ledger: docs/evidence-ledger.md
- Evidence verification snapshot: docs/evidence-verification.md
- Codex for OSS fit/gap review: docs/codex-for-oss-fit-gap.md
- Adoption kit: docs/adoption-kit.md
- Maintainer trial: docs/maintainer-trial.md
- Maintainer feedback: docs/maintainer-feedback.md
- Social launch kit: docs/social-launch.md
- Architecture: docs/architecture.md
- Security model: docs/security-model.md
- JSON output contract and schemas: docs/json-output.md, single-repository schema, inventory schema, and rule catalog schema
- Configuration: docs/configuration.md
- Rules and scoring weights: docs/rules.md
- Maintainer plan output: docs/plan-output.md
- SARIF Code Scanning walkthrough: docs/sarif-code-scanning.md
- Roadmap: docs/roadmap.md
- Post-submission version note: the application may reference earlier evidence;
0.9.8is the current maintained release and is documented in docs/post-submission-update.md and docs/selection-update-2026-06-08.md. - Public checks: CI, Repository health, Repository inventory, Evidence verification, and CodeQL are passing on
main. - Security posture: OpenSSF Scorecard is scheduled, CodeQL is active, secret scanning push protection is enabled, Dependabot alerts/security updates/malware alerts are enabled, and private vulnerability reporting is enabled.
- Branch posture:
mainhas branch protection to prevent force pushes and deletions while keeping direct maintainer maintenance possible. - Governance posture: MAINTAINERS.md, GOVERNANCE.md, and .github/CODEOWNERS define ownership, review routing, and supported change scope.
- Community route: Discussion #5 is the public maintainer-workflow thread for usage questions and rule feedback.
- Self-audit: this repository scores 100/100 (A) locally and through GitHub URL mode.
- Field use: five currently visible field-audit issues and four currently visible follow-up PRs remain public, plus two merged external documentation PRs. Historical reports whose public links disappeared are kept as local audit examples but are not counted as public adoption evidence.
- Merged external OSS contribution evidence: icoretech/codex-action PR #24 is a focused Codex Action documentation safety fix accepted by an outside maintainer, and oss-signal PR #14 is an inbound external contributor PR adding a compact JSON score example.
- Contributor intake: good first issues are labeled for small outside PRs.
- Inventory mode: the CLI and Action can audit a newline-delimited list of repositories for organization-level triage.
- Evidence verification:
npm run evidence:verifychecks npm latest, npm download API, GitHub release evidence, repository metadata, and current external issue/PR links; the workflow uploads a Markdown verification artifact and the current snapshot is in docs/evidence-verification.md. - Separate workflow demo: oss-signal-adoption-demo runs the public
v0.8.4Action tag and uploads Markdown, SARIF, Issue-ready, and no-fail workflow artifacts. It remains valid demo evidence while the main repository has advanced tov0.9.8.
Why
Open-source projects often fail quietly because the maintainer workflow is undocumented. oss-signal gives maintainers a repeatable checklist they can run locally, in CI, or before asking contributors to help.
Use Cases
- Maintainers can run it before publishing a new project.
- Contributors can attach a report to a cleanup issue or pull request.
- Teams can gate release readiness with
--fail-under. - Foundations and working groups can compare repository hygiene across many projects.
- CI maintainers can add it as a GitHub Action, show the score in the workflow summary, and publish the report as an artifact.
See docs/maintainer-playbook.md for a concrete maintainer workflow from audit to issue, PR, CI gate, and Code Scanning evidence.
Install
npm install --global oss-signalTry it without installing:
npx oss-signal SalmonPlays/oss-signalUse it from GitHub Marketplace: https://github.com/marketplace/actions/oss-signal
For local development:
git clone https://github.com/SalmonPlays/oss-signal.git
cd oss-signal
npm install
npm testUsage
Audit the current directory:
oss-signalShow a one-screen maintainer triage summary:
oss-signal SalmonPlays/oss-signal --format summaryShow the rule catalog and scoring weights:
oss-signal --list-rules
oss-signal --list-rules --format json --output rules-catalog.jsonAudit a public GitHub repository without cloning it:
oss-signal https://github.com/SalmonPlays/oss-signal
oss-signal platformatic/massimo --format jsonWrite a Markdown report:
oss-signal /path/to/repo --format markdown --output oss-signal-report.mdUse JSON in automation:
oss-signal . --format json --fail-under 80Print a compact shell-friendly score summary (jq optional):
oss-signal . --format json | jq -r '"score=\(.score) grade=\(.grade) source=\(.source)"'See docs/json-output.md for the JSON schema and fixture.
Document intentional exceptions with a local config:
oss-signal . --config .oss-signal.json --format markdownSee docs/configuration.md for not-applicable rules and scoring behavior.
Audit multiple repositories from one newline-delimited inventory file:
oss-signal --inventory docs/examples/inventory-targets.txt --format markdown --output inventory-report.mdSee docs/examples/inventory-report.md for a generated inventory report.
Write SARIF for GitHub Code Scanning or other dashboards:
oss-signal . --format sarif --output oss-signal.sarifSee docs/sarif-code-scanning.md for the Code Scanning upload workflow and expected output.
Generate a report that can be attached to an issue:
oss-signal . --format markdown --output docs/maintainer-readiness.mdGenerate a maintainer-friendly issue body:
oss-signal platformatic/massimo --format issue --output maintainer-follow-up.mdGenerate a PR-sized maintainer plan:
oss-signal platformatic/massimo --format plan --output maintainer-plan.mdSee docs/plan-output.md and docs/examples/github-plan.md for an example.
Generate a maintainer adoption pack:
oss-signal platformatic/massimo --format adoption --output adoption-pack.mdThe adoption pack combines a local trial command, no-fail workflow YAML, suggested maintainer message, decision checklist, current findings, verification links, and boundaries against overstating adoption.
Generate a no-fail GitHub Actions trial workflow:
oss-signal owner/repo --format workflow --output .github/workflows/oss-signal-trial.ymlSee docs/maintainer-trial.md and docs/examples/maintainer-trial-workflow.yml for the generated workflow.
Checks
oss-signal currently checks:
- Community files: README, license, contributing guide, security policy, code of conduct, changelog, support policy, maintainer ownership
- Automation: CI workflows, tests, issue templates, pull request template, Dependabot, CodeQL or similar security workflow
- Package hygiene: package metadata and lockfile presence
See docs/rules.md for rule details and scoring weights.
SARIF output reports failed maintainer-readiness checks as warning-level results. This lets teams upload the audit to code scanning dashboards while keeping the Markdown report available for maintainers. Issue output turns the same findings into a human-reviewed checklist that can be edited before posting. Plan output turns the findings into a PR-sized sequence with suggested files and acceptance criteria.
For GitHub URL audits, oss-signal reads the repository file tree through the GitHub API and also uses GitHub's community profile signal when available. This lets it detect organization-level files such as a shared code of conduct.
Real Output
This repository audits itself at 100/100 (A) and dogfoods the public GitHub Action:
Score: 100/100 (A)
Summary:
- Passed: 16
- Failed: 0
- Total checks: 16See docs/self-audit.md for the full local self-audit report, docs/examples/github-url-report.md for the GitHub URL audit output, docs/examples/github-summary.txt for compact summary output, docs/examples/github-issue-body.md for issue output, docs/examples/github-plan.md for plan output, docs/examples/maintainer-trial-workflow.yml for workflow output, docs/examples/adoption-pack.md for adoption-pack output, docs/examples/self-audit.sarif for SARIF output, and docs/examples/rules-catalog.json for the machine-readable rule catalog.
The Repository health workflow runs SalmonPlays/[email protected], uploads the Markdown report and adoption pack as artifacts, includes a SHA256 checksum manifest, and uploads SARIF to GitHub Code Scanning on non-PR runs. The Repository inventory workflow runs the inventory mode from CI and uploads a multi-repository report artifact.
Field Audits
oss-signal has been run against public repositories to produce maintainer-readiness reports, respectful issue drafts, and focused follow-up PRs:
- platformatic/massimo report, issue #159, and PR #160
- supermarkt/checkjebon report, issue #22, and PR #23
- sammorrisdesign/interactive-feed report, issue #14, and PR #15
- flox/install-flox-action report, issue #204, and PR #205
- Divyesh-5981/signal-oss report and issue #5
See docs/outreach for the reports and draft issue text. Drafts are not posted automatically; maintainers should only receive specific, useful, and respectful suggestions.
Historical audit reports for Grovanni/oss-signal and noctemlabs/signal-oss remain in the repository as examples, but their public issue or PR links were not verifiable on 2026-06-08 and are not counted as current public evidence.
Additional prepared outreach candidates are tracked in docs/outreach/peer-shortlist-2026-06.md. The shortlist explicitly separates respectful, defensible candidates from low-signal mass outreach.
Additional focused external contribution evidence: icoretech/codex-action PR #24 was merged by an outside maintainer and updates Codex Action README examples to route generated output through environment variables before printing it from shell steps. oss-signal PR #14 was opened by an outside contributor and merged into this repository with a compact JSON score example.
For a compact maintainer/adoption summary, see docs/adoption-evidence.md. For a reviewer-oriented verification path, see docs/reviewer-evidence.md.
Separate public workflow evidence: SalmonPlays/oss-signal-adoption-demo runs SalmonPlays/[email protected] and produced a successful workflow run with Markdown, SARIF, Issue-ready, and no-fail workflow artifacts.
Example Recommendation Output
Score: 86/100 (B)
Recommended next steps:
- Static security analysis: Add a CodeQL or equivalent security scanning workflow.
- Support policy: Add SUPPORT.md describing where to ask questions.See docs/examples/minimal-repo-report.md for a small repository example with missing maintainer files.
Exit Codes
By default, oss-signal exits with 0 after writing a report.
When --fail-under <score> is provided, it exits with 1 if the score is below the threshold:
oss-signal . --fail-under 80GitHub Action
Add oss-signal directly to a GitHub Actions workflow:
- uses: SalmonPlays/[email protected]
id: oss-signal
with:
fail-under: "80"
output: oss-signal-report.md
summary: "true"
- run: echo "score ${{ steps.oss-signal.outputs.score }} (${{ steps.oss-signal.outputs.grade }})"The Action writes a concise GitHub Actions step summary by default, so reviewers can see the score and recommended next steps without downloading an artifact. Set summary: "false" to disable it.
Run an inventory from CI:
- uses: SalmonPlays/[email protected]
env:
GITHUB_TOKEN: ${{ github.token }}
with:
inventory: docs/examples/inventory-targets.txt
output: inventory-report.md
summary: "true"Generate an editable Issue body from CI:
- uses: SalmonPlays/[email protected]
with:
format: issue
output: maintainer-follow-up.md
summary: "true"Full workflow example:
name: Repository health
on:
pull_request:
push:
branches: [main]
env:
FORCE_JAVASCRIPT_ACTIONS_TO_NODE24: "true"
jobs:
oss-signal:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v5
- uses: SalmonPlays/[email protected]
id: oss-signal
with:
fail-under: "80"
output: oss-signal-report.md
summary: "true"
- uses: actions/upload-artifact@v5
with:
name: oss-signal-report
path: oss-signal-report.mdSee docs/examples/github-action-workflow.yml for a copyable workflow, docs/examples/github-inventory-workflow.yml for an inventory workflow, and docs/examples/github-code-scanning-workflow.yml for a workflow that uploads SARIF to GitHub Code Scanning.
Upload SARIF to GitHub Code Scanning:
permissions:
contents: read
security-events: write
steps:
- uses: actions/checkout@v5
- uses: SalmonPlays/[email protected]
with:
format: sarif
output: oss-signal.sarif
summary: "true"
- uses: github/codeql-action/upload-sarif@v4
with:
sarif_file: oss-signal.sarifThis repository dogfoods the public Action tag in Repository health, which runs SalmonPlays/[email protected] against the repository, uploads Markdown and adoption-pack artifacts with a SHA256 manifest, and publishes SARIF to Code Scanning on non-PR runs.
You can also run the CLI directly in CI:
- run: npx oss-signal . --format markdown --output oss-signal-report.md --fail-under 80Current Limitations
- It checks deterministic maintenance signals, not code quality or project importance.
- GitHub URL mode uses unauthenticated API requests unless
GITHUB_TOKENis set, so very heavy usage may hit GitHub rate limits. - A high score does not prove a project is important. It proves the maintainer workflow is documented and automatable.
Roadmap
- Ecosystem-specific profiles for Python, Rust, Go, and JavaScript packages
- Release automation and provenance metadata checks
- Maintainer score trends over time
- Organization-level repository inventory dashboards
Release Process
Releases use the checklist in docs/release-process.md. The repository also includes a tag-triggered release workflow that verifies the package, creates a GitHub Release, and publishes to npm with Trusted Publishing provenance.
Contributing
Contributions are welcome. Please read CONTRIBUTING.md before opening a pull request.
Security
Please report security issues privately. See SECURITY.md.
License
MIT
