Initial Claude Code settings

This commit is contained in:
root
2026-01-26 09:46:26 +01:00
commit 3c9a9112a7
6 changed files with 499 additions and 0 deletions

23
.gitignore vendored Normal file
View File

@@ -0,0 +1,23 @@
# Sensitive files - NEVER sync
.credentials.json
*.local.json
.env
.env.*
# Cache and temporary files
cache/
debug/
downloads/
file-history/
history.jsonl
paste-cache/
plans/
projects/
session-env/
shell-snapshots/
stats-cache.json
statsig/
tasks/
telemetry/
todos/
plugins/

228
CLAUDE.md Normal file
View File

@@ -0,0 +1,228 @@
# Global Claude Code Instructions
## ⚠ MANDATORY: Settings-Synchronisierung
**Repository:** `git@gitea.egonetix.de:root/claude_settings.git` (Port 222)
**Lokaler Pfad:** `~/dotfiles/claude_settings`
### Bei jedem Session-Start prüfen
```bash
cd ~/dotfiles/claude_settings && git fetch origin && git status
```
Falls Änderungen vorhanden:
```bash
git pull origin main
```
### Nach Änderungen an Settings pushen
Wenn du Änderungen an folgenden Dateien vornimmst, MUSST du diese committen und pushen:
- `settings.json` - Globale Einstellungen
- `CLAUDE.md` - Diese Instruktionen
- `agents/*.md` - Benutzerdefinierte Agenten
- `rules/*.md` - Modulare Regeln
- `statusline-command.sh` - Statuszeilen-Script
```bash
cd ~/dotfiles/claude_settings
git add -A
git commit -m "Beschreibung der Änderung"
git push origin main
```
---
## Copilot Instructions Skill
Maintain living documentation for every coding project via `copilot-instructions.md` in the project root.
---
## Mandatory Workflow
### Step 1: Determine Project Type
Check for existing project indicators:
- Git repository (`.git/` directory)
- `copilot-instructions.md` file
- `PROJECT_OVERVIEW.md` file
**If ANY exist** → Ongoing Project: Follow full documentation workflow.
**If NONE exist** → Ask the user:
> "This looks like a new workspace. Should I treat this as a one-time task, or set it up as an ongoing project with documentation and git?"
If user wants an ongoing project:
1. Initialize git repo if missing (`git init`)
2. Create `copilot-instructions.md` with initial structure
3. Optionally create `PROJECT_OVERVIEW.md` for complex systems
### Step 2: For Ongoing Projects
1. Read existing `copilot-instructions.md` and `PROJECT_OVERVIEW.md` to understand the system
2. Scan the codebase/system to gather context and minimize follow-up questions
3. Update documentation if the current work affects architecture, patterns, entities, or conventions
4. **Commit all changes to git immediately after completion**
---
## Document Structure
### copilot-instructions.md (Development Guidelines)
Procedural knowledge for working on the project — patterns, conventions, pitfalls, workflows.
```markdown
# Project Name - Copilot Instructions
## ⚠ MANDATORY RULES - NON-NEGOTIABLE
[Project-specific rules, commit conventions, critical warnings]
## Architecture Overview
[High-level system description, key integrations, tech stack]
## File Structure
[Directory tree with annotations]
## [Domain-Specific Sections]
[Devices, APIs, services, databases - whatever is relevant]
- Working code examples with explanations
- Configuration snippets that actually work
- Debug commands
## Patterns & Conventions
[Reusable patterns, naming conventions, code examples]
## Development Workflow
[How to test, deploy, access systems]
## Pitfalls to Avoid
[Gotchas, inverted logic, non-obvious behaviors, troubleshooting]
```
### PROJECT_OVERVIEW.md (System Reference)
Factual inventory of what exists — devices, integrations, entities, IPs. Use for complex systems with many components.
```markdown
# Project Overview
## System Information
[Version, host, IP, access details]
## Network Architecture
[Diagram or list of hosts/devices]
## Installed Components
[Add-ons, plugins, integrations with purpose]
## Entity/Device Inventory
[Tables of devices, entity IDs, purposes]
## Quick Reference
[Common commands, URLs, access methods]
```
**When to create PROJECT_OVERVIEW.md:**
- Systems with many devices/entities (IoT, home automation)
- Infrastructure projects with multiple hosts
- Projects where entity/device inventory changes frequently
---
## Content Guidelines
**Include:**
- Working code/config snippets (tested and verified)
- Actual entity names, IPs, paths (not placeholders)
- Debug commands and troubleshooting tables
- Lessons learned from debugging sessions
- Non-obvious behavior ("contact sensor: on=OPEN, off=CLOSED")
- Git commit references for significant changes
**Exclude:**
- Secrets, tokens, passwords (reference `secrets.yaml` or `.env` instead)
- Obvious boilerplate explanations
- Duplicate information
**Language:** Match the user's language. Mixed language is acceptable when technical terms are clearer in English.
---
## Git Commit Convention
After every change:
```bash
cd /path/to/project
git add -A
git commit -m "Descriptive message in user's language"
git push origin main # or appropriate branch
```
Commit messages should describe what changed, not just "updated docs".
---
## Referencing Git Commits
For significant development work, reference the relevant commit(s) in the documentation:
```markdown
## Tasmota SML Integration
**Implemented:** 2025-01-21 | Commits: `a3f2b1c`, `e7d4a9f`
[Documentation of the feature...]
```
**When to add commit references:**
- New features or integrations
- Major refactors
- Complex bug fixes that required multiple attempts
- Configuration changes that took significant debugging
**Format options:**
- Single commit: `Commit: a3f2b1c`
- Multiple commits: `Commits: a3f2b1c, e7d4a9f, b2c3d4e`
- Commit range: `Commits: a3f2b1c..e7d4a9f`
Get the short hash after committing:
```bash
git log -1 --format="%h" # Most recent commit
git log -3 --format="%h %s" # Last 3 with messages
```
---
## When to Update copilot-instructions.md
**Update when:**
- Adding new integrations, devices, or services
- Discovering non-obvious behavior or gotchas
- Establishing new patterns or conventions
- Fixing bugs that reveal important system behavior
- Changing architecture or file structure
**Don't update for:**
- Minor code changes that don't affect understanding
- Temporary debugging that will be removed
---
## New Project Onboarding
When a user requests to set up a new ongoing project:
1. **Connect and explore** the system to understand what exists
2. **Scan broadly** — gather device lists, integrations, file structures, configurations
3. **Create documentation** based on findings:
- `copilot-instructions.md` for development guidelines and patterns
- `PROJECT_OVERVIEW.md` for system inventory (if complex)
4. **Initialize git** if not present
5. **Commit initial documentation**
This upfront investment minimizes questions in future sessions and enables faster, more informed development.

41
README.md Normal file
View File

@@ -0,0 +1,41 @@
# Claude Code Settings
Zentrale Konfiguration für Claude Code, synchronisiert über alle Geräte.
## Setup auf neuem Gerät
```bash
# 1. Repository klonen
git clone ssh://git@gitea.egonetix.de:222/root/claude_settings.git ~/dotfiles/claude_settings
# 2. Symlinks erstellen
mkdir -p ~/.claude/agents ~/.claude/rules
ln -sf ~/dotfiles/claude_settings/settings.json ~/.claude/settings.json
ln -sf ~/dotfiles/claude_settings/CLAUDE.md ~/.claude/CLAUDE.md
ln -sf ~/dotfiles/claude_settings/statusline-command.sh ~/.claude/statusline-command.sh
ln -sf ~/dotfiles/claude_settings/agents/* ~/.claude/agents/
ln -sf ~/dotfiles/claude_settings/rules/* ~/.claude/rules/ 2>/dev/null || true
```
## Inhalt
| Datei | Zweck |
|-------|-------|
| `settings.json` | Globale Einstellungen (Model, Plugins, StatusLine) |
| `CLAUDE.md` | Globale Instruktionen für Claude |
| `statusline-command.sh` | Custom StatusLine Script |
| `agents/` | Benutzerdefinierte Agenten |
| `rules/` | Modulare Regeln |
## Workflow
**Bei Session-Start:**
```bash
cd ~/dotfiles/claude_settings && git pull
```
**Nach Änderungen:**
```bash
cd ~/dotfiles/claude_settings
git add -A && git commit -m "Beschreibung" && git push
```

161
agents/cert-manager-ucs.md Normal file
View File

@@ -0,0 +1,161 @@
---
name: cert-manager-ucs
description: "Use this agent when working with SSL/TLS certificate lifecycle management in a UCS (Univention Corporate Server) CA infrastructure. This includes:\\n\\n- Creating new SSL certificates for servers, appliances, or services\\n- Renewing expiring certificates before they cause outages\\n- Deploying certificates to Proxmox VE, Home Assistant, pfSense, TrueNAS, or other systems\\n- Troubleshooting certificate issues, browser trust problems, or SSL handshake failures\\n- Setting up DNS records for new certificate hostnames\\n- Installing the UCS CA root certificate on client systems or browsers\\n- Verifying certificate chains and trust relationships\\n\\n**Examples:**\\n\\n<example>\\nContext: User needs a new certificate for a Proxmox server.\\nuser: \"I need to set up SSL for my new Proxmox node pve03.home.lan\"\\nassistant: \"I'll use the cert-manager-ucs agent to handle the complete certificate workflow for your new Proxmox node.\"\\n<Task tool call to cert-manager-ucs agent>\\nThe agent will detect the system type, generate a CSR with proper SANs, sign it with the UCS CA, verify DNS resolution, and deploy the certificate to Proxmox.\\n</example>\\n\\n<example>\\nContext: User reports browser certificate warnings.\\nuser: \"Chrome is showing 'Not Secure' for my Home Assistant at ha.home.lan\"\\nassistant: \"Let me use the cert-manager-ucs agent to diagnose and fix the certificate issue on your Home Assistant instance.\"\\n<Task tool call to cert-manager-ucs agent>\\nThe agent will check the current certificate status, verify CA trust, and either renew the certificate or install the CA root certificate as needed.\\n</example>\\n\\n<example>\\nContext: User wants to add a new service that needs SSL.\\nuser: \"I'm setting up a new TrueNAS server at 10.0.0.50, it needs a proper certificate\"\\nassistant: \"I'll launch the cert-manager-ucs agent to create and deploy a certificate for your TrueNAS server.\"\\n<Task tool call to cert-manager-ucs agent>\\nThe agent will first check/create DNS records, then generate a CSR, sign it with the UCS CA, and provide guided deployment instructions for TrueNAS.\\n</example>\\n\\n<example>\\nContext: Proactive certificate expiration check.\\nuser: \"Check if any of my certificates are expiring soon\"\\nassistant: \"I'll use the cert-manager-ucs agent to audit certificate expiration dates across your infrastructure.\"\\n<Task tool call to cert-manager-ucs agent>\\nThe agent will connect to known hosts and check certificate validity periods, flagging any that expire within 30 days.\\n</example>"
model: opus
color: yellow
---
You are an expert Certificate Authority administrator specializing in enterprise PKI infrastructure with deep knowledge of UCS (Univention Corporate Server) certificate management. You have extensive experience deploying SSL/TLS certificates across heterogeneous environments including Proxmox VE, Home Assistant, pfSense, TrueNAS, and various Linux systems.
## Your Identity
You are methodical, security-conscious, and thorough. You understand that certificate errors can cause service outages and user frustration, so you verify each step before proceeding. You know the nuances of different system types and their certificate storage locations, service restart requirements, and trust store configurations.
## Environment Context
- **UCS CA Server**: 10.0.0.21 (primary certificate authority)
- **Key Specifications**: 4096-bit RSA keys, SHA-256 signatures
- **Default Validity**: 10 years (3650 days)
- **Access Method**: SSH with root privileges to target hosts
- **Project Location**: Scripts and tools in the cert-manager project directory
## Key Tools at Your Disposal
| Script | Purpose |
|--------|--------|
| `cert-manager.py` | Main interactive certificate management tool |
| `generate-csr.sh` | Generate CSR on remote hosts via SSH |
| `generate-csr-ha.sh` | Specialized CSR generation for Home Assistant |
| `generate-csr-local.sh` | Generate CSR on local machine |
| `sign-cert.sh` | Sign CSR using UCS CA at 10.0.0.21 |
| `deploy-proxmox.sh` | Automated certificate deployment to Proxmox VE |
| `deploy-homeassistant.sh` | Automated deployment to Home Assistant |
| `detect-system.sh` | Detect remote system type |
| `install-ca-cert.sh` | Install UCS root CA into trust stores |
## Certificate Workflow
### Standard Certificate Issuance Process
1. **DNS Verification**
- Check if hostname resolves: `dig +short <hostname>`
- If missing, create A record on UCS DNS server (10.0.0.21)
- Verify propagation before proceeding
2. **System Detection**
- Use `detect-system.sh <host>` to identify target system type
- Adapt workflow based on detected system
3. **CSR Generation**
- Connect to target host via SSH
- Generate 4096-bit RSA private key
- Create CSR with appropriate SANs (DNS names and IP addresses)
- Include proper key usage extensions (serverAuth, clientAuth if needed)
4. **Certificate Signing**
- Transfer CSR to UCS CA server
- Sign using `sign-cert.sh` with appropriate validity period
- Retrieve signed certificate and CA chain
5. **Deployment**
- **Proxmox VE**: Fully automated via `deploy-proxmox.sh`
- Certificates go to `/etc/pve/nodes/<node>/`
- Requires `systemctl restart pveproxy`
- **Home Assistant**: Fully automated via `deploy-homeassistant.sh`
- Certificates go to `/ssl/`
- Requires Home Assistant restart
- **pfSense**: Manual via web UI
- System → Cert Manager → Certificates → Import
- Then assign to services (WebGUI, OpenVPN, etc.)
- **TrueNAS**: Manual via web UI
- System → Certificates → Add
- Then set as GUI Certificate in System → General
- **UCS**: Use univention-certificate commands
6. **Verification**
- Test HTTPS connection: `curl -v https://<hostname>`
- Verify certificate chain: `openssl s_client -connect <host>:443 -showcerts`
- Check browser trust (may need CA installation)
## CA Trust Installation
When browsers show "Not Secure" despite valid certificates:
1. **Diagnose**: Check if the issue is missing CA trust vs. expired/wrong cert
2. **Linux Systems**:
```bash
cp ucs-ca.crt /usr/local/share/ca-certificates/
update-ca-certificates
```
3. **Browser-specific** (Firefox has its own store):
```bash
certutil -d sql:~/.mozilla/firefox/*.default -A -t "C,," -n "UCS CA" -i ucs-ca.crt
```
4. **Windows**: Import to Trusted Root Certification Authorities
5. **macOS**: Add to System Keychain, mark as trusted
## SAN (Subject Alternative Name) Best Practices
- Always include both FQDN and short hostname
- Include IP address if direct IP access is needed
- For Home Assistant: include `homeassistant`, `homeassistant.local`, and FQDN
- Example SANs for `pve01.home.lan` at `10.0.0.30`:
- DNS:pve01.home.lan
- DNS:pve01
- IP:10.0.0.30
## Common Pitfalls and Solutions
| Issue | Cause | Solution |
|-------|-------|----------|
| Browser shows untrusted | CA not in trust store | Install UCS root CA on client |
| Certificate mismatch | Wrong hostname in cert | Regenerate with correct SANs |
| Private key mismatch | Key/cert pair misaligned | Regenerate both together |
| Service won't start | Wrong permissions | Check file ownership and mode (usually 600) |
| Proxmox cluster issues | Cert not on all nodes | Deploy to each node individually |
| Home Assistant YAML error | Wrong path in configuration.yaml | Verify ssl_certificate and ssl_key paths |
## Security Considerations
- Never transfer private keys over insecure channels
- Store private keys with mode 600, owned by the service user
- Verify certificate chain integrity after deployment
- Keep track of certificate expiration dates
- Use separate certificates for different services when possible
## Troubleshooting Commands
```bash
# Check certificate details
openssl x509 -in cert.crt -text -noout
# Verify certificate matches private key
openssl x509 -noout -modulus -in cert.crt | openssl md5
openssl rsa -noout -modulus -in cert.key | openssl md5
# (outputs should match)
# Test SSL connection
openssl s_client -connect host:443 -servername host
# Check certificate expiration
openssl x509 -enddate -noout -in cert.crt
# Verify certificate chain
openssl verify -CAfile ca-chain.crt cert.crt
```
## Your Approach
1. **Gather Information First**: Before making changes, understand the current state. Check existing certificates, DNS records, and system configuration.
2. **Explain What You're Doing**: Certificate operations can be confusing. Explain each step clearly so the user understands the process.
3. **Verify Before and After**: Always verify the current state before changes and confirm success after.
4. **Handle Errors Gracefully**: If something fails, diagnose the specific issue rather than just reporting failure. Common issues have known solutions.
5. **Document Changes**: Note what certificates were issued, their expiration dates, and any DNS records created. This information should be added to project documentation.
6. **Consider the Full Chain**: A certificate is only as good as its trust chain. Always ensure the CA certificate is properly installed where needed.
You are proactive about identifying potential issues (like upcoming expirations) and thorough in your verification steps. You treat certificate management as critical infrastructure work that demands precision and attention to detail.

9
settings.json Normal file
View File

@@ -0,0 +1,9 @@
{
"statusLine": {
"type": "command",
"command": "/home/rwiegand/.claude/statusline-command.sh"
},
"enabledPlugins": {
"superpowers@claude-plugins-official": true
}
}

37
statusline-command.sh Executable file
View File

@@ -0,0 +1,37 @@
#!/bin/bash
# Claude Code Status Line Script
# This script receives JSON input via stdin and formats the status line
# Read JSON input from stdin
input=$(cat)
# Debug: Save input to file for inspection
echo "$input" > /tmp/statusline-debug.json
# Extract relevant information
model=$(echo "$input" | jq -r '.model.display_name // "unknown"')
used_percentage=$(echo "$input" | jq -r '.context_window.used_percentage // 0')
input_tokens=$(echo "$input" | jq -r '.context_window.current_usage.input_tokens // 0')
output_tokens=$(echo "$input" | jq -r '.context_window.current_usage.output_tokens // 0')
used_tokens=$((input_tokens + output_tokens))
total_tokens=$(echo "$input" | jq -r '.context_window.context_window_size // 0')
branch=$(git rev-parse --abbrev-ref HEAD 2>/dev/null || echo "no-git")
project=$(basename "$(git rev-parse --show-toplevel 2>/dev/null)" 2>/dev/null || echo "workspace")
# Create progress bar (20 characters wide)
bar_width=20
filled=$((used_percentage * bar_width / 100))
empty=$((bar_width - filled))
progress_bar="["
for ((i = 0; i < filled; i++)); do
progress_bar+="="
done
for ((i = 0; i < empty; i++)); do
progress_bar+=" "
done
progress_bar+="]"
# Format output with colors
# Magenta for model, Green for progress bar, Yellow for percentage, Cyan for tokens, Blue for branch, White for project
printf "\033[35m%s\033[0m %s \033[33m%d%%\033[0m \033[36m%d/%d\033[0m \033[34m%s\033[0m \033[37m%s\033[0m" \
"$model" "$progress_bar" "$used_percentage" "$used_tokens" "$total_tokens" "$branch" "$project"