agentleFS
rundopsrundops/dops/.claude/skills/create-runbook/SKILL.md

create-runbook

Skill3 starsChanged 8 months agoMITView on GitHub

Create a new dops runbook with correct YAML schema and POSIX shell script. Use when the user asks to create a new automation, runbook, or script for dops. Triggers on: 'create a runbook', 'add automation', 'new script', 'scaffold runbook'.

3 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

6 rules. About 0 are common, 0 are distinctive, and 6 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈0

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 6

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Use $(command): not backticks

    line 107
  2. Very specific:

    Create the directory: mkdir -p ~/.dops/catalogs/<catalog>/<name>

    line 140
  3. Very specific:

    Write runbook.yaml with the schema above

    line 141
  4. Very specific:

    Write script.sh following the POSIX template

    line 142
  5. Very specific:

    If the catalog is new, register it: dops catalog add ~/.dops/catalogs/<catalog>

    line 144
  6. Very specific:

    Test: launch dops, navigate to the runbook, execute it

    line 145

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Create a dops Runbook

Directory Structure

Runbooks live under DOPS_HOME/catalogs/<catalog>/<runbook-name>/:

~/.dops/catalogs/<catalog>/<runbook-name>/
├── runbook.yaml    # Runbook definition
└── script.sh       # Automation script (POSIX sh)

runbook.yaml Schema

name: <runbook-name>          # Must match directory name
version: 1.0.0
description: Short description of what this runbook does
risk_level: low               # low | medium | high | critical
script: script.sh
parameters:
  - name: endpoint
    type: string              # See parameter types below
    required: true
    description: What this parameter does
    scope: global             # local | global | catalog | runbook
    default: ""               # Optional default value
    secret: false             # If true, masked in UI, excluded from MCP
    options: []               # Required for select and multi_select

Parameter Types

TypeDescriptionValidation
stringFree text—
booleanYes/No toggle—
integerWhole number (negative ok)strconv.Atoi
numberNon-negative whole number (0+)Must be >= 0
floatDecimal numberstrconv.ParseFloat
selectSingle choice from optionsRequires options list
multi_selectMultiple choices from optionsRequires options list
file_pathFile system path—
resource_idResource identifier (ARN, URI)—

Risk Levels

LevelTUI ConfirmationMCP Confirmation
lowNoneNone
mediumNoneNone
highy/N prompt_confirm_id param must match runbook ID
criticalType runbook ID_confirm_word param must be "CONFIRM"

Scopes

Values are saved to the encrypted vault.json (age AEAD, tamper-resistant).

ScopeWhere savedUse when
localNot savedOne-time values, never prompted to save
globalvault.json → vars.global.<name>Shared across all runbooks (API tokens, regions)
catalogvault.json → vars.catalog.<cat>.<name>Shared within a catalog
runbookvault.json → vars.catalog.<cat>.runbooks.<rb>.<name>Specific to this runbook

Script Template (POSIX sh)

#!/bin/sh
set -eu

# dops passes parameters as UPPERCASE environment variables.
# Parameter "endpoint" → $ENDPOINT
# Parameter "dry_run" → $DRY_RUN
ENDPOINT="${ENDPOINT:?endpoint is required}"
DRY_RUN="${DRY_RUN:-false}"

main() {
  echo "==> Stage 1/2: Validate"
  echo "    Checking ${ENDPOINT}..."
  # TODO: implement

  echo ""
  echo "==> Stage 2/2: Execute"
  echo "    Running operation..."
  # TODO: implement

  echo ""
  echo "✓ Done"
}

main "$@"

Shell Style Rules (POSIX-compatible)

  1. Use #!/bin/sh — not #!/bin/bash (POSIX compatibility for Linux/macOS)
  2. Use set -eu — not set -euo pipefail (pipefail is not POSIX)
  3. Quote all variables: "${var}" not $var
  4. Use [ ] not [[ ]] — POSIX test
  5. Use $(command) not backticks
  6. Stderr for errors: echo "error" >&2
  7. Indent with 2 spaces, no tabs
  8. Put main() at the bottom of the script
  9. Use command -v not which
  10. Use printf over echo -e for portability

Output Conventions

# Stage headers
echo "==> Stage 1/3: Build"

# Indented details
echo "    Compiling source..."

# Success
echo "✓ Build complete"

# Failure
echo "✗ Build failed" >&2

# Summary block
echo "========================================="
echo "  Summary"
echo "========================================="
echo "  Status: SUCCESS"
echo "========================================="

Workflow

  1. Determine the catalog name and runbook name
  2. Create the directory: mkdir -p ~/.dops/catalogs/<catalog>/<name>
  3. Write runbook.yaml with the schema above
  4. Write script.sh following the POSIX template
  5. chmod +x script.sh
  6. If the catalog is new, register it: dops catalog add ~/.dops/catalogs/<catalog>
  7. Test: launch dops, navigate to the runbook, execute it

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.