@rubix0270/arboris 1.0.1 → 1.0.3

package/prisma/skills/homelab-wireguard-vpn/SKILL.md

@@ -1,306 +0,0 @@
----
-name: homelab-wireguard-vpn
-description: WireGuard VPN server setup, peer configuration, key generation, split tunneling vs full tunnel routing, and remote access to a home network from mobile and laptop clients.
-metadata:
-  origin: community
----
-
-# Homelab WireGuard VPN
-
-WireGuard is a fast, modern VPN protocol. It is the right choice for remote access to a
-home network — simpler to configure than OpenVPN and faster than most alternatives.
-
-All configuration examples show common setups. Review each command — especially the
-iptables forwarding rules and key file permissions — before applying them to your
-system, and make changes in a maintenance window.
-
-## When to Use
-
-- Setting up WireGuard server on a Raspberry Pi, Linux host, pfSense, or router
-- Generating WireGuard keypairs and writing peer config files
-- Configuring remote access from a phone or laptop to a home network
-- Explaining split tunneling (route only home traffic) vs full tunnel (route all traffic)
-- Troubleshooting WireGuard connections that will not come up
-- Automating peer configuration generation for multiple clients
-
-## How WireGuard Works
-
-```
-Your phone (WireGuard client)
-    │
-    │  Encrypted UDP tunnel (port 51820)
-    │
-Your home router (WireGuard server — needs a public IP or DDNS)
-    │
-    Your home network (192.168.1.0/24, NAS, Pi, etc.)
-
-Every device has a keypair (public + private key).
-The server knows each client's public key.
-The client knows the server's public key + endpoint (IP:port).
-Traffic is encrypted end-to-end with no central server or certificate authority.
-```
-
-## Server Setup (Linux)
-
-```bash
-# Install WireGuard
-sudo apt update && sudo apt install wireguard -y
-
-# Generate server keypair — create files with private permissions from the start
-sudo mkdir -p /etc/wireguard
-sudo sh -c 'umask 077; wg genkey > /etc/wireguard/server_private.key'
-sudo sh -c 'wg pubkey < /etc/wireguard/server_private.key > /etc/wireguard/server_public.key'
-
-# Write server config — substitute the actual private key value
-# Do not store private keys in version control or share them
-sudo tee /etc/wireguard/wg0.conf << 'EOF'
-[Interface]
-Address = 10.8.0.1/24              # VPN subnet — server gets .1
-ListenPort = 51820
-PrivateKey = <paste_server_private_key_here>
-
-# Scoped forwarding rules: allow VPN traffic in/out, not a blanket FORWARD ACCEPT
-PostUp   = iptables -A FORWARD -i wg0 -o eth0 -j ACCEPT
-PostUp   = iptables -A FORWARD -i eth0 -o wg0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-PostUp   = iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
-PostDown = iptables -D FORWARD -i wg0 -o eth0 -j ACCEPT
-PostDown = iptables -D FORWARD -i eth0 -o wg0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-PostDown = iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
-
-[Peer]
-# Phone — replace with the actual phone public key
-PublicKey = <phone_public_key>
-AllowedIPs = 10.8.0.2/32
-
-[Peer]
-# Laptop — replace with the actual laptop public key
-PublicKey = <laptop_public_key>
-AllowedIPs = 10.8.0.3/32
-EOF
-sudo chmod 600 /etc/wireguard/wg0.conf
-
-# Replace eth0 with your actual outbound interface name
-# Check with: ip route show default
-
-# Enable IP forwarding (required for routing traffic through the server)
-echo "net.ipv4.ip_forward=1" | sudo tee /etc/sysctl.d/99-wireguard.conf
-sudo sysctl --system
-
-# Start WireGuard and enable on boot
-sudo wg-quick up wg0
-sudo systemctl enable wg-quick@wg0
-```
-
-## Client Configuration
-
-```bash
-# Generate a unique keypair for each client device
-# Run on the client, or on the server and transfer the private key securely — never in plaintext
-umask 077
-wg genkey | tee phone_private.key | wg pubkey > phone_public.key
-
-# Client config file (phone_wg0.conf):
-[Interface]
-PrivateKey = <phone_private_key>
-Address = 10.8.0.2/32
-DNS = 192.168.1.2                  # Optional: use Pi-hole for DNS over the tunnel
-
-[Peer]
-PublicKey = <server_public_key>
-Endpoint = your-home-ip.ddns.net:51820  # Your public IP or DDNS hostname
-AllowedIPs = 192.168.1.0/24            # Split tunnel: only home network traffic
-# AllowedIPs = 0.0.0.0/0, ::/0        # Full tunnel: all traffic through VPN
-
-PersistentKeepalive = 25              # Keep NAT hole open (required for mobile clients)
-```
-
-## Split Tunnel vs Full Tunnel
-
-```
-# Split tunnel: AllowedIPs = 192.168.1.0/24
-  Only traffic destined for your home network goes through the VPN.
-  Internet traffic (YouTube, Spotify) goes directly — better performance on mobile.
-  Best for: "I just want to reach my NAS and Pi from anywhere."
-
-# Full tunnel: AllowedIPs = 0.0.0.0/0, ::/0
-  ALL traffic goes through your home internet connection.
-  Useful for: piggybacking home DNS/Pi-hole ad blocking.
-  Downside: home upload speed becomes your bottleneck everywhere.
-
-# Multi-subnet split tunnel (most common homelab use case):
-  AllowedIPs = 192.168.10.0/24, 192.168.20.0/24, 192.168.30.0/24, 10.8.0.0/24
-  Routes all your VLANs through the tunnel; internet stays direct.
-```
-
-## Key Generation and Peer Management
-
-```python
-import subprocess
-
-def generate_keypair() -> tuple[str, str]:
-    """Generate a WireGuard keypair. Returns (private_key, public_key)."""
-    private = subprocess.check_output(["wg", "genkey"]).decode().strip()
-    public = subprocess.run(
-        ["wg", "pubkey"], input=private.encode(), capture_output=True
-    ).stdout.decode().strip()
-    return private, public
-
-def generate_preshared_key() -> str:
-    return subprocess.check_output(["wg", "genpsk"]).decode().strip()
-
-def build_client_config(
-    client_private_key: str,
-    client_vpn_ip: str,       # e.g. "10.8.0.3"
-    server_public_key: str,
-    server_endpoint: str,     # e.g. "home.example.com:51820"
-    allowed_ips: str = "192.168.1.0/24",
-    dns: str = "",
-) -> str:
-    dns_line = f"DNS = {dns}\n" if dns else ""
-    return f"""[Interface]
-PrivateKey = {client_private_key}
-Address = {client_vpn_ip}/32
-{dns_line}
-[Peer]
-PublicKey = {server_public_key}
-Endpoint = {server_endpoint}
-AllowedIPs = {allowed_ips}
-PersistentKeepalive = 25
-"""
-
-def build_server_peer_block(
-    client_public_key: str,
-    client_vpn_ip: str,
-    comment: str = "",
-) -> str:
-    comment_line = f"# {comment}\n" if comment else ""
-    return f"""
-{comment_line}[Peer]
-PublicKey = {client_public_key}
-AllowedIPs = {client_vpn_ip}/32
-"""
-```
-
-Keep private keys out of source control. If you use this script, write key material
-to files with mode 600 and never log or print it.
-
-## pfSense / OPNsense WireGuard
-
-```
-# pfSense: VPN → WireGuard → Add Tunnel
-  Interface Keys: Generate (creates keypair automatically)
-  Listen Port: 51820
-  Interface Address: 10.8.0.1/24
-
-# Add Peer (one per client):
-  Public Key: <client public key>
-  Allowed IPs: 10.8.0.2/32
-
-# Assign the WireGuard interface:
-  Interfaces → Assignments → Add (select wg0)
-  Enable interface, no IP needed (it is set in the tunnel config)
-
-# Firewall rules:
-  WAN → Allow UDP port 51820 inbound (so clients can reach the server)
-  WireGuard interface → Allow traffic to LAN networks you want reachable
-```
-
-## DDNS (Dynamic DNS) for Home Servers
-
-Most home internet connections have a dynamic IP. Use DDNS so your VPN endpoint
-stays reachable after an IP change.
-
-```bash
-# Option 1: Cloudflare DDNS — store credentials in a secrets file, not inline
-# docker-compose entry using an env file:
-  ddns-updater:
-    image: qmcgaw/ddns-updater
-    env_file: ./ddns.env   # store zone_id and token here, not in compose
-    restart: unless-stopped
-
-# ddns.env (chmod 600, not committed to git):
-# SETTINGS_CLOUDFLARE_ZONE_ID=your_zone_id
-# SETTINGS_CLOUDFLARE_TOKEN=your_api_token
-
-# Option 2: DuckDNS (free, simple)
-  Sign up at duckdns.org → get a token and subdomain (myhome.duckdns.org)
-  Store token in /etc/ddns.env (mode 600), then use a small root-owned script:
-
-  # /usr/local/bin/update-duckdns
-  #!/bin/sh
-  set -eu
-  . /etc/ddns.env
-  curl --fail --silent --show-error --max-time 10 \
-    --get "https://www.duckdns.org/update" \
-    --data-urlencode "domains=myhome" \
-    --data-urlencode "token=${DUCKDNS_TOKEN}" \
-    --data-urlencode "ip="
-
-  # Cron job:
-  */5 * * * * /usr/local/bin/update-duckdns >/dev/null 2>&1
-```
-
-## Troubleshooting
-
-```bash
-# Check WireGuard status and last handshake
-sudo wg show
-
-# If "latest handshake" is never or very old, the tunnel is not connected.
-# Check:
-# 1. Is UDP port 51820 open on the router/firewall?
-sudo ufw status  # or check pfSense/UniFi firewall rules
-
-# 2. Is the server public key in the client config correct?
-sudo wg show wg0 public-key   # Compare to what is in the client config
-
-# 3. Is IP forwarding enabled on the server?
-cat /proc/sys/net/ipv4/ip_forward  # Should be 1
-
-# 4. Does the client AllowedIPs cover the IP you are trying to reach?
-# If AllowedIPs = 192.168.1.0/24 and you are trying to reach 192.168.3.5, it will not route.
-
-# Check kernel logs for WireGuard errors
-dmesg | grep wireguard
-
-# Restart WireGuard
-sudo wg-quick down wg0 && sudo wg-quick up wg0
-```
-
-## Anti-Patterns
-
-```
-# BAD: Storing private keys in version control or sharing them
-# Private keys are equivalent to passwords — never commit them to git
-
-# BAD: Using AllowedIPs = 0.0.0.0/0 on mobile without considering the impact
-# Full tunnel routes all mobile traffic through your home upload — usually slow
-
-# BAD: Not setting PersistentKeepalive on mobile clients
-# Mobile clients behind NAT drop idle tunnels without it
-
-# BAD: Opening port 51820 in the firewall but forgetting IP forwarding on the server
-# Tunnel connects but no traffic routes — confusing to debug
-
-# BAD: Sharing a keypair across multiple client devices
-# Each device must have its own unique keypair — shared keys break the security model
-
-# BAD: Using a broad "FORWARD ACCEPT" iptables rule
-# Scope forwarding rules to the wg0 interface and direction only
-```
-
-## Best Practices
-
-- Generate a unique keypair per client device — never reuse keys
-- Use split tunneling (`AllowedIPs = <home subnets>`) for mobile
-- Set `PersistentKeepalive = 25` on all mobile clients
-- Use DDNS if your ISP assigns a dynamic IP; store credentials in env files, not inline
-- Use scoped iptables forwarding rules (inbound on wg0 only) rather than a blanket FORWARD ACCEPT
-- Add Pi-hole's IP as `DNS =` in client configs to get ad blocking over the VPN
-- Rotate the server keypair periodically and update all client configs
-
-## Related Skills
-
-- homelab-network-setup
-- homelab-vlan-segmentation
-- homelab-pihole-dns

package/prisma/skills/hookify-rules/SKILL.md

@@ -1,128 +0,0 @@
----
-name: hookify-rules
-description: This skill should be used when the user asks to create a hookify rule, write a hook rule, configure hookify, add a hookify rule, or needs guidance on hookify rule syntax and patterns.
----
-
-# Writing Hookify Rules
-
-## Overview
-
-Hookify rules are markdown files with YAML frontmatter that define patterns to watch for and messages to show when those patterns match. Rules are stored in `.claude/hookify.{rule-name}.local.md` files.
-
-## Rule File Format
-
-### Basic Structure
-
-```markdown
----
-name: rule-identifier
-enabled: true
-event: bash|file|stop|prompt|all
-pattern: regex-pattern-here
----
-
-Message to show Claude when this rule triggers.
-Can include markdown formatting, warnings, suggestions, etc.
-```
-
-### Frontmatter Fields
-
-| Field | Required | Values | Description |
-|-------|----------|--------|-------------|
-| name | Yes | kebab-case string | Unique identifier (verb-first: warn-*, block-*, require-*) |
-| enabled | Yes | true/false | Toggle without deleting |
-| event | Yes | bash/file/stop/prompt/all | Which hook event triggers this |
-| action | No | warn/block | warn (default) shows message; block prevents operation |
-| pattern | Yes* | regex string | Pattern to match (*or use conditions for complex rules) |
-
-### Advanced Format (Multiple Conditions)
-
-```markdown
----
-name: warn-env-api-keys
-enabled: true
-event: file
-conditions:
-  - field: file_path
-    operator: regex_match
-    pattern: \.env$
-  - field: new_text
-    operator: contains
-    pattern: API_KEY
----
-
-You're adding an API key to a .env file. Ensure this file is in .gitignore!
-```
-
-**Condition fields by event:**
-- bash: `command`
-- file: `file_path`, `new_text`, `old_text`, `content`
-- prompt: `user_prompt`
-
-**Operators:** `regex_match`, `contains`, `equals`, `not_contains`, `starts_with`, `ends_with`
-
-All conditions must match for rule to trigger.
-
-## Event Type Guide
-
-### bash Events
-Match Bash command patterns:
-- Dangerous commands: `rm\s+-rf`, `dd\s+if=`, `mkfs`
-- Privilege escalation: `sudo\s+`, `su\s+`
-- Permission issues: `chmod\s+777`
-
-### file Events
-Match Edit/Write/MultiEdit operations:
-- Debug code: `console\.log\(`, `debugger`
-- Security risks: `eval\(`, `innerHTML\s*=`
-- Sensitive files: `\.env$`, `credentials`, `\.pem$`
-
-### stop Events
-Completion checks and reminders. Pattern `.*` matches always.
-
-### prompt Events
-Match user prompt content for workflow enforcement.
-
-## Pattern Writing Tips
-
-### Regex Basics
-- Escape special chars: `.` to `\.`, `(` to `\(`
-- `\s` whitespace, `\d` digit, `\w` word char
-- `+` one or more, `*` zero or more, `?` optional
-- `|` OR operator
-
-### Common Pitfalls
-- **Too broad**: `log` matches "login", "dialog" — use `console\.log\(`
-- **Too specific**: `rm -rf /tmp` — use `rm\s+-rf`
-- **YAML escaping**: Use unquoted patterns; quoted strings need `\\s`
-
-### Testing
-```bash
-python3 -c "import re; print(re.search(r'your_pattern', 'test text'))"
-```
-
-## File Organization
-
-- **Location**: `.claude/` directory in project root
-- **Naming**: `.claude/hookify.{descriptive-name}.local.md`
-- **Gitignore**: Add `.claude/*.local.md` to `.gitignore`
-
-## Commands
-
-- `/hookify [description]` - Create new rules (auto-analyzes conversation if no args)
-- `/hookify-list` - View all rules in table format
-- `/hookify-configure` - Toggle rules on/off interactively
-- `/hookify-help` - Full documentation
-
-## Quick Reference
-
-Minimum viable rule:
-```markdown
----
-name: my-rule
-enabled: true
-event: bash
-pattern: dangerous_command
----
-Warning message here
-```

package/prisma/skills/inherit-legacy-style/SKILL.md

@@ -1,157 +0,0 @@
----
-name: inherit-legacy-style
-description: Legacy-project style inheritance skill. Use when the user types /inherit-legacy-style, or when onboarding an AI coding agent onto a hand-written legacy project and you need to prevent "style drift" (the model imposing its pretrained mainstream idioms onto the project). Language- and framework-agnostic — it aligns meta-architecture only, not syntax. Once run, it becomes a behavioral constraint on all subsequent coding tasks. Do NOT use for pure research or one-off questions unrelated to code-style alignment.
-metadata:
-  origin: community
-allowed-tools: Read, Glob, Grep, Bash, Edit, Write, AskUserQuestion
----
-
-# Inherit Legacy Style
-
-Prevents AI code style drift in legacy projects by scanning the codebase for implicit conventions across 4 meta-architecture dimensions, resolving conflicts with the user one at a time, and crystallizing the consensus into an enforceable `.ai-style-rules.md`. Fully language- and framework-agnostic.
-
-## When to Activate
-
-- User types `/inherit-legacy-style`
-- User mentions onboarding AI onto a hand-written legacy project
-- User is worried about AI-generated code "drifting" from existing project conventions
-- User wants to extract and codify their project's implicit coding rules
-
-## When to Use
-
-Use this skill when you need to preserve legacy project style and prevent AI-generated style drift. See **When to Activate** above for trigger conditions.
-
-## Prerequisites
-
-- Git (recommended; non-Git projects fall back to file timestamps for incremental mode)
-- Read/Write access to the project root (generates `.ai-style-rules.md` and optionally `CLAUDE.md`)
-
-## Workflow
-
-### Step 0 — Auto-Detect Mode
-
-Silently check for `.ai-style-rules.md` at the project root:
-
-| File exists? | Mode |
-|---|---|
-| No | **Branch A — First-time Full-Scan** |
-| Yes | **Branch B — Incremental Sniff** |
-
-Announce the mode in one line and proceed — never ask the user to pick.
-
-### Branch A — First-time Full-Scan
-
-**1. Measure scale, pick a scanning tier**
-
-```bash
-git ls-files | grep -cE '\.(js|ts|jsx|tsx|vue|py|go|rs|java|kt|rb|php|cs|swift|c|cpp|h)$'
-```
-
-| Tier | Source files | Strategy |
-|---|---|---|
-| Small | ≲ 50 | Full close-read every source |
-| Medium | 50–500 | Infra layer = full read; business layer = sample 2–3 per dimension |
-| Large | ≳ 500 | Strict sampling + budget cap; `--stat` summary first, then targeted reads |
-
-**2. Scan along 4 dimensions**
-
-1. **File Anatomy** — in-file declaration order (imports → types → main logic → helpers → export)
-2. **State & Control Flow** — naming conventions for async state, pagination, flags
-3. **Infrastructure** — where cross-cutting utils live (interceptors, formatters, middleware)
-4. **Error Handling** — try/catch vs global interceptor vs Result return; null-check habits
-
-**3. Apply signal-threshold noise reduction**
-
-Before interrupting the user, evaluate signal strength:
-
-- **Weak signal** → auto-suppress: minority <5% AND count <10 → majority wins, minority goes to DONTs
-- **Strong signal** → grill: near-even split, or semantic fork on a core dimension
-- **Small-project exception**: sources ≲50, "3 vs 2" is NOT a majority → grill it
-
-**4. Resolve conflicts one at a time (Grilling Protocol)**
-
-For each strong-signal conflict, present exactly ONE question with 4 options:
-
-> Evidence: `pathA` uses style X, `pathB` uses style Y
-> WARNING: Risk: mixing both fractures the project style
-> Choose: `1` follow X  `2` follow Y  `3` this is evolution, update rules  `4` I have a new rule
-
-Suspend until the user answers, then proceed to the next conflict. Never stack questions.
-
-**5. Generate `.ai-style-rules.md`** with three mandatory sections:
-- **[Golden Files]** — real exemplar paths annotated with what they demonstrate
-- **[Naming & State-Control Rules]** — concrete, checkable conventions
-- **[DONTs]** — anti-patterns that must not propagate
-
-**6. Install the persistent hook**
-
-Ask the user for enforcement strength (use `AskUserQuestion`):
-
-| Option | Mechanism |
-|---|---|
-| **1** Soft hook (recommended) | Write `@.ai-style-rules.md` reference into project `CLAUDE.md` |
-| **2** Hard hook | Soft hook + `PreToolUse[Write\|Edit\|MultiEdit]` Hook in `settings.json` |
-| **3** No hook | Keep the rules file; user references manually |
-
-### Branch B — Incremental Sniff
-
-1. Read existing `.ai-style-rules.md`; if it has a commit fingerprint, `git diff <last_hash> HEAD --stat` to pinpoint delta
-2. Read recent Git changes (`git log -3 --stat` → inspect suspect files on demand)
-3. For oversized diffs (>hundreds of files): `--stat` summary only + sample the largest changes
-4. Compare new code against recorded rules → conflicts go through Grilling Protocol
-5. Append evolution log at the end of `.ai-style-rules.md` (never overwrite old rules)
-
-### Per-Turn Enforcement
-
-When `.ai-style-rules.md` is in context (loaded via CLAUDE.md), every code-writing task must open with a **compliance declaration** in the reasoning chain, naming the exemplar being followed and the DONTs being avoided.
-
-## How It Works
-
-This skill auto-detects whether it's a first-time or incremental run via `.ai-style-rules.md` presence:
-
-- **First-time (Branch A)** — Measures project scale, scans codebase across 4 meta-architecture dimensions (File Anatomy, State & Control Flow, Infrastructure, Error Handling), applies signal-threshold noise reduction to suppress weak conflicts, resolves strong-signal conflicts one-at-a-time with the user, generates `.ai-style-rules.md` with Golden Files / Naming Rules / DONTs, and offers optional enforcement hooks.
-- **Incremental (Branch B)** — Reads existing rules, checks recent Git diffs for new or conflicting patterns, runs the same one-at-a-time grilling protocol for any conflicts found, and appends evolution logs without overwriting existing rules.
-- **Per-Turn Enforcement** — When hooked via `CLAUDE.md`, every code-writing task opens with a compliance declaration naming the exemplar followed and the DONTs avoided.
-
-## Output Specification
-
-- `.ai-style-rules.md` at project root (with commit fingerprint + scale tier in header)
-- Optionally `CLAUDE.md` with `@.ai-style-rules.md` reference
-- Evolution logs appended as `### [YYYY-MM-DD] Style Evolution Log` entries
-
-## Anti-Patterns
-
-- FAIL: Do NOT skip the scale measurement step — sampling a 30-file project "starves" it; full-scanning a 5,000-file repo blows up
-- FAIL: Do NOT stack multiple conflict questions at once — grilling is strictly one-at-a-time
-- FAIL: Do NOT overwrite old rules in incremental mode — always append evolution logs
-- FAIL: Do NOT default to "hard hook" without asking — enforcement strength is the user's call
-- FAIL: Do NOT judge syntax or tech-stack quality — this skill aligns meta-architecture only
-- FAIL: Do NOT copy bugs from exemplar files — reuse structure, flag defects
-
-## Best Practices
-
-- Announce the detected mode (first-time vs incremental) and scale tier in one line before scanning
-- For large projects, read `--stat` summaries first, then targeted `Read` on suspect files
-- Let the signal threshold handle noise — a 843-vs-8 naming split should auto-resolve without user interruption
-- When in doubt about signal strength, lean toward asking
-- The CLAUDE.md soft hook (`@.ai-style-rules.md`) is usually sufficient; hard hook only if the user wants mechanical enforcement
-
-## Related Skills
-
-- `init` — initialize a new CLAUDE.md with codebase documentation
-- `code-review` — review diffs for correctness and style issues
-- `simplify` — review code for reuse and simplification opportunities
-
-## Examples
-
-1. **First-time onboarding**
-   - User: "Help me onboard AI to this older codebase without changing its style."
-   - Action: Run Branch A full-scan → measure scale → scan 4 dimensions → grill conflicts → generate `.ai-style-rules.md` → offer hook strength (soft/hard/none).
-
-2. **Incremental update after team changes**
-   - User: "We added a new module; keep existing style rules intact."
-   - Action: Run Branch B incremental sniff → compare Git deltas to recorded rules → grill any new conflicts → append evolution log without overwriting.
-
-3. **Enforcing DONTs via CLAUDE.md**
-   - User: "Make sure all new code stays consistent with the project's rules."
-   - Action: Soft hook installed → `.ai-style-rules.md` auto-loaded every session → every code-writing task opens with compliance declaration, reusing exemplar patterns and avoiding DONTs.