agentsclimarketplace

Rig

Skill slamb2k/mad-skills/skills/rig

Idempotently bootstrap any repository with standard development tools, hooks, and workflows. Use when starting work on a new repo, onboarding to an existing project, or ensuring a repo has proper CI/CD setup. Configures: git hooks (lefthook) including a secret-scan pre-commit check for accidentally staged credentials/API keys, commit message templates, PR templates, and GitHub Actions for lint/format/type-check/build. Prompts for user confirmation before changes. Triggers: "bootstrap repo", "setup hooks", "configure CI", "rig", "standardize repo", "scan for secrets", "prevent committing credentials".From its SKILL.md

Install
npx -y skills add slamb2k/mad-skills --skill rig

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 5 stars5 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

13.0 KB, as published. Nobody here has run it

Rig - Repository Bootstrap

When this skill is invoked, IMMEDIATELY output the banner below before doing anything else. Pick ONE tagline at random β€” vary your choice each time. CRITICAL: Reproduce the banner EXACTLY character-for-character, including the diagonal / glyph before the name.

{tagline}

       /$$ /$$$$$$$  /$$$$$$  /$$$$$$ 
      /$$/| $$__  $$|_  $$_/ /$$__  $$
     /$$/ | $$  \ $$  | $$  | $$  \__/
    /$$/  | $$$$$$$/  | $$  | $$ /$$$$
   /$$/   | $$__  $$  | $$  | $$|_  $$
  /$$/    | $$  \ $$  | $$  | $$  \ $$
 /$$/     | $$  | $$ /$$$$$$|  $$$$$$/
|__/      |__/  |__/|______/ \______/ 

Taglines:

  • πŸ—οΈ Rigging up the production line...
  • πŸ”© Bolting down the framework!
  • πŸͺœ Assembling the scaffolding!
  • πŸ—οΈ Hoisting the infrastructure!
  • 🦺 Locking in the safety harness!
  • ⚑ Wiring up the control panel!
  • πŸ› οΈ Setting up the drill floor!
  • πŸ“ From blueprint to build-ready!

Output Formatting

After the banner, display parsed input:

β”Œβ”€ Input ────────────────────────────────────────
β”‚  {Field}:  {value}
β”‚  Flags:    {parsed flags or "none"}
└────────────────────────────────────────────────

Pre-flight results:

── Pre-flight ───────────────────────────────────
  βœ… {dep}           {version or "found"}
  ⚠️ {dep}           not found β†’ {fallback detail}
  ❌ {dep}           missing β†’ stopping
──────────────────────────────────────────────────

Stage/phase headers: ━━ {N} Β· {Name} ━━━━━━━━━━━━━━━━━━━━━━━━━

Status icons: βœ… done Β· ❌ failed Β· ⚠️ degraded Β· ⏳ working Β· ⏭️ skipped


Idempotently bootstrap repositories with standard development infrastructure. Prompts and report schemas are in references/. Configuration procedures are in references/configuration-steps.md.

Key principle: Prompt user before making changes. Report findings first, get approval, then act.


Platform Detection

Detect the hosting platform before pre-flight so dependency checks are platform-specific:

REMOTE_URL=$(git remote get-url origin 2>/dev/null)
if echo "$REMOTE_URL" | grep -qiE 'dev\.azure\.com|visualstudio\.com'; then
  PLATFORM="azdo"
elif echo "$REMOTE_URL" | grep -qi 'github\.com'; then
  PLATFORM="github"
else
  PLATFORM="github"   # default fallback
fi

Pass {PLATFORM} into all phase prompts. Each phase uses the appropriate CLI tool: gh for GitHub, az repos/az pipelines for Azure DevOps.


Pre-flight

Before starting, check all dependencies in this table. The table contains all dependencies β€” some are platform-conditional (see notes after table).

DependencyTypeCheckRequiredResolutionDetail
gitcligit --versionyesstopInstall from https://git-scm.com
syncskillls .claude/skills/sync/SKILL.md ~/.claude/skills/sync/SKILL.md ~/.claude/plugins/marketplaces/slamb2k/skills/sync/SKILL.md 2>/dev/nullnofallbackRepo sync; falls back to manual git pull
lefthooknpmnpx lefthook --helpyesasknpm install -g lefthook
ghcligh --versionyesurlhttps://cli.github.com
az devopscliaz devops -h 2>/dev/nullnofallbackFalls back to REST API with PAT; see AzDO tooling below

Platform-conditional rules:

  • gh: Only required when PLATFORM == github. Skip for AzDO repos.
  • az devops: Only checked when PLATFORM == azdo. Skip for GitHub repos.

For each applicable row, in order:

  1. Skip rows that don't apply to the detected {PLATFORM}
  2. Run the Check command (for cli/npm) or test file existence (for agent/skill)
  3. If found: continue silently
  4. If missing: apply Resolution strategy
    • stop: notify user with Detail, halt execution
    • url: notify user with Detail (install link), halt execution
    • install: notify user, run the command in Detail, continue if successful
    • ask: notify user, offer to run command in Detail, continue either way (or halt if required)
    • fallback: notify user with Detail, continue with degraded behavior
  5. After all checks: summarize what's available and what's degraded

AzDO Tooling Detection

When PLATFORM == azdo, determine which tooling is available. Set AZDO_MODE for use in all subsequent phases:

if az devops -h &>/dev/null; then
  AZDO_MODE="cli"
else
  AZDO_MODE="rest"
fi
  • cli: Use az repos / az pipelines commands (preferred)
  • rest: Use Azure DevOps REST API via curl. Requires a PAT (personal access token) in AZURE_DEVOPS_EXT_PAT or AZDO_PAT env var. If no PAT is found, prompt the user to either install the CLI or set the env var.

Report in pre-flight:

  • βœ… az devops cli β€” version found
  • ⚠️ az devops cli β€” not found β†’ using REST API fallback
  • ❌ az devops cli β€” not found, no PAT configured β†’ halt with setup instructions

AzDO Configuration Validation

When PLATFORM == azdo, extract organization and project from the remote URL and validate they are usable. These values are needed by every az repos / az pipelines command and every REST API call.

# Extract org and project from remote URL patterns:
#   https://dev.azure.com/{ORG}/{PROJECT}/_git/{REPO}
#   https://{ORG}@dev.azure.com/{ORG}/{PROJECT}/_git/{REPO}
#   {ORG}@vs-ssh.visualstudio.com:v3/{ORG}/{PROJECT}/{REPO}

REMOTE_URL=$(git remote get-url origin 2>/dev/null)

if echo "$REMOTE_URL" | grep -q 'dev\.azure\.com'; then
  AZDO_ORG=$(echo "$REMOTE_URL" | sed -n 's|.*dev\.azure\.com/\([^/]*\)/.*|\1|p')
  AZDO_PROJECT=$(echo "$REMOTE_URL" | sed -n 's|.*dev\.azure\.com/[^/]*/\([^/]*\)/.*|\1|p')
  AZDO_ORG_URL="https://dev.azure.com/$AZDO_ORG"
elif echo "$REMOTE_URL" | grep -q 'vs-ssh\.visualstudio\.com'; then
  AZDO_ORG=$(echo "$REMOTE_URL" | sed -n 's|.*vs-ssh\.visualstudio\.com:v3/\([^/]*\)/.*|\1|p')
  AZDO_PROJECT=$(echo "$REMOTE_URL" | sed -n 's|.*vs-ssh\.visualstudio\.com:v3/[^/]*/\([^/]*\)/.*|\1|p')
  AZDO_ORG_URL="https://dev.azure.com/$AZDO_ORG"
elif echo "$REMOTE_URL" | grep -q 'visualstudio\.com'; then
  AZDO_ORG=$(echo "$REMOTE_URL" | sed -n 's|.*//\([^.]*\)\.visualstudio\.com.*|\1|p')
  AZDO_PROJECT=$(echo "$REMOTE_URL" | sed -n 's|.*/\([^/]*\)/_git/.*|\1|p')
  AZDO_ORG_URL="https://${AZDO_ORG}.visualstudio.com"
fi

# URL-decode for CLI/display; keep URL-safe versions for REST API paths
AZDO_PROJECT_URL_SAFE="$AZDO_PROJECT"
AZDO_ORG=$(python3 -c "import urllib.parse; print(urllib.parse.unquote('$AZDO_ORG'))")
AZDO_PROJECT=$(python3 -c "import urllib.parse; print(urllib.parse.unquote('$AZDO_PROJECT_URL_SAFE'))")

if [ -z "$AZDO_ORG" ] || [ -z "$AZDO_PROJECT" ]; then
  echo "❌ Could not extract organization/project from remote URL"
  echo "   Remote: $REMOTE_URL"
  echo ""
  echo "Ensure the remote URL follows one of these formats:"
  echo "  https://dev.azure.com/{ORG}/{PROJECT}/_git/{REPO}"
  echo "  https://{ORG}.visualstudio.com/{PROJECT}/_git/{REPO}"
  echo "  {ORG}@vs-ssh.visualstudio.com:v3/{ORG}/{PROJECT}/{REPO}"
  # HALT β€” cannot proceed without org/project context
fi

When AZDO_MODE == cli, also configure the defaults so commands work correctly:

az devops configure --defaults organization="$AZDO_ORG_URL" project="$AZDO_PROJECT"

When AZDO_MODE == rest, store these for API calls:

  • Base URL: $AZDO_ORG_URL/$AZDO_PROJECT_URL_SAFE/_apis
  • Auth header: Authorization: Basic $(printf ":%s" "$PAT" | base64 | tr -d '\n')

Report in pre-flight:

  • βœ… azdo context β€” org: {AZDO_ORG}, project: {AZDO_PROJECT}
  • ❌ azdo context β€” could not parse from remote URL β†’ halt with instructions

Pass {AZDO_MODE}, {AZDO_ORG}, {AZDO_PROJECT}, {AZDO_ORG_URL} into all phase prompts alongside {PLATFORM}.


Phase 0: Sync

Invoke /sync to ensure the working tree is up to date with origin/main before bootstrapping. If /sync is unavailable, run git pull manually. This prevents rigging against stale repo state.


Phase 1: System Requirements Check

Launch general-purpose subagent (bash) (haiku β€” simple checks):

Task(
  subagent_type: "general-purpose",
  model: "haiku",
  description: "Check system requirements",
  prompt: <read from references/phase-prompts.md#phase-1>
)

Parse SYSTEM_REPORT. If any requirement fails, use AskUserQuestion:

Options for missing git config:

  • "I'll configure it manually"
  • "Configure for me with: [email] / [name]"

Stop if user chooses manual. Configure if values provided.


Phase 2: Repository Analysis

Launch general-purpose subagent (bash) (haiku):

Task(
  subagent_type: "general-purpose",
  model: "haiku",
  description: "Analyze repository",
  prompt: <read from references/phase-prompts.md#phase-2>
)

Parse REPO_REPORT.


Phase 3: Present Findings & Get Approval

Present analysis to user with AskUserQuestion:

Repository Analysis Complete

Current State:
  Git initialized: {status}
  Branch: {branch}
  Lefthook: {status}
  Commit template: {status}
  PR template: {status}
  CI workflow: {status}
  {if azdo and unregistered_pipelines:}
  Azure Pipelines: {N} YAML file(s) found, {M} not yet registered

Detected Stack:
  Type: {project_type}
  Components: {detected_components}
  Available scripts: {available_scripts}

Proposed Changes:
  {numbered list of what will be added/configured}
  {if azdo and unregistered_pipelines: "Register Azure Pipelines: {list of YAML paths}"}

Options:

  • "Yes, configure everything"
  • "Let me choose what to configure"
  • "Cancel"

If "Let me choose", present individual options as multi-select.


Phase 4: Execute Configuration

For each approved item, follow the procedures in references/configuration-steps.md.

Branch Discipline in CLAUDE.md

If the project has an existing CLAUDE.md:

  1. Check if ## Branch Discipline already exists:
    grep -q "## Branch Discipline" CLAUDE.md
    
  2. If NOT found, inject the Branch Discipline section before ## Guardrails:
    • Read the file content
    • Find the line containing ## Guardrails
    • Insert the Branch Discipline section immediately before it
    • If no ## Guardrails section exists, append at the end of the file
  3. If already present, skip (idempotent)

The Branch Discipline content to inject is the ## Branch Discipline section from skills/brace/references/claude-md-template.md. Read that file to get the exact content β€” this avoids duplication and ensures both /brace and /rig inject identical text.


Phase 5: Verification

Launch general-purpose subagent (bash) (haiku):

Task(
  subagent_type: "general-purpose",
  model: "haiku",
  description: "Verify configuration",
  prompt: <read from references/phase-prompts.md#phase-5>
)

Parse VERIFY_REPORT.


Phase 6: Final Report

Present summary using the template in references/report-template.md.

After presenting the report, record lifecycle completion and surface the next step:

_R="${CLAUDE_PLUGIN_ROOT:-$HOME/.claude/plugins/marketplaces/slamb2k}"
node "$_R/hooks/session-guard.cjs" lifecycle-complete rig

If the command prints a LIFECYCLE_OFFER_BEGIN…END block, present that offer to the user via AskUserQuestion as instructed inside the block. If it prints nothing (or LIFECYCLE_OFFER_NONE), do not mention the lifecycle engine.


Idempotency Rules

  • Skip items already correctly configured
  • Update items that exist but are outdated (prompt user first)
  • Add items that are missing
  • Never delete user's existing configuration without explicit approval
  • Merge rather than replace when possible (e.g., add missing hooks)

Error Handling

If any step fails:

  1. Report the specific failure
  2. Offer to skip and continue, or abort
  3. Include troubleshooting suggestions

Common issues:

  • No package manager -> suggest installing npm/bun
  • Permission denied -> check file permissions
  • Lefthook install fails -> try global install
  • Git not initialized -> offer to initialize

Keep looking

Skills are one crate of 627,801. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.