agentleFS
lgbarnlgbarn/devops-skills/skills/using-devops-skills/SKILL.md

using-devops-skills

Skill15 starsChanged 9 months agoMITView on GitHub

Use when starting any conversation - establishes mandatory skill invocation for both Development AND Operations workflows

We split this skill into the rules it gives an agent

9 rules. About 0 are common, 8 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈8

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    If you think there is even a 1% chance a skill might apply to what you are doing, you ABSOLUTELY MUST invoke the skill.

    line 7
  2. Distinctive:

    IF A SKILL APPLIES TO YOUR TASK, YOU DO NOT HAVE A CHOICE.

    line 9
  3. Distinctive:

    Test First: - Write tests before implementation (TDD)

    line 19
  4. Distinctive:

    Debug Systematically: - Follow evidence, not hunches

    line 20
  5. Distinctive:

    Never Auto-Apply: - All terraform/tofu apply commands require explicit user approval

    line 25
  6. Distinctive:

    Escalate Conflicts: - When uncertain, ask the user rather than guessing

    line 27
  7. Very specific:

    In Claude Code: Use the Skill tool. When you invoke a skill, its content is loaded and presented to you—follow it directly.

    line 32
  8. Distinctive:

    When multiple skills could apply, use this order:

    line 104
  9. Distinctive:

    Infrastructure skills: when working with IaC

    line 108

≈ “Common” is an estimate: at least 1 in 5 of the 308,232 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
<EXTREMELY-IMPORTANT> If you think there is even a 1% chance a skill might apply to what you are doing, you ABSOLUTELY MUST invoke the skill.

IF A SKILL APPLIES TO YOUR TASK, YOU DO NOT HAVE A CHOICE. YOU MUST USE IT.

This is not negotiable. This is not optional. You cannot rationalize your way out of this.

This plugin supports the FULL DevOps lifecycle - Development AND Operations. </EXTREMELY-IMPORTANT>

Core Principles

For Development

  1. Test First - Write tests before implementation (TDD)
  2. Debug Systematically - Follow evidence, not hunches
  3. Review Thoroughly - Code review before merge
  4. Plan Before Coding - Design before implementation

For Operations

  1. Never Auto-Apply - All terraform/tofu apply commands require explicit user approval
  2. Explain Each Step - Guide the user through what will happen before doing it
  3. Escalate Conflicts - When uncertain, ask the user rather than guessing
  4. Fewer Mistakes - Safety over speed, always

How to Access Skills

In Claude Code: Use the Skill tool. When you invoke a skill, its content is loaded and presented to you—follow it directly. Never use the Read tool on skill files.

The Rule

Invoke relevant or requested skills BEFORE any response or action. Even a 1% chance a skill might apply means you should invoke the skill.

digraph skill_flow {
    "User message received" [shape=doublecircle];
    "Might any skill apply?" [shape=diamond];
    "Invoke Skill tool" [shape=box];
    "Announce: 'Using [skill] to [purpose]'" [shape=box];
    "Has checklist?" [shape=diamond];
    "Create TodoWrite todo per item" [shape=box];
    "Follow skill exactly" [shape=box];
    "Respond (including clarifications)" [shape=doublecircle];

    "User message received" -> "Might any skill apply?";
    "Might any skill apply?" -> "Invoke Skill tool" [label="yes, even 1%"];
    "Might any skill apply?" -> "Respond (including clarifications)" [label="definitely not"];
    "Invoke Skill tool" -> "Announce: 'Using [skill] to [purpose]'";
    "Announce: 'Using [skill] to [purpose]'" -> "Has checklist?";
    "Has checklist?" -> "Create TodoWrite todo per item" [label="yes"];
    "Has checklist?" -> "Follow skill exactly" [label="no"];
    "Create TodoWrite todo per item" -> "Follow skill exactly";
}

Available Skills

Development Skills

TaskSkillWhen to Use
Writing new codebrainstormingBefore any creative work
Implementing featurestest-driven-developmentWriting tests first, then code
Fixing bugssystematic-debuggingFollow evidence to root cause
Code reviewrequesting-code-reviewAfter completing implementation
Receiving feedbackreceiving-code-reviewWhen getting review comments
Planning implementationwriting-plansMulti-step task design
Executing plansexecuting-plansFollowing implementation plans
Parallel workdispatching-parallel-agentsMultiple independent tasks
Multi-agent executionsubagent-driven-developmentComplex parallel implementation
Isolated workusing-git-worktreesFeature isolation
Completing workfinishing-a-development-branchReady to merge
Verificationverification-before-completionBefore claiming "done"

Operations Skills

TaskSkillWhen to Use
terraform planterraform-plan-reviewBefore any apply
State surgeryterraform-state-operationsmv, rm, import operations
Drift detectionterraform-drift-detectionChecking for out-of-band changes
AWS operationsaws-profile-managementBefore any AWS/Terraform work
Provider upgradesprovider-upgrade-analysisAnalyzing upgrade impact
Generate docsauto-documentationCreating READMEs, runbooks
Past patternshistorical-pattern-analysisLearning from git history

Commands

CommandPurpose
/planRun terraform plan with parallel analysis
/driftDetect infrastructure drift
/review-infraFull IaC code review
/upgrade-checkProvider upgrade analysis
/generate-docsAuto-generate documentation
/env-compareCompare environments

Skill Priority

When multiple skills could apply, use this order:

  1. Process skills first (brainstorming, debugging) - these determine HOW to approach the task
  2. Implementation skills second (TDD, code review) - these guide execution
  3. Infrastructure skills when working with IaC

Examples:

  • "Let's build X" → brainstorming first, then TDD
  • "Fix this bug" → systematic-debugging first
  • "Deploy this change" → terraform-plan-review, then aws-profile-management

Red Flags - STOP if You Think These

Development Red Flags

ThoughtReality
"This is just a simple fix"Simple fixes can have complex impacts. Use skills.
"I'll add tests later"Tests first. Always. Use TDD skill.
"I know how to debug this"Follow systematic-debugging anyway.
"Let me just explore first"Skills tell you HOW to explore. Check first.

Operations Red Flags

ThoughtReality
"I'll just run a quick apply"NEVER. Use /plan first, get approval.
"This is a simple change"Simple changes can cascade. Use the skill.
"I can fix it if it breaks"Infrastructure mistakes can be irreversible.
"This is just a dev environment"Treat all environments with same rigor.

Dangerous Commands - ALWAYS BLOCKED

These commands are intercepted by safety hooks:

  • terraform apply / tofu apply (without explicit approval flow)
  • terraform destroy / tofu destroy
  • terraform state rm
  • terraform force-unlock
  • Any command with -auto-approve flag

Parallel Agent Workflows

For complex tasks, dispatch multiple agents in parallel:

Infrastructure Analysis

/plan command →
  ├─→ Task(terraform-plan-analyzer) → Risk Analysis
  ├─→ Task(security-reviewer) → Security Analysis
  └─→ Task(historical-pattern-analyzer) → Pattern Detection

Development Tasks

Multiple test failures →
  ├─→ Task(fix test file A)
  ├─→ Task(fix test file B)
  └─→ Task(fix test file C)

Memory System

DevOps-skills maintains memory across sessions for learning from history.

User Instructions

Instructions say WHAT, not HOW. "Add X" or "Fix Y" doesn't mean skip workflows.

The user's #1 goal is fewer mistakes. Honor that above all else - in BOTH development AND operations.

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.

Reviews can't be read right now.

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.