Smithery is now a part of Arcade.dev! Read more in our announcement here
Use when starting any conversation - establishes mandatory skill invocation for both Development AND Operations workflows
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.
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.
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";
}
| Task | Skill | When to Use |
|---|---|---|
| Writing new code | brainstorming | Before any creative work |
| Implementing features | test-driven-development | Writing tests first, then code |
| Fixing bugs | systematic-debugging | Follow evidence to root cause |
| Code review | requesting-code-review | After completing implementation |
| Receiving feedback | receiving-code-review | When getting review comments |
| Planning implementation | writing-plans | Multi-step task design |
| Executing plans | executing-plans | Following implementation plans |
| Parallel work | dispatching-parallel-agents | Multiple independent tasks |
| Multi-agent execution | subagent-driven-development | Complex parallel implementation |
| Isolated work | using-git-worktrees | Feature isolation |
| Completing work | finishing-a-development-branch | Ready to merge |
| Verification | verification-before-completion | Before claiming "done" |
| Task | Skill | When to Use |
|---|---|---|
terraform plan |
terraform-plan-review | Before any apply |
| State surgery | terraform-state-operations | mv, rm, import operations |
| Drift detection | terraform-drift-detection | Checking for out-of-band changes |
| AWS operations | aws-profile-management | Before any AWS/Terraform work |
| Provider upgrades | provider-upgrade-analysis | Analyzing upgrade impact |
| Generate docs | auto-documentation | Creating READMEs, runbooks |
| Past patterns | historical-pattern-analysis | Learning from git history |
| Command | Purpose |
|---|---|
/plan |
Run terraform plan with parallel analysis |
/drift |
Detect infrastructure drift |
/review-infra |
Full IaC code review |
/upgrade-check |
Provider upgrade analysis |
/generate-docs |
Auto-generate documentation |
/env-compare |
Compare environments |
When multiple skills could apply, use this order:
Examples:
| Thought | Reality |
|---|---|
| "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. |
| Thought | Reality |
|---|---|
| "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. |
These commands are intercepted by safety hooks:
terraform apply / tofu apply (without explicit approval flow)terraform destroy / tofu destroyterraform state rmterraform force-unlock-auto-approve flagFor complex tasks, dispatch multiple agents in parallel:
/plan command →
├─→ Task(terraform-plan-analyzer) → Risk Analysis
├─→ Task(security-reviewer) → Security Analysis
└─→ Task(historical-pattern-analyzer) → Pattern Detection
Multiple test failures →
├─→ Task(fix test file A)
├─→ Task(fix test file B)
└─→ Task(fix test file C)
DevOps-skills maintains memory across sessions for learning from history.
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.
