Skill: ivangdavila/home-server (version 1.0.0)

--- name: Home Server slug: home-server version: 1.0.0 homepage: https://clawic.com/skills/home-server description: Plan, secure, and maintain a home server with Docker services, remote access, backups, and incident recovery. changelog: Initial release with practical home server planning, security, and recovery workflows. metadata: {"clawdbot":{"emoji":"🏠","requires":{"bins":[]},"os":["linux","darwin","win32"],"configPaths":["~/home-server/"]}} --- ## Setup On first use, read `setup.md`, explain planned local storage in `~/home-server/`, and ask for confirmation before creating files. ## When to Use User needs help designing, deploying, or operating a home server environment. Agent handles architecture choices, secure exposure, service operations, backup strategy, and recovery planning. ## Architecture Memory lives in `~/home-server/`. See `memory-template.md` for setup. ```text ~/home-server/ ├── memory.md # Current environment and preferences ├── services.md # Service inventory and ownership ├── backup-status.md # Backup coverage and restore checks └── incidents.md # Failure timeline and recovery notes ``` ## Quick Reference | Topic | File | |-------|------| | Setup behavior | `setup.md` | | Memory structure | `memory-template.md` | | Service inventory model | `service-catalog.md` | | Operational routines | `operations-checklists.md` | | Incident response flow | `incident-playbook.md` | ## Core Rules ### 1. Define Trust Boundaries First - Classify every service as LAN-only, VPN-only, or internet-facing before deployment. - Never expose admin panels or databases directly to the internet. ### 2. Design Around Recoverable Data - Identify where each service stores state before changing configs or images. - Back up data paths first, then update workloads. - Never request or store raw secrets, full `.env` dumps, or private keys in workspace memory. ### 3. Prefer Stable, Reproducible Deployments - Use pinned image tags and declarative Compose files. - Keep runtime variables documented so rebuilds are deterministic. ### 4. Secure the Host Before Scaling Services - Enforce key-based SSH, minimal open ports, and regular security updates. - Apply least privilege for containers, users, and file permissions. ### 5. Operate with Observable Signals - Track health checks, disk usage, certificate expiry, and backup freshness. - Treat silent failures as incidents and document root cause quickly. ### 6. Validate Recovery Paths Continuously - Test restore procedures on a schedule, not only after failures. - Require rollback plans before major upgrades or topology changes. ## Common Traps - Installing services before defining backup paths -> data loss during first migration. - Publishing many ports directly on the router -> large attack surface and hard troubleshooting. - Using `latest` tags everywhere -> surprise upgrades and inconsistent behavior. - Skipping restore drills -> backups exist but cannot be trusted in real incidents. - Running all workloads on one Docker network -> accidental lateral access between services. ## Security & Privacy **Data that may leave your machine (only when configured):** - DNS or dynamic DNS updates to your selected provider. - Telemetry from optional monitoring stacks you install. **Data that stays local by default:** - Service configs, logs, backup manifests, and incident notes in your home-server workspace. **This skill does NOT:** - Open ports automatically. - Deploy services without explicit user instruction. - Send undeclared external requests. ## Related Skills Install with `clawhub install <slug>` if user confirms: - `self-host` — self-hosted service strategy and security baselines - `server` — server deployment and troubleshooting patterns - `docker` — container build and runtime discipline - `docker-compose` — multi-service orchestration patterns - `linux` — host administration and system diagnostics ## Feedback - If useful: `clawhub star home-server` - Stay updated: `clawhub sync`

path: incident-playbook.md
content: # Incident Playbook

## Severity Levels

- Sev-1: Data at risk or total outage
- Sev-2: Major feature unavailable with workaround
- Sev-3: Degraded performance or isolated failure

## First Five Minutes

1. Stabilize: stop automated changes and preserve evidence.
2. Scope: identify affected services, users, and data paths.
3. Contain: isolate failing components from healthy traffic.
4. Communicate: post concise status with next update time.

## Triage Commands (Adapt to Host)

- Service state: process manager status or container health
- Network state: listening ports and recent connection errors
- Storage state: free space, I/O saturation, filesystem health
- Logs: reverse proxy, application, and host security logs

## Recovery Sequence

1. Restore control plane dependencies (DNS, proxy, auth).
2. Recover stateful stores from latest verified snapshot.
3. Bring stateless services back online.
4. Run functional smoke checks before full traffic.

## Post-Incident Review

- Timeline with timestamps and key decisions
- Root cause and contributing factors
- Preventive actions with owners and deadlines
- Detection improvements for earlier alerting


path: memory-template.md
content: # Memory Template - Home Server

Create `~/home-server/memory.md` with this structure:

```markdown
# Home Server Memory

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

## Context
- Hardware profile and host OS
- Core services and exposure policy
- Stated reliability and security priorities

## Service Inventory
- Service name -> purpose -> data path -> exposure level
- Owner and maintenance cadence

## Backup Coverage
- What is backed up
- Where backups are stored
- Last restore test date

## Notes
- Repeated failure patterns
- Proven recovery procedures
- Preferences inferred from behavior

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

## Status Values

| Value | Meaning | Behavior |
|-------|---------|----------|
| `ongoing` | Context still evolving | Keep learning from normal work |
| `complete` | Stable environment model exists | Operate with current assumptions |
| `paused` | User requested less setup discussion | Limit follow-up questions |
| `never_ask` | User asked to stop setup discovery | Only use explicit requests |

## Rules

- Use natural language observations, not exposed config keys.
- Update `last` whenever home server context changes.
- Promote recurring incidents into explicit prevention notes.
- Never delete prior context without confirmation.


path: operations-checklists.md
content: # Operations Checklists

## Daily Signals

- Check service health dashboards for failed checks.
- Confirm disk utilization trend is stable.
- Verify backup jobs completed without errors.

## Weekly Maintenance

- Review container and host update advisories.
- Rotate logs and inspect sudden growth.
- Revalidate exposed ports against intended policy.

## Before Any Upgrade

- Confirm current backup snapshot age is acceptable.
- Capture a sanitized deployment snapshot: image tags, ports, mounted paths, and feature flags.
- Never export raw environment variables or secret values into notes.
- Define explicit rollback trigger and rollback owner.
- Apply updates in low-risk order: proxy -> shared services -> apps.

## After Upgrade

- Validate login flow and critical user actions.
- Compare resource usage with pre-upgrade baseline.
- Close with a short incident-style note even if no issues occurred.

## Monthly Reliability Check

- Test at least one restore path end-to-end.
- Audit stale services that no longer have an owner.
- Review long-lived warnings and convert to actions.


path: service-catalog.md
content: # Service Catalog Template

Use this model to keep service ownership and risk visible.

## Required Fields

- Service name and business purpose
- Runtime (container, VM, host process)
- Data location and backup owner
- Exposure level: LAN-only, VPN-only, or internet-facing
- Authentication boundary and admin URL policy
- Health check source and alert destination

## Lightweight Table

| Service | Runtime | Data Path | Exposure | Backup | Health Check |
|---------|---------|-----------|----------|--------|--------------|
| Example: nextcloud | docker | /srv/nextcloud | VPN-only | nightly snapshot | uptime probe |

## Ownership Rules

- Every service has a primary owner and fallback owner.
- Every internet-facing service has a documented reverse proxy route.
- Every stateful service has restore instructions linked in incident notes.

## Review Cadence

- Weekly: health and disk trend review
- Monthly: patch level and certificate expiry review
- Quarterly: restore drill and dependency refresh


path: setup.md
content: # Setup - Home Server

If `~/home-server/` does not exist or is empty, start with a short transparent onboarding. Explain which local files will be created and ask for confirmation before writing anything.

## Your Attitude

Be practical, calm, and reliability-focused. The user should feel this will reduce risk and save time, not add process overhead.

## Priority Order

### 1. First: Integration

Within the first exchanges, clarify how this should activate in future conversations.

Ask naturally:
- Should this activate whenever they mention homelab, NAS, Docker services, reverse proxy, or home networking?
- Should it proactively warn about security and backup gaps, or only when asked?
- Are there situations where it should stay passive?

### 2. Then: Understand Current Environment

Build a quick baseline:
- Host platform and hardware constraints
- Current service stack and exposure model
- Existing backup and monitoring habits

Favor open questions that reveal operations maturity and risk tolerance.

### 3. Finally: Capture Detail Only When Useful

If the user wants depth, collect:
- Preferred deployment tooling
- Update cadence and maintenance windows
- Incident escalation style and documentation level

If the user wants speed, keep lightweight defaults and proceed.

## What You Are Saving Internally

Track only reusable context:
- Activation preferences for future sessions
- Home server topology, critical services, and data locations
- Security decisions, backup coverage, and unresolved risks
- Incident patterns and successful recovery steps

Always summarize what was saved in plain language after updates so the user can correct or remove it immediately.
After each relevant answer, reflect the value back and connect it to a concrete operating benefit.


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