agent-skillsSAFE

From the repository's own README, as read at the audited commit. Badges and raw HTML are left out.

npx skills@latest add mikemcg87/agent-skills

The instruction file, verbatim from the audited commit — this is the text the model reads, and the surface the audit's instruction layer examines. Quoted here so you can judge it without cloning anything.

---
name: contributing-to-open-source
description: Use when landing a change in a project the user does not own — choosing a repository worth contributing to, checking whether outside pull requests actually merge, opening an issue or a PR, or responding to review. Covers triage, contribution-channel checks, evidence expectations and the review loop, and works for any repository, not one named project.
license: MIT
metadata:
  author: Michael McGlade
  version: "1.0.0"
---

# Contributing to open source

Helping a user land changes in someone else's project. The work is mostly
judgement before the diff: which project, is the issue still real, what evidence
this maintainer expects.

## Always-on rules

- **The merged commit is the unit of success.** A comment, a review, or a PR the
  maintainer rewrites and merges is progress; only a commit on the default branch
  counts. Optimise for the merge, not for being right.
- **Openness decides everything.** A project that merges nothing from outside is
  a wall, whatever its star count. Check before reading any code.
- **Never claim a limitation you have not searched for.** "I could not find a way
  to do X — is there one?" is allowed. "X is not possible" is a claim that will
  be corrected in public.
- **Run the project's gates, not the ones you would have chosen**, and say
  plainly what you ran and what you did not.
- **Prefer a small and recent project over a large and famous one.** Being
  noticed is a function of how many contributions compete with yours.

## Deciding whether a project is worth the user's time

List the last 20–50 merged pull requests and count how many authors are not the
maintainer. Then read recent commit activity, the median time from issue opened
to closed, and how many open issues have no assignee.

Done when: there is a **number** for outside-authored merges, and it is not zero.

Where candidates come from, in rough order of yield: package and plugin
registries; the client and plugin layer around a funded platform; the public
stars of engineers the user respects, and the other repositories of a project's
top contributors; the release and issue feeds a repository already publishes;
and the user's own professional domain, where they are not interchangeable.

## Before writing code

1. Read `CONTRIBUTING.md`. Follow what it asks, including whether it wants an
   issue before a pull request.
2. Search open and recently merged pull requests, and the recent log, for a
   sibling change. Many projects file an issue and a PR together.
3. Check the issue against the default branch **now**. Issues go stale; say so
   if the behaviour was fixed after it was filed.
4. Establish how the project takes contributions at all — pull requests, a
   mailing list, or a review tool of its own. A popular project that does not
   take pull requests is not a target.
5. Where the intended behaviour looks deliberate, or an issue describes
   something that does not exist, stop and ask with evidence: state what you
   found and the two options, and ask which one is wanted.

Done when: the process is known, no sibling exists, the issue still reproduces,
and any ambiguity has been put to the maintainer as a question rather than a
guess.

## Writing the change

- **Keep the diff small.** Split work that is large, and say so.
- **Match the project's conventions, not the user's**: commit message format,
  branch naming, where screenshots are hosted, changelog rules. Read recent
  commits before writing one; many projects enforce these with hooks and CI.
- **A field added to a type that participates in equality or validation is not a
  no-op.** It silently joins every comparison. Where that type is compared for a
  security or validity decision, remove the derived equality and compare the
  fields that matter explicitly, so the next change cannot repeat the mistake.
- **Ask who else reads what you create.** If you make a file, a directory, or a
  record, something else may scan it before you finish — a discovery index, a
  watcher, a scheduled job. Half-finished state that is merely *visible* is
  still a defect.
- **Fail safe**: an operation that fails partway should leave no half-state, and
  a retry should be possible.

## Proving it works

- Run the project's documented gates. Where it has feature flags, channels, or
  platform variants, exercise them — default runs miss exactly those paths.
- **Test the payload the service actually sends, not the one you would design.**
  An absent field and a present-but-null field are different inputs; read the
  fixtures and test what really arrives.
- Provide the evidence this project expects: tests, a UI screenshot, a
  before-and-after number. Find out which before opening the PR.
- Assume CI may not run for outside contributors. On projects that skip it, the
  local run is the only check that exists, and the maintainer's own run is the
  one that finds what it missed.

Done when: the project's gates pass on the full matrix, the real payload is
covered by a test, and the description names what was not run.

## The review loop

- Two reviewers is normal: an automated one and a human. Take the automated one
  seriously — it catches concurrency, performance and edge-case defects a human
  will not read closely enough to find — but it is not complete.
- **Fix, do not argue.** Reply with what changed and why. Disagree plainly when
  there is a reason, not reflexively.
- **Expect the maintainer to reshape the work.** It is their product. They may
  change the design, push commits to the branch, or replace the approach. That
  is a success: the idea landed.
- **Generalise each correction before fixing it.** Most review comments are
  instances of a class; fix the class.

## After it lands

Use the feature as a user would, on the merged code — that is where the things
no test covers live. Record what changed, what was learned, who responded, and
what they changed about the work; over a year that log outperforms an

SAFEgrade B · trust 89/100 Nothing in the source contradicts what it says it does. Grade A is reserved for packages that have also passed the behavioural sandbox.

What the source does

Filesystem

none-observed

Network

none-observed

Shell

none-observed

Dependencies

pinned

Secrets in source

none-found

Findings (0)

No findings outside the package's declared scope.

Gates applied: no_behavioural_pass.