GitHub Contributor

Enforces repository-defined contribution policy before any GitHub interaction (issues, PRs, comments, reviews). Use this skill when the user asks you to enga...

Security Scan

The skill's instructions are internally consistent with its stated purpose (enforcing repository contribution policy) and it requests no extra installs or credentials.

Purpose & Capability

The name/description say it will enforce repo contribution policies before GitHub interactions; the SKILL.md exclusively instructs the agent to locate and follow CONTRIBUTING/CODE_OF_CONDUCT/SECURITY files, check templates, search issues/PRs, and stop if requirements can't be met. There are no unrelated requirements (no extraneous env vars, binaries, or config paths).

Instruction Scope

Runtime instructions stay on-topic: identify repo context, read repository policy files, summarize policy, search existing threads, and enforce templates/pacing. The instructions do not request reading unrelated system files or exfiltrating data. They do assume the agent can access repository contents and GitHub metadata (owner/name, branches, issues/PRs).

Install Mechanism

This is an instruction-only skill with no install spec and no code files, so nothing is written to disk and there is no installer risk.

Credentials

The skill declares no required environment variables or credentials, which is appropriate for a policy-enforcement instruction set. Practically, performing the described actions (reading repo files, searching issues/PRs, creating comments/PRs) requires GitHub access provided by the agent/platform (e.g., a GITHUB_TOKEN). The skill does not request or assume any specific token scope—users should ensure the agent's GitHub credentials are appropriately scoped before allowing interactions.

Persistence & Privilege

always:false and no install or persistent configuration changes are requested. The skill does not ask to modify other skills or system-wide settings.

Assessment

This skill appears coherent and low-risk: it only tells the agent how to behave around GitHub interactions and doesn't request secrets or install software. Before enabling it, confirm that your agent/platform already has the right GitHub access (and that that token's scope is limited to what you want). If you expect the agent to act autonomously on your behalf, review the platform's GitHub credential use and consider limiting write permissions so the agent can read repo content and issues but cannot perform destructive actions without your explicit consent.

GitHub Contributor Protocol

This skill governs all outward interactions on GitHub.

All behavior must align with the repository’s published policies (e.g., CONTRIBUTING.md, CODE_OF_CONDUCT.md, templates, SECURITY.md). This is a hard requirement imposed by GitHub itself and not merely a best practice. If repository policy cannot be located, interpreted, or satisfied, DO NOT proceed.

---

1. Mandatory Pre-Interaction Protocol

Before creating or commenting on:

• Issues
• Pull Requests
• Discussions
• Reviews

You MUST complete all steps below.

---

A. Identify Repository Context

Determine:

• owner/name
• default branch
• fork vs upstream
• write permissions
• whether contribution requires prior issue/discussion

If context cannot be established → STOP.

---

B. Locate and Read Repository Policies

Locate core contributing docs:

1. CONTRIBUTING.md
2. CODE_OF_CONDUCT.md
3. SECURITY.md

Search for them in these directories, in order:

1. / - i.e., root
2. /.github
3. /docs

Not all repositories contain these documents.

4. PR templates:
   • /.github/PULL_REQUEST_TEMPLATE.md
   • /.github/PULL_REQUEST_TEMPLATE/
5. Issue templates:
   • /.github/ISSUE_TEMPLATE/

Read all relevant files fully.

---

C. Produce an Internal Policy Summary

Before proceeding, internally summarize all explicitly defined repository policies:

• Required workflow (issue-first? discussion-first?)
• Branching model expectations (e.g. naming conventions)
• Testing / lint / formatting requirements (for PRs)
• Commit message conventions (for PRs)
• Explicit restrictions (e.g., no unsolicited refactors, no automated submissions)
• Required PR or issue structure

If this summary cannot be produced → STOP.

---

D. Search for Existing Work

Before opening a new issue or PR:

1. Search open and closed:

   • Issues
   • PRs
   • Discussions

2. If a related thread exists:

   • Contribute there instead of creating a duplicate.
   • Do not fragment discussion.

If adequate search cannot be performed → STOP.

---

2. Template & Information Enforcement

Checklist Compliance

If an issue or PR template includes required checkboxes:

• Perform each required action before marking it complete.
• Do not mark items unless actually satisfied.
• Do not remove required checklist items.

If any required action cannot be completed → STOP.

---

Required Information Compliance

If a template requires specific information (e.g., OS, version, reproduction steps, logs, environment):

• Provide all required fields.
• Ensure reproduction steps are concrete and testable.
• Do not leave required sections blank.

If required information cannot be supplied → STOP.

---

3. Scope & Change Discipline

• One purpose per PR.
• No unrelated formatting or refactors.
• No drive-by changes.
• Follow repository formatting and style rules.
• Update documentation or changelog if required.

If required quality gates (tests/lint/build) cannot be verified → STOP.

---

4. Relaxed Interaction Pacing

When performing multiple outward actions (e.g., several comments or issues):

• Wait at least 5 minutes between interactions.
• Avoid burst behavior.
• Default to slower pacing if uncertainty exists.

Do not generate high-frequency comment sequences.

Bursty activity is:

(a) highly indicative of automation;

(b) may violate GitHub's rate limit policies. These violations can result in severe penalties for the user.

---

5. Respect Repository Authority

If maintainers:

• Close an issue or PR,
• Reject a proposal,
• Request changes,
• Request no further automated interaction,

Then:

• Comply immediately.
• Do not escalate.
• Do not repost the same content.
• Do not bypass stated policy.

---

6. Stop Conditions

Do NOT proceed if:

• Policies are missing or ambiguous.
• Security-sensitive code is involved.
• Explicit anti-bot/automation policy exists.
• Required checks/tests cannot be run.
• Required template information cannot be provided.

When uncertain, choose the action that minimizes disruption.

---

7. Policy Basis & Consequences

This protocol is grounded in repository-defined contribution policies and GitHub platform rules. If you are able to satisfy these requirements, you may produce high-quality contributions and your contributions will be welcome.

Failure to follow repository policies may result in:

• Immediate closure of issues or PRs
• Maintainer refusal to review
• Loss of trust
• Account moderation or rate limiting
• Organization-level blocking
• Reputational damage

This skill exists to ensure compliance with repository governance and to prevent disruptive or low-quality interaction that could have undesirable repercussions. You may be acting on behalf of a user who cares a lot about their project, so do not put that at risk by disregarding GitHub community standards. If the user is not aware of these standards, notify them of this risk before taking any action.