What this is

A curated marketplace of 19 Claude Code plugins, one per cloud, each shipping:

Every plugin is schema-validated, follows a canonical structure enforced by CI, and bakes in production-grade defaults: encryption-at-rest, least-privilege identity, private-by-default networking, observability before launch, cost flagged at decision time.

Why use this? You want Claude Code to be opinionated and right about cloud choices, not generic. The skills are scoped tightly enough to fire only when relevant, deep enough to actually help, and consistent enough across providers that switching clouds doesn't break your muscle memory.

🚀 Quick start

From any Claude Code session:

/plugin marketplace add /absolute/path/to/blackrim-nimbus-skills
/plugin install cloud-aws@blackrim-cloud-toolkits

That's it. The next time you ask Claude something compute-shaped on AWS — "should this be a Lambda or an ECS task?" — the aws-compute skill auto-fires with a decision tree, defaults, and anti-patterns.

Install multiple plugins side-by-side:

/plugin install cloud-aws@blackrim-cloud-toolkits
/plugin install cloud-cloudflare@blackrim-cloud-toolkits
/plugin install cloud-supabase@blackrim-cloud-toolkits

Try the sub-agents

Use the aws-architect agent to review my CDK stack against the Well-Architected pillars.

Use the cf-security-reviewer agent to audit my wrangler.toml + Workers code for exposure.

Try the slash commands

/aws-scaffold-iac a multi-AZ web service with a Postgres backend and CloudFront in front

🗺️ The matrix

Hyperscalers

Edge · Zero Trust · Frontend

Modern PaaS · Dev-first · BaaS

VPS · Regional · Cost-leader

🎯 Pick a provider

🧩 Plugin anatomy

Every plugin follows the same shape. Predictable layout, predictable surface area.

cloud-<provider>/
├── .claude-plugin/
│   └── plugin.json                              # manifest (name, prefix, keywords, ...)
├── README.md                                    # has a managed "What's inside" region
├── skills/
│   ├── <prefix>-compute/SKILL.md                # runtime selection + sizing
│   ├── <prefix>-storage-and-databases/SKILL.md  # data tier decisions
│   ├── <prefix>-networking-and-edge/SKILL.md    # VPC / LB / DNS / WAF / CDN
│   ├── <prefix>-identity-and-security/SKILL.md  # IAM, KMS, secrets, audit
│   ├── <prefix>-observability-and-cost/SKILL.md # metrics, logs, traces, FinOps
│   └── <prefix>-iac-and-deployment/SKILL.md     # IaC tool selection + CI/CD
├── agents/
│   ├── <prefix>-architect.md                    # well-architected reviewer
│   └── <prefix>-security-reviewer.md            # security audit
└── commands/
    └── <prefix>-scaffold-iac.md                 # IaC project scaffold

Note on <prefix> — usually matches the provider name (aws-, gcp-), but some diverge: Cloudflare uses cf-, DigitalOcean uses do-. The plugin's prefix is declared in plugin.json.

For platforms whose shape diverges from generic IaaS (Cloudflare's Zero Trust, Vercel's edge runtime, Supabase's Postgres+Auth model, Fly's Firecracker fleet), the six-slot template flexes — e.g. cf-workers-and-compute, supabase-auth, vercel-frontend-platform.

📖 Skill anatomy

Each SKILL.md follows a consistent shape so Claude knows what to expect and contributors know what to write:

---
name: <skill-slug>
description: <when to use this skill — fires on description match>
---

# <Skill Title>

## When to use
- Concrete triggering conditions

## Decision tree / Defaults
Per-service production-grade defaults or a decision tree.

## Anti-patterns
| Anti-pattern | What goes wrong |
| --- | --- |
| ... | ... |

## Security defaults
## Observability defaults
## Cost considerations
## IaC hints

## Verification checklist
- [ ] Items that gate "done"

The Verification checklist is the load-bearing section — it's what gates "is this work actually finished?" The validator enforces it; downstream tooling can parse it via npm run checklist <plugin>.

🧪 What's in the validator

Every plugin and every file is checked by a declarative rule registry at bin/lib/rules.js. Run npm run rules to print the live list (29 rules across 5 scopes).

Architect agents must contain: ## Inputs you expect, ## Review process, ## Output format, ## Rules of engagement. Security-reviewer agents must contain: ## Inputs, ## Review scope — what you check, ## Output, ## Rules of engagement.

CI runs npm run check + npm run regen + asserts no diff on every push and PR. Drift is caught before it lands.

🛠️ Development

Requires Node ≥ 18.

# Setup
git clone https://github.com/jsgerman-oss/blackrim-nimbus-skills.git
cd blackrim-nimbus-skills
npm install

# Validate
npm run check                                # run all 29 rules
npm run check -- --rule plugin-schema        # one rule
npm run check -- --skip skill-checklist-min-items  # skip one
npm run check -- --json                      # machine-readable output

# Inspect
npm run rules                                # list all rules (text)
npm run rules -- --md                        # markdown table
npm run rules -- --json                      # JSON
npm run checklist cloud-aws                  # all checklists in a plugin
npm run checklist cloud-aws aws-compute --json   # JSON for one skill

# Regenerate derived files (run after adding skills/agents/commands or a provider)
npm run regen                                # marketplace.json + plugin READMEs + pack provider index
npm run regen:marketplace                    # marketplace.json only
npm run regen:plugin-readmes                 # plugin README "What's inside" regions only
npm run regen:pack-providers                 # pack/nimbus/providers.json only

Adding a new plugin

1. Create the directory: mkdir -p cloud-<provider>/{.claude-plugin,skills,agents,commands}
2. Write plugin.json (don't forget prefix).
3. Write 5+ skills, two agents (<prefix>-architect.md, <prefix>-security-reviewer.md), one command.
4. npm run regen to update marketplace.json and your README's managed region.
5. npm run check to validate.
6. Open a PR.

See CONTRIBUTING.md for the full file-shape conventions.

🎨 Design principles

1. Defaults are production-grade, not demo-grade. Encryption-at-rest on by default. Private subnets unless public is explicitly required. Least-privilege identity scoped to specific resources, never *.
2. Cost is a first-class concern. Every skill flags cost-amplifying choices (NAT, cross-AZ, idle baselines, infinite log retention) at decision time, not in post-mortem.
3. Observability before launch. No workload ships without metrics, logs, traces, and at least one alarm wired to a real notification channel.
4. IaC over console. Console steps appear only as bootstrap (account hardening). Everything else is code.
5. Well-architected as a checklist, not a vibe. The architect agent maps findings to specific pillar best practices and rates severity.
6. Honest about limits. When a provider lacks a feature — fine-grained tokens, managed databases, anycast LB, fully-managed Postgres — the skill says so out loud rather than papering over it.
7. Schema-validated. Conventions are enforced by code (bin/lib/rules.js), not by reviewer attention.

💡 Worked example

Suppose you're building a multi-region API on Fly.io with Supabase as the data tier. You'd install:

/plugin install cloud-fly@blackrim-cloud-toolkits
/plugin install cloud-supabase@blackrim-cloud-toolkits

Then in your session, the skills fire automatically as you discuss your design:

• "Should I run this in 2 or 6 regions on Fly?" → fly-machines-and-apps skill fires; decision tree on placement vs LiteFS replication.
• "How do I scope RLS so user A can't read user B's rows?" → supabase-postgres-and-rls skill fires; RLS policy templates.
• "Audit my supabase RLS setup before launch." → invoke the supabase-security-reviewer agent.
• "Scaffold the fly.toml for this service." → /fly-scaffold-app slash command.

The cross-plugin story is consistent: every plugin's architect agent uses the same six-step review process; every security-reviewer uses the same four canonical sections; every skill ends with a parseable checklist.

🤝 Contributing

Contributions are welcome — new providers, deeper skills, refined defaults. See CONTRIBUTING.md for:

• File-shape conventions (the canonical 6-skill + 2-agent + 1-command layout)
• Skill anatomy and the verification-checklist contract
• The 28-rule validator and how to add a new rule
• PR checklist

Before opening a PR, run:

npm run check && npm run regen

…and ensure your diff is clean.

📜 License

MIT — Copyright © 2026 Blackrim.dev.

Pull requests, issues, and feature requests are welcome. The full validator output, schema definitions, and rule registry are all open to inspection so you can verify the production-grade-defaults claim isn't marketing.