Skill: ivangdavila/minio (version 1.0.0)

--- name: MinIO S3 (Object Storage) slug: minio version: 1.0.0 homepage: https://clawic.com/skills/minio description: Deploy, secure, and operate MinIO object storage using mc workflows, policy controls, replication, and incident-safe runbooks. changelog: Initial release with MinIO deployment, policy, replication, and recovery playbooks for object storage operations. metadata: {"clawdbot":{"emoji":"🗂️","requires":{"bins":["mc","curl","openssl"]},"os":["linux","darwin","win32"],"configPaths":["~/minio/"]}} --- ## Setup On first use, read `setup.md` to align activation boundaries, environment defaults, and write-approval rules before mutating buckets, policies, or replication. ## When to Use Use this skill when the user needs MinIO deployment, bucket lifecycle operations, access policy work, object retention planning, or incident recovery. Use this for single-node labs, distributed production clusters, S3-compatible migration tasks, and operational troubleshooting where data durability and access correctness are critical. ## Architecture Memory lives in `~/minio/`. See `memory-template.md` for structure and status values. ```text ~/minio/ |-- memory.md # Activation preferences and approval model |-- environments.md # Endpoint map, topology, and region notes |-- buckets.md # Bucket inventory, versioning, lifecycle, lock mode |-- identities.md # Users, groups, policies, and credential rotation state `-- incidents.md # Outages, corruption events, and validated recovery steps ``` ## Quick Reference Use the smallest file needed for the current task. | Topic | File | |-------|------| | Setup and activation behavior | `setup.md` | | Memory structure and status model | `memory-template.md` | | Deployment and topology choices | `deployment-patterns.md` | | Bucket, IAM, and mc execution flow | `mc-operations.md` | | Hardening, backup, and disaster recovery | `hardening-dr.md` | ## Core Rules ### 1. Classify Topology Before Any Command - Identify single-node, distributed, or tenant-style deployment before writing a plan. - Validate endpoint, region, and storage layout so commands target the correct environment. ### 2. Gate Write Operations with Explicit Confirmation - Bucket deletion, lifecycle rewrite, policy replacement, and replication changes need explicit user confirmation. - Confirm scope, expected impact, and rollback path before applying mutating actions. ### 3. Use Read-Then-Write mc Workflows - Start with read commands (`mc admin info`, `mc ls`, `mc policy ls`) before write commands. - Keep command output snapshots so post-change verification can compare expected versus observed state. ### 4. Enforce Identity and Policy Least Privilege - Default to scoped policies by bucket and prefix rather than broad wildcard access. - Rotate access keys and verify policy bindings after every security-sensitive change. ### 5. Protect Durability Features During Maintenance - Check versioning, object lock, retention mode, and replication health before major updates. - Never disable durability controls without a documented user-approved exception. ### 6. Verify by API Behavior, Not Only Command Exit Codes - Confirm changes with independent checks: listing, object test writes (if approved), and policy simulation. - Treat partial success as failure until data path and auth path both validate. ### 7. Record Durable Context for Next Sessions - Update `~/minio/` notes with environment constraints, safe defaults, and incident learnings. - Keep only reusable operational context, never secrets or raw credentials. ## Common Traps - Treating MinIO like generic S3 without checking deployment mode -> commands succeed but behavior differs in distributed setups. - Replacing policies without reading effective bindings -> accidental privilege expansion or lockout. - Enabling replication before validating versioning and time sync -> replication drift and conflict noise. - Running lifecycle expiration on active prefixes without dry checks -> unexpected object loss. - Skipping pre-change snapshots -> no reliable rollback path during outage response. - Assuming TLS is valid because endpoint is reachable -> clients fail later due to trust-chain mismatch. ## External Endpoints | Endpoint | Data Sent | Purpose | |----------|-----------|---------| | https://<minio-endpoint> | S3 API object and metadata requests | Bucket and object operations against user-managed MinIO | | https://<minio-endpoint>/minio/admin | Admin API requests for cluster and identity operations | Health, IAM, and operational control | | https://min.io/docs | Documentation lookups only | Reference for command behavior and configuration details | No other data is sent externally. ## Security & Privacy Data that leaves your machine: - Requests to user-managed MinIO endpoints for object, bucket, and IAM operations. - Optional documentation fetches from official MinIO docs. Data that stays local: - Operational context stored in `~/minio/`. - Command planning notes, incident logs, and approved runbooks. This skill does NOT: - Execute undeclared endpoints. - Store raw credentials in memory files. - Approve destructive or privilege-changing writes without explicit confirmation. - Modify SKILL.md or auxiliary files automatically. ## Trust This skill can send data to MinIO endpoints and optional documentation endpoints when executing approved operations. Only install if you trust the configured MinIO infrastructure and its credential handling model. ## Related Skills Install with `clawhub install <slug>` if user confirms: - `s3` - S3-compatible object storage workflows across providers - `cloud-storage` - Storage architecture patterns for mixed cloud and local environments - `backups` - Backup verification and restore-first operating practices - `infrastructure` - Infrastructure planning and production operations baselines - `docker` - Containerized deployment and service lifecycle operations ## Feedback - If useful: `clawhub star minio` - Stay updated: `clawhub sync`

path: deployment-patterns.md
content: # Deployment Patterns - MinIO

Use this guide to select a deployment shape before any data migration or production cutover.

## Pattern Matrix

| Pattern | Best For | Tradeoffs | First Checks |
|---------|----------|-----------|--------------|
| Single Node | Labs, low-risk internal tools | Simple but no distributed durability | Disk health, backup cadence, TLS enabled |
| Distributed Erasure Set | Production object workloads | More moving parts and network sensitivity | Node count parity, clock sync, network path quality |
| Tenant Style Isolation | Multi-team environments | Higher operational overhead | Per-tenant policy boundaries, quota model, monitoring split |

## Capacity and Durability Baseline

Before provisioning:
- estimate object growth for 90 days and 12 months
- reserve headroom for rebuild and healing operations
- validate target IO profile with representative object sizes

Before cutover:
- confirm versioning defaults for critical buckets
- confirm object lock and retention requirements
- confirm backup and restore test has passed

## TLS and Endpoint Design

- Assign stable DNS names per environment.
- Use certificates with correct SAN coverage for API and console endpoints.
- Validate chain trust from every client environment that will run `mc`.

## Networking Guardrails

- Keep east-west traffic predictable between storage nodes.
- Avoid mixed latency paths inside one distributed set.
- Monitor packet loss and clock skew continuously.

## Change Rollout Strategy

Use progressive rollout:
1. Pilot one low-risk bucket.
2. Validate reads, writes, policies, and lifecycle behavior.
3. Expand by workload class, not by all buckets at once.

Stop rollout immediately if validation fails.
Fix root cause before resuming.


path: hardening-dr.md
content: # Hardening and Disaster Recovery

Use this playbook for security baselines and outage recovery planning.

## Security Baseline

- Enforce TLS for all API and console traffic.
- Use short-lived credentials where possible.
- Restrict wildcard policies and anonymous access.
- Enable audit logs and preserve immutable retention where required.

## Encryption Decisions

- Define server-side encryption defaults for critical buckets.
- Document key ownership and rotation policy.
- Validate restore workflows with encrypted objects.

## Backup and Restore Discipline

- Back up configuration and policy state along with object data.
- Test restore by reading real objects after recovery.
- Measure restore times and compare with target objectives.

## Incident Response Sequence

1. Freeze non-essential writes.
2. Capture cluster and bucket health snapshot.
3. Isolate scope (single bucket, node set, or policy domain).
4. Execute lowest-risk recovery path.
5. Verify data-path and auth-path integrity.
6. Resume traffic in stages with monitoring.

## Post-Incident Hardening

After recovery:
- record root cause and exact recovery steps
- update guardrails in `memory.md` and `incidents.md`
- tighten monitoring for the failure signature
- schedule a restore drill for the affected scenario

## Red Flags

- Recovery plans that have never been tested in a real restore.
- Shared admin credentials across environments.
- Policy updates without pre-change snapshots.
- Replication enabled without versioning checks.


path: mc-operations.md
content: # mc Operations Playbook

Use these workflows to run MinIO tasks with clear preflight and verification steps.

## Baseline Preflight

Before any write action:
- verify alias target and environment
- capture current state for buckets and policies
- confirm approval for mutating scope

Suggested read commands:
- `mc admin info <alias>`
- `mc ls <alias>`
- `mc policy ls <alias>`

## Bucket Lifecycle Workflow

1. Inspect current bucket settings.
2. Confirm versioning and retention requirements.
3. Apply changes in smallest safe scope.
4. Validate with independent read checks.
5. Record change and timestamp in `incidents.md` or `buckets.md`.

## Identity and Policy Workflow

1. List users, groups, and attached policies.
2. Diff requested policy against effective policy.
3. Apply least-privilege policy update.
4. Re-test access with representative operations.
5. Rotate credentials if scope changed materially.

## Replication Workflow

1. Verify source and target versioning state.
2. Validate clock sync and endpoint reachability.
3. Configure replication rule.
4. Test object flow on controlled prefix.
5. Review lag and failed events before expansion.

## Verification Checklist

After each mutating action, confirm:
- expected policy behavior from a scoped test
- expected bucket settings from direct read commands
- no new errors in admin status output
- rollback path is still valid

If any check fails, treat the change as incomplete and recover before continuing.


path: memory-template.md
content: # Memory Template - MinIO Operations

Create `~/minio/memory.md` with this structure:

```markdown
# MinIO Operations Memory

## Status
status: ongoing
version: 1.0.0
last: YYYY-MM-DD
integration: pending | done | declined

## Activation Preferences
- Auto-activation boundaries for MinIO and S3-compatible operations
- Ask-first versus proactive behavior by risk level
- Environments where auto-activation is restricted

## Environment Context
- Endpoint aliases, deployment mode, and region conventions
- Storage topology and capacity constraints
- Encryption and TLS baseline decisions

## Buckets and Data Controls
- Bucket inventory and high-risk prefixes
- Versioning, object lock, retention, and lifecycle expectations
- Replication scope and validation cadence

## Identity and Access
- User and group policy boundaries
- Key rotation cadence and ownership
- Audit and least-privilege decisions

## Incident Patterns
- Recurring failure signatures
- Confirmed rollback and recovery procedures
- Post-incident hardening actions

## Notes
- Durable context that improves future operations

---
*Updated: YYYY-MM-DD*
```

## Status Values

| Value | Meaning | Behavior |
|-------|---------|----------|
| `ongoing` | Context still evolving | Keep collecting context during normal work |
| `complete` | Core environment context is stable | Execute quickly with minimal clarification |
| `paused` | User paused setup prompts | Continue tasks using existing context |
| `never_ask` | User does not want setup prompts | Do not ask setup questions unless requested |

## Memory Principles

- Keep entries factual and tied to operational decisions.
- Replace stale assumptions instead of stacking contradictions.
- Save reusable context only, not one-off task chatter.
- Never store secrets, raw keys, or unrelated personal data.
- Update `last` after each meaningful execution.


path: setup.md
content: # Setup - MinIO Operations

Use this when `~/minio/` does not exist or is empty.
Keep setup lightweight and answer the active request first.

## Your Attitude

Operate like a careful storage reliability engineer.
Prioritize data safety, access correctness, and reversible execution.

## Activation First

Within the first exchanges, align activation boundaries:
- Should this activate whenever MinIO, bucket policy, S3 compatibility, replication, or object lock topics appear?
- Should read-only diagnostics run proactively while all write actions stay ask-first?
- Are there environments where this skill should never auto-activate?

## Environment Snapshot

Capture only decision-changing context:
- endpoint aliases and environment names (dev, staging, production)
- deployment mode and storage layout
- data criticality and acceptable recovery point/recovery time expectations
- preferred toolchain (`mc`, console, or mixed execution)

Avoid long questionnaires. Gather context while working on real tasks.

## Execution Defaults

Use these defaults until user behavior indicates otherwise:
- read-then-write flow for all change operations
- explicit confirmation before bucket delete, policy replace, retention changes, or replication updates
- pre-change state snapshot for buckets, policies, and replication
- post-change validation using independent read checks

## What to Save Internally

Persist durable context in `memory.md`:
- activation boundaries and approval mode
- endpoint aliases, topology constraints, and validated safe defaults
- recurring failure signatures and proven mitigations
- compliance expectations for retention, encryption, and access audits

Keep notes concise and operational.

## Status Model

Use status values from `memory-template.md`:
- `ongoing` when context is still evolving
- `complete` when environment and approval behavior are stable
- `paused` when setup prompts should stop temporarily
- `never_ask` when setup prompts should not be used

## Guardrails

- Never run destructive object or bucket operations without explicit approval.
- Never assume policy inheritance; verify effective access before and after changes.
- Never treat command success as full success without data-path verification.
- Never store secrets, access keys, or tokens in local memory files.


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: clean (LOW)