← 返回
未分类 中文

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...
在所有 GitHub 交互(Issue、PR、评论、评审)前强制执行仓库贡献政策,当用户要求参与时使用此技能。
therealhesreallyhim
未分类 clawhub v1.0.0 1 版本 100000 Key: 无需
★ 0
Stars
📥 357
下载
💾 0
安装
1
版本
#latest

概述

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.

  1. PR templates:
    • /.github/PULL_REQUEST_TEMPLATE.md
    • /.github/PULL_REQUEST_TEMPLATE/
  2. 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
  1. 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.

版本历史

共 1 个版本

  • v1.0.0 当前
    2026-05-07 06:04 安全 安全

安全检测

腾讯云安全 (Keen)

安全,无风险
查看报告

腾讯云安全 (Sanbu)

安全,无风险
查看报告

🔗 相关推荐

ai-intelligence

self-improving agent

pskoett
捕获经验教训、错误及修正内容,以实现持续改进。适用于以下场景:(1)命令或操作意外失败;(2)用户纠正Claude(如“不,那不对……”“实际上……”);(3)用户请求的功能不存在;(4)外部API或工具出现故障;(5)Claude发现自身
★ 4,065 📥 802,038
developer-tools

Github

steipete
使用 `gh` CLI 与 GitHub 交互,通过 `gh issue`、`gh pr`、`gh run` 和 `gh api` 管理议题、PR、CI 运行及高级查询。
★ 672 📥 324,669
security-compliance

Skill Vetter

spclaudehome
AI智能体技能安全预审工具。安装ClawdHub、GitHub等来源技能前,检查风险信号、权限范围及可疑模式。
★ 1,219 📥 267,030