Open Source Contributor

Autonomously scouts GitHub for beginner issues, writes fixes by complexity, tests, and submits PRs while enforcing safety and approval thresholds.

Security Scan

The skill's declared metadata, runtime instructions, and shipped scripts are not fully consistent: it legitimately needs a GitHub token and will send repo data to an external cloud model, but the registry metadata omits the required credential and the install/setup behavior persists tokens to disk contrary to some guidance — review before installing and give only a dedicated, limited token if you proceed.

Purpose & Capability

The skill's stated purpose (autonomously finding issues, writing fixes, running tests, and opening PRs) matches the included scripts and README. However the registry-level metadata claimed no required env vars/credentials while install.json, README, SKILL.md, and setup.py all expect a GITHUB_TOKEN. That metadata mismatch is an incoherence that could mislead users about what secrets the skill needs.

Instruction Scope

SKILL.md and the scripts clearly instruct the agent to read/cloned repositories, run tests, and use a cloud model (qwen3-coder-next:cloud) to generate code. That behavior is consistent with the described purpose, but it means repository source (and potentially secrets present in repos) may be sent to an external model—this is significant data exposure and should be explicit. The code also promises full PR submission under the user's identity, but the Submitter is only described as a task (no concrete API calls implemented), so implementation is incomplete/ambiguous.

Install Mechanism

There is no remote download of third-party binaries; the package is instruction/script-based and shippped locally. install.json declares a postInstall that runs scripts/setup.py, which is interactive and will persist configuration. Running setup.py at install-time (postInstall) may prompt and store sensitive data unexpectedly; this is a moderate-installer risk but not a remote code-download risk.

Credentials

Requesting a GitHub personal access token (public_repo scope) is appropriate for opening PRs, so the credential itself is proportionate. But the registry metadata incorrectly lists no required env vars. Additionally, setup.py writes the token into ~/.openclaw/workspace/contrib-scout/config.json (plain text), contradicting the README's admonition to 'store token in environment variable' — persisting the token to disk increases risk if the machine is shared or compromised. The skill will also send repository contents to a cloud model (qwen3-coder-next:cloud), which is functionally related to the purpose but a significant data-leak/privacy consideration that should be explicit and under user control.

Persistence & Privilege

The skill does not request always:true and does not modify other skills. It does persist configuration, logs, and cloned repos under ~/.openclaw/workspace/contrib-scout/, which is expected for this functionality. The postInstall running setup.py is potentially surprising (interactive token entry and config write) and could be considered intrusive if not made clear at install time.

What to consider before installing

Key things to consider before installing: - Source and provenance: the skill's repository and owner are not a known, trusted maintainer. Review the code yourself (especially setup.py and any code that would actually push PRs) before running any install steps. - Credentials: this skill needs a GitHub Personal Access Token (the code expects GITHUB_TOKEN / setup input). Use a dedicated token with only public_repo scope and rotate it after testing. Do NOT reuse a personal token that has broader scopes. - Token storage: setup.py will save the token into ~/.openclaw/workspace/contrib-scout/config.json in plain text. If you prefer not to persist the token, skip running setup.py interactive steps and set GITHUB_TOKEN as an environment variable for the session or modify the code to avoid writing the token to disk. - Data exposure: the Coder subagent is configured to use qwen3-coder-next:cloud. That means repository files and issue text will be sent to an external cloud model. If repositories contain sensitive data (even in history), do not use the cloud coder — either run in human-review mode only or modify the pipeline to use a local model. - Autonomy: start in the 'Approval-First' or manual mode. Do initial dry runs and review the first several drafted PRs before enabling auto-submit. The safety docs recommend this; follow it. - Implementation gaps: the pipeline prepares tasks and subagent calls but the Submitter steps are not fully implemented (no concrete GitHub API calls present). Expect you may need to add or inspect the code that actually opens PRs to confirm it behaves as you want. Actions to reduce risk: - Run the pipeline locally in dry-run/manual mode and inspect all generated drafts and logs before any network operations. - Use a throwaway or secondary GitHub account/token for initial testing so any accidental commits won't affect your main account. - Inspect/modify the code to avoid persisting tokens and to avoid sending repo contents to external models if that is a concern. If the author updates the registry metadata to declare the GITHUB_TOKEN requirement, documents where and how repo data is sent to external services, and either implements PR submission with explicit safe handling or offers a local-model option, my confidence in this being coherent/safe would increase.

Autonomous GitHub contribution agent with graduated complexity levels.

Description

Scouts small open-source projects for contribution opportunities, analyzes issues, writes fixes using qwen3-coder-next:cloud, and submits PRs under your identity.

When to Use

✅ USE when:

• You want to contribute to open source during quiet hours
• You want AI-assisted coding with graduated complexity
• You want to build contribution history gradually

❌ DON'T use when:

• Repository involves security/auth/cryptography
• Issue scope is unclear or ambiguous
• You've hit rejection rate threshold (>30%)

Configuration

{
  "github_token": "ghp_xxxxxxxxxxxx",
  "max_repos_per_night": 3,
  "complexity_level": 1,
  "approval_threshold": 0.5,
  "quiet_hours": {"start": "23:00", "end": "07:00"},
  "blocked_patterns": ["auth", "crypto", "token", "key", "password", "credential"]
}

Complexity Levels

Level	Scope	Max Repos	Approval Rate Required
1	Typo/link fixes	3	None
2	README/doc fixes	3	>50%
3	Simple code fixes	2	>70%
4	Moderate code fixes	1	>90%

Pipeline

1. Scout → Find candidates with good first issue label
2. Analyzer → Scope understanding + complexity assessment
3. Coder (qwen3-coder-next:cloud) → Write fix
4. Tester → Run test suite
5. Reviewer → Pre-flight checklist
6. Submitter → Open PR

Usage

# Manual run
python3 ~/.openclaw/skills/open-source-contributor/scripts/contrib-pipeline.py

# Check status
cat ~/.openclaw/workspace/contrib-scout/logs/contributions.jsonl | tail -20

Safety

• Append-only audit logging
• Auto-pause if rejection rate >30%
• Blocked file patterns enforced
• AI disclosure in every PR
• Test suite must pass

Storage

~/.openclaw/workspace/contrib-scout/
├── repos/              # Cloned repositories
├── drafts/             # Pending contributions
├── logs/               # Activity + audit trail
├── config.json         # User settings
└── approval-tracking.json  # PR outcomes