Skill flagged — suspicious patterns detected

ClawHub Security flagged this skill as suspicious. Review the scan results before using.

repo-setup

v1.0.0

Fork, clone, and set up a GitHub repository for development or contribution. Handles fork creation, clone with authentication, upstream remote configuration,...

0· 109·0 current·0 all-time
byBijin@sliverp

Install

OpenClaw Prompt Flow

Install with OpenClaw

Best for remote or guided setup. Copy the exact prompt, then paste it into OpenClaw for sliverp/repo-setup.

Previewing Install & Setup.
Prompt PreviewInstall & Setup
Install the skill "repo-setup" (sliverp/repo-setup) from ClawHub.
Skill page: https://clawhub.ai/sliverp/repo-setup
Keep the work scoped to this skill only.
After install, inspect the skill metadata and help me finish setup.
Use only the metadata you can verify from ClawHub; do not invent missing requirements.
Ask before making any broader environment changes.

Command Line

CLI Commands

Use the direct CLI path if you want to install manually and keep every step visible.

OpenClaw CLI

Bare skill slug

openclaw skills install repo-setup

ClawHub CLI

Package manager switcher

npx clawhub@latest install repo-setup
Security Scan
VirusTotalVirusTotal
Suspicious
View report →
OpenClawOpenClaw
Suspicious
high confidence
!
Purpose & Capability
The SKILL.md clearly expects git and the GitHub CLI (gh), a GH_TOKEN or gh auth login, and language-specific toolchains (pip, npm, go, cargo, mvn, gradle). The skill metadata lists no required binaries or environment variables. This mismatch is unexpected — a repo-setup helper legitimately needs git and some auth mechanism declared in metadata.
!
Instruction Scope
Instructions stay within the repo-setup use case, but they also tell the agent/user to: request or rely on GH_TOKEN, run broad dependency installs (npm/pip/mvn/gradle) which execute third-party code, and include a token directly in an HTTPS clone URL. Embedding a token in the clone URL can leave the token in shell history, process listings, and repository config (remote URL), increasing the risk of accidental credential exposure. The doc also references an external helper script (oss-pr-campaign / scripts/setup_repo.sh) that is not provided or installed by this skill.
Install Mechanism
This is instruction-only with no install spec or code files, which is lower risk because nothing is written automatically. However, the README references an external helper script available only when paired with another (oss-pr-campaign) — that coupling is undocumented in the metadata and could confuse users.
!
Credentials
The instructions require a GH_TOKEN and GitHub username, but the skill declares no required env vars or primary credential. Asking for a GH token is reasonable for pushing/forking, but the skill does not document required token scopes or warn about safer alternatives (SSH or gh auth login). Also, the broad set of build toolchains suggested increases the surface area: running install commands will execute arbitrary third-party code (npm/pip/maven lifecycle scripts).
Persistence & Privilege
The skill is not always:true, has no install hook, and does not request persistent privileges or modify other skills. Autonomous invocation is allowed (platform default) but not combined with other strong privilege requests here.
What to consider before installing
Before installing or running this skill: 1) Treat the metadata mismatch as a red flag — ask the publisher to update required binaries (git, gh) and required env vars (GH_TOKEN) so you know what will be used. 2) Avoid cloning with a token embedded in the HTTPS URL; prefer gh auth login or SSH keys, and if you must use a token, use ephemeral/minimal-scoped tokens and remove them from remote URLs afterwards (git remote set-url). 3) Be cautious running dependency installs (npm, pip, mvn, gradle) from unknown repositories — these can execute arbitrary code (postinstall/build scripts). Consider running the setup in an isolated container or VM. 4) Verify existence and contents of any referenced helper scripts (scripts/setup_repo.sh, oss-pr-campaign) before executing them. 5) Limit GH_TOKEN scopes to the minimum required (fork/push), rotate tokens after use, and never paste tokens into chat or public logs. If the publisher cannot justify the missing metadata and the token-in-URL pattern is not removed or explained, treat the skill as untrusted.

Like a lobster shell, security has layers — review code before you run it.

latestvk97bqhezwhgdg5ck1h7fbx9gqd83hgmt
109downloads
0stars
1versions
Updated 1mo ago
v1.0.0
MIT-0

Repo Setup — Fork, Clone & Branch Setup

Overview

Automate the setup of a local development environment for contributing to or working on GitHub repositories. Handles the full fork → clone → branch → dependencies pipeline.

Use cases: Open-source contribution, multi-repo development, new project onboarding, codebase exploration.

Prerequisites

gh auth status   # Must show "Logged in"
git --version    # Git installed

If not configured, ask the user to provide:

  1. GitHub username — used for fork URLs and clone paths
  2. GitHub token — run gh auth login or set export GH_TOKEN=<token>

Token is required for: forking repos, cloning private forks, pushing code. Without it, git push and gh repo fork will fail.

Workflow

Step 1: Get Parameters

ParameterRequiredDefaultExample
Repositoryowner/repo
GitHub usernamemyusername
Branch name(stay on default)fix/bug-description
Working directory~/prs/{repo}~/dev/{repo}
Auth methodGH_TOKEN env varToken in URL, SSH

Step 2: Fork

gh repo fork {owner}/{repo} --clone=false

If fork already exists, this is a no-op. If the user already owns the repo, skip forking.

Step 3: Clone

WORKDIR="${WORK_BASE:-$HOME/prs}/{repo_name}"

if [ -d "$WORKDIR" ]; then
    cd "$WORKDIR"
    git fetch --all
else
    mkdir -p "$(dirname "$WORKDIR")"

    # With token auth
    git clone "https://${GH_TOKEN}@github.com/${username}/${repo_name}.git" "$WORKDIR"

    # Or with SSH
    # git clone "git@github.com:${username}/${repo_name}.git" "$WORKDIR"

    cd "$WORKDIR"
fi

Step 4: Configure Upstream Remote

if ! git remote get-url upstream &>/dev/null; then
    git remote add upstream "https://github.com/${owner}/${repo_name}.git"
fi
git fetch upstream

Step 5: Create Feature Branch

# Detect default branch
DEFAULT_BRANCH=$(git remote show upstream 2>/dev/null | grep 'HEAD branch' | awk '{print $NF}')
DEFAULT_BRANCH="${DEFAULT_BRANCH:-main}"

# Create branch from latest upstream
git checkout -b {branch_name} upstream/$DEFAULT_BRANCH

Branch Naming Conventions

TypePatternExample
Bug fixfix/{short-description}fix/null-pointer-on-empty-list
Featurefeat/{short-description}feat/add-retry-logic
Refactorrefactor/{short-description}refactor/extract-auth-module
Review iterationfix/{description}-v2fix/tool-guards-v2

Step 6: Install Dependencies

Detect the project type and install accordingly:

IndicatorLanguageInstall Command
pyproject.toml / setup.pyPythonpip install -e ".[dev]" or pip install -e .
requirements.txtPythonpip install -r requirements.txt
package.jsonNode.jsnpm install
go.modGogo mod download
Cargo.tomlRustcargo build
pom.xmlJavamvn install -DskipTests
build.gradleJava/Kotlin./gradlew build -x test

If full dev install fails (common with native dependencies):

  1. Install core deps individually
  2. Skip optional native/GPU deps
  3. Ensure test framework is installed at minimum

Step 7: Verify

# Check setup
echo "Directory: $(pwd)"
echo "Branch: $(git branch --show-current)"
echo "Upstream: $(git remote get-url upstream)"
echo "Fork: $(git remote get-url origin)"

# Quick build/import test
# Python: python -c "import {package}"
# Node: npm run build (if applicable)
# Go: go build ./...

Automation Script

A helper script is available if this Skill is installed alongside oss-pr-campaign:

# One-liner setup
scripts/setup_repo.sh owner/repo username fix/branch-name

Or implement the same logic step-by-step using the SOP above.

Output

  • Local repo at ~/prs/{repo}/ (or custom directory) on feature branch
  • Upstream remote configured
  • Dependencies installed
  • Ready for development

Tips

  • When used as part of a development pipeline, this follows issue-hunter and feeds into dev-test.
  • For exploring a codebase without contributing, skip the fork step and clone the original directly.
  • Store GH_TOKEN in your shell profile for persistent auth across sessions.
  • If working on multiple repos, keep them all under ~/prs/ for easy navigation.

Comments

Loading comments...