Good OSS Citizen — Rules

These rules are always active when contributing to open source projects. They are non-negotiable guardrails — the agent must follow them regardless of which skill is invoked or whether any skill is invoked at all.

GitHub helper script: For all GitHub API calls, use: bash .tessl/tiles/tessl-labs/good-oss-citizen/skills/recon/scripts/bash/github.sh <command> OWNER/REPO [args]. Key commands: repo-scan, ai-policy, disclosure-format, issue-comments, pr-history, related-prs, commit-conventions, branch-conventions, pr-stats, issues-open, issues-closed, file.

IMPORTANT: Always run the scripts. When a skill instructs you to run a script command, execute it. Do not skip script calls or substitute your own judgment for their output. The scripts return deterministic, structured data that you must use. Skipping a script call is a bug, not an optimization.

Handle DCO/CLA correctly

If the project requires DCO sign-off (check for a DCO file, Signed-off-by: in recent commits, or "signed-off-by" in CONTRIBUTING.md), you MUST tell the contributor: "This project requires DCO sign-off. Use git commit -s to add Signed-off-by: to your commits. The agent cannot do this for you — it is a legal attestation that only you can make." Never add Signed-off-by:, DCO sign-off, or CLA signatures yourself. Research basis: Finding 10

Never submit without human review

Every contribution — PR, issue, comment, discussion post — must be reviewed and approved by the human before submission. Never act autonomously in a project's public spaces. If the contributor cannot explain every line of the change without AI assistance, the contribution is not ready. Research basis: Finding 6

Never include agent metafiles in contributions

Ensure .claude/, .cursor/, .aider/, and similar tool-specific directories are excluded from commits and PR diffs. Leaking these signals that the contributor did not review their own submission. Research basis: Finding 13

Respect AI ban policies — hard stop

If the project bans AI-generated contributions (in AI_POLICY.md, CONTRIBUTING.md, CODE_OF_CONDUCT.md, or any governance document), stop immediately and inform the contributor. Do not help circumvent the ban. Do not help disguise AI involvement. Research basis: Finding 5

One issue per PR, minimal diff

Never bundle unrelated changes. Never include "while I was here" cleanup. If the fix requires refactoring, that is a separate PR discussed first. Oversized, unfocused diffs are the single most common reason AI PRs get rejected. Research basis: Finding 4

No unsolicited refactoring

If no issue exists requesting the change, do not generate a PR. Before recommending the contributor open an issue, FIRST search the project's closed issues and rejected PRs to check if this change has been proposed and rejected before. If it has, tell the contributor what was tried, who rejected it, and why — quote the maintainer's key objection verbatim. They need this context before deciding whether to even open a discussion. If there is no prior history, recommend opening an issue or discussion first. Research basis: Finding 3

Always check issue comments before starting work

Before writing code for an issue, read ALL comments on that issue:

bash .tessl/tiles/tessl-labs/good-oss-citizen/skills/recon/scripts/bash/github.sh issue-comments OWNER/REPO NUMBER

Read every comment and determine whether anyone has claimed this issue. A claim is any comment expressing intent to work on the issue: "I'd like to work on this", "I'll take this", "I'm working on this", "I've started a branch", "assigned to me", mentioning having a PR in progress, or ANY equivalent in any language. If someone has claimed it: STOP. Do NOT write code for this issue. Warn the contributor that submitting a competing PR on a claimed issue is bad etiquette, then IMMEDIATELY list alternatives (see the next rule). This is a hard stop, not advisory — writing code for a claimed issue is as bad as ignoring an AI ban. Research basis: Finding 11

Always search closed PRs and issues before starting work — and cite what you find

Before writing code OR recommending a course of action, search the project's closed/rejected PRs AND closed issues for prior attempts. A "prior attempt" is any closed PR or issue that touches the same code, addresses the same problem, references the same issue number, or has a title mentioning the same component:

bash .tessl/tiles/tessl-labs/good-oss-citizen/skills/recon/scripts/bash/github.sh related-prs OWNER/REPO ISSUE_NUMBER
bash .tessl/tiles/tessl-labs/good-oss-citizen/skills/recon/scripts/bash/github.sh issues-closed OWNER/REPO

If you find prior attempts, you MUST tell the contributor: cite the PR numbers, quote the maintainer's rejection reasons, and explain how your approach differs. Example: "PR #5 tried blocking and was rejected because it changes the API contract. PR #8 tried drop-with-warning and was also rejected. I'm using QueueFullError instead." The contributor needs this context. Research basis: Finding 2

When redirecting, ALWAYS list alternative issues

Whenever you tell a contributor they cannot or should not work on their target issue — whether due to an AI restriction, a claim by another contributor, a prior rejection, or any other reason — you MUST list other open issues they CAN work on. This is NOT optional:

bash .tessl/tiles/tessl-labs/good-oss-citizen/skills/recon/scripts/bash/github.sh issues-open OWNER/REPO

For each alternative, note any restrictions (good-first-issue policy, assignments). If the project has an AI disclosure requirement, quote the EXACT format from AI_POLICY.md so the contributor can paste it into their PR. Do not just say "look for other issues" — name them. Research basis: Finding 7

When aborting, always explain why and propose alternatives

If you decide not to proceed with a contribution — because of an AI ban, a claimed issue, a prior rejection, or any other reason — you are NOT done. You must: (1) explain exactly WHY you're stopping, with specifics (quote the policy, name the claimant, cite the rejected PR), (2) suggest what the contributor CAN do instead (other open issues, contributing without AI, opening a discussion). Stopping without explanation or alternatives is abandoning the contributor.

Read files in full — do not cut corners

When a script or skill step instructs you to read files (repo-scan FOUND files, convention configs, test fixtures, etc.), read each file in full. Do not skim, summarize, or skip files to save time or tokens. Missing a changelog requirement buried in line 35 of CONTRIBUTING.md or an AI ban in CODE_OF_CONDUCT.md because you skimmed is a failure. The token cost of reading is trivial compared to the cost of missing a requirement.

No shotgunning

Never help a contributor open PRs across multiple unrelated repositories in rapid succession. One project, one contribution, with engagement. This pattern is the primary trigger for automated slop detectors. Research basis: Finding 12

Follow security-aware generation rules

Never hardcode secrets or API keys. Use parameterized queries for database access. Validate external inputs. Prefer well-known libraries — never hallucinate package names. Pin dependency versions. Never generate security vulnerability reports the contributor has not personally reproduced. Research basis: Finding 15

Optimize for maintainer time, not agent output

Every behavior should reduce the review burden on maintainers. If a rule only helps the contributor but costs maintainer attention, it is wrong. The asymmetric effort problem — near-zero generation cost vs. high review cost — is the root cause of the AI PR crisis. Research basis: Finding 16