Menu
Homelab dev workflow convention: work in ~/dev/, test there, get approval, then release using the project's own idioms. Tech-stack agnostic.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
Check health of the homelab-backup service — last run status, next scheduled run, R2 bucket contents, and local archive state. Quick mobile-friendly summary.
Delete a blog post or review from blog.carter2099.com. Soft-deletes the markdown file (moved to deleted/ directory) and destroys the database record.
Edit an existing blog post or review on blog.carter2099.com. Find by title/ID, show current content, collaboratively revise, preview changes, then update.
Create a new blog post on blog.carter2099.com. Collaboratively draft and polish markdown content, preview it, then publish — triggering subscriber email notifications via the Rails app.
Create a new review on blog.carter2099.com (Book, Movie, Show, Product, or Video Game). Collaboratively draft content, preview it, then publish — triggering subscriber email notifications via the Rails app.
Audit the homelab for outdated software and report findings. Use when user says "check for updates", "what's outdated", "audit the homelab", "run update check", or wants a system health report.
| name | dev-test-and-release |
| description | Homelab dev workflow convention: work in ~/dev/, test there, get approval, then release using the project's own idioms. Tech-stack agnostic. |
This skill establishes the standard workflow for implementing and shipping changes to any homelab project. It is tech-stack agnostic — Rails, Go, React, whatever.
~/dev/<repo> is the workspace. ~/<app>/ (e.g. ~/delta_neutral/, ~/blog/) is the deployment directory. Never do implementation work in the deployment directory.
# Clone if not already present
ls ~/dev/<repo> || git clone git@github.com:carter2099/<repo>.git ~/dev/<repo>
cd ~/dev/<repo>
git checkout main && git pull origin main
Install dependencies using the project's conventions (check AGENTS.md for the canonical command):
RBENV_VERSION=$(cat .ruby-version 2>/dev/null || echo 3.4.3) bundle installgo mod downloadnpm install or pnpm installImplement the change in ~/dev/<repo>. Read AGENTS.md for code quality rules, architecture patterns, and anything project-specific before touching code.
Run tests as you go using the project's test command (canonical source: AGENTS.md):
RBENV_VERSION=... bin/rakego test ./...npm testBefore asking for approval:
bin/rake for Rails).git diff --stat summary of what changed.Pause here. Present the changes and test results. Let the user review, request tweaks, or approve.
Do NOT push or release until the user explicitly approves.
Once the user approves, release using the project's own idioms — do not invent a generic release process. Check in this order:
/release skill). If yes, invoke it.AGENTS.md: Look for a "Versioning" or "Release" section with specific instructions.release.sh: Some repos have a release script — but confirm it's for the dev release (version bump + tag), not the deployment script.For dependency-only changes (bumps), use /dependabot-release instead of this skill.
Deployment is always a separate explicit step — never automatic after a release. If the user wants to deploy after releasing, use the deploy-app skill.
~/dev/<repo> clone is the source of truth for development. The deployment directory (~/<app>/) is managed by release.sh pulling from origin — never edit files there directly..ruby-version requests an uninstalled Ruby version, use RBENV_VERSION=3.4.3 as an override for minor patch differences.