What file is generated and where?

A .shellcheckrc INI-style file generated for the project root (or a specified path) that ShellCheck reads for configuration.

Can I disable specific warnings?

Yes. Use disable lines to suppress individual SC codes; you can also enable specific checks as needed.

How do I collaborate across teams?

Document decisions in the config and maintain consistency by reusing the same template across repositories.

shellcheck-config-generator

Scanned

npx machina-cli add skill a5c-ai/babysitter/shellcheck-config-generator --openclaw

Files (1)

SKILL.md

2.2 KB

ShellCheck Config Generator

Generate ShellCheck configuration for shell script linting.

Capabilities

Generate .shellcheckrc files
Configure rule exclusions
Set shell dialect
Configure severity levels
Document rule decisions
Create project-specific configs

Usage

Invoke this skill when you need to:

Set up ShellCheck for a project
Configure linting rules
Exclude specific warnings
Document rule decisions

Generated Configuration

# .shellcheckrc - ShellCheck configuration
# https://www.shellcheck.net/wiki/

# Default shell dialect (sh, bash, dash, ksh)
shell=bash

# Source path for sourced files
source-path=SCRIPTDIR
source-path=lib/

# External sources (follow source commands)
external-sources=true

# Severity level: error, warning, info, style
severity=warning

# Disable specific warnings

# SC1090: Can't follow non-constant source
disable=SC1090

# SC1091: Not following (sourced file not found)
disable=SC1091

# SC2034: Variable appears unused (often used in sourced scripts)
# disable=SC2034

# SC2086: Double quote to prevent globbing (sometimes intentional)
# disable=SC2086

# SC2155: Declare and assign separately
# disable=SC2155

# Enable optional checks

# Check for unquoted variables that could be empty
enable=check-unassigned-uppercase

# Check for extra masking of return values
enable=check-extra-masked-returns

Rule Categories

Critical (Never Disable)

SC2094: File read and written in same pipeline
SC2095: Add < /dev/null to prevent ssh from eating stdin
SC2096: Script requires shebang
SC2148: Missing shebang

Important (Disable Carefully)

SC2086: Double quote to prevent globbing
SC2046: Quote to prevent word splitting
SC2035: Use ./* to avoid globbing issues
SC2012: Use find instead of ls

Style (Project Decision)

SC2034: Variable appears unused
SC2155: Declare and assign separately
SC2164: Use cd ... || exit

Target Processes

shell-script-development
cli-unit-integration-testing
cross-platform-cli-compatibility

Source

git clone https://github.com/a5c-ai/babysitter/blob/main/plugins/babysitter/skills/babysit/process/specializations/cli-mcp-development/skills/shellcheck-config-generator/SKILL.md

View on GitHub

Overview

This skill generates a tailored .shellcheckrc configuration for shell script linting. It lets you set the shell dialect, source paths, and whether to follow external sources, plus per-rule enable/disable and severity levels. It also supports documenting rule decisions and creating project-specific configurations for consistent linting across a codebase.

How This Skill Works

The skill collects project inputs such as dialect, source paths, external sources and desired severity, then outputs an INI-style .shellcheckrc. It populates keys like shell, source-path, external-sources, severity, and lists of disable and enable entries, along with comments documenting decisions. The result is a reproducible, project-specific config that ShellCheck can apply automatically.

When to Use It

Starting a new project and want a sensible lint baseline with a consistent ShellCheck setup.
Enforcing project-wide linting by aligning all scripts to the same dialect and severity.
Excluding noisy or false-positive warnings for legacy scripts.
Documenting why certain rules are enabled or disabled for compliance.
Creating per-project configs as part of CI to ensure reproducible checks.

Quick Start

Step 1: Run the skill to generate a .shellcheckrc for your repository.
Step 2: Review and adjust the shell dialect, source-paths, external-sources, and severity as needed.
Step 3: Commit the generated .shellcheckrc to the project root and run ShellCheck in CI.

Best Practices

Define the project dialect up front (bash, sh, dash, etc.) and keep it consistent.
Set a baseline severity (e.g., warning) and adjust for critical issues as needed.
Use disable sparingly and document decisions within the config.
Keep source-paths accurate and reflect where sourced files live (SCRIPTDIR, lib/, etc.).
Regularly review rule categories and update the config as scripts evolve.

Example Use Cases

Example 1: shell=bash, source-path=SCRIPTDIR, source-path=lib/, external-sources=true, severity=warning.
Example 2: Disable SC1090 and SC1091 to accommodate legacy sourcing patterns.
Example 3: Enable unassigned-uppercase and check-extra-masked-returns for stricter checks.
Example 4: Set severity to error for critical checks in CI while keeping others as warnings.
Example 5: Include multiple folder layouts with relative source paths to reflect project structure.

Frequently Asked Questions

Add this skill to your agents