菜单
Create, list, manage, or troubleshoot systemd user-level services for CLI tools. Use when the user wants to run a command as a persistent background service, create a systemd unit, enable/disable/restart a user service, list running services, or check service status and logs.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Normalize a PRD-derived GitHub backlog into a strict native GitHub graph so Ralph can follow it deterministically. Audits every epic's acceptance criteria against its child tasks to find coverage gaps — AC items with no task are silent black holes that no agent will ever work on. Creates missing tasks, sharpens vague task AC, and wires everything with native sub-issues and `blockedBy` links. Use immediately after `grill-me`, `write-a-prd`, and `prd-to-issues`, or whenever a repo has PRD/epic/task issues still held together by prose instead of native links. Reach for this skill when the user wants Ralph to "just follow the graph", asks to clean up backlog hygiene, wants ordering or blockers wired correctly, mentions AC coverage gaps, or says the next task should be mechanically obvious even if they do not mention "hygiene" by name.
Work one GitHub implementation task from a PRD-derived backlog, test-first, then stop for review. Use whenever the user says "ralph", "run ralph", "do a ralph pass", "grab the next issue", "work the next issue", "pick up a task", "grind an issue", "knock out a ticket", or asks for a token-budget-conscious one-issue pass instead of a continuous autonomous loop. This version expects a structured native GitHub hierarchy with `kind:prd`, `kind:epic`, and `kind:task`, plus native sub-issues and blocker links, and it uses that graph to pick the next task deterministically. Do not trigger for PRD writing (`write-a-prd`), PRD decomposition (`prd-to-issues`), bulk issue triage, or requests that explicitly want multiple issues handled in one session.
Extract planning/grilling session content from Claude Code and opencode into committed markdown transcripts inside a repository's `.sessions/` directory, one file per session, so that long design conversations survive context resets, tool switches, and rate limits. Trigger when the user says `dump the session`, `export this chat`, `save the transcript`, `checkpoint this planning session`, `commit the grilling`, `I don't want to lose this conversation`, `resume where we stopped yesterday`, `how do I get the opencode session into git`, or anything that implies they want a durable, reviewable, git-tracked copy of an agent chat that currently lives only inside Claude Code's `~/.claude/projects/` JSONL files or opencode's sqlite DB. Also trigger when the user is fixing an existing dump script that seems to only export one session (classic data-loss bug), or when they want to add a new runtime to an existing dump setup. Agent-agnostic: works from any CLI/agent with shell + Python, as long as the source agent (Claud
Create or update a repo-backed skill that should live in this repository and be installed into `~/.agents/skills` and `~/.claude/skills` via `install.sh`. Use this instead of the generic `skill-creator` workflow whenever the user wants to add or edit a skill in this repo, wants to turn a workflow into a repo-backed skill here, mentions this skills repo or its installer, or names one of the repo-backed skills as the thing to change. If the target skill is ambiguous, confirm it before editing.
Reflect on the current session and propose durable improvements to any skills that would benefit from what was learned. Trigger whenever the user says `self evolve`, `self-evolve`, `/self-evolve`, `reflect on this chat`, `what did you learn`, `any skills to improve`, `anything to bake back into the skills`, `upgrade your skills`, or otherwise asks the agent to turn session experience into concrete skill edits. This is an experiential audit — it looks at what actually happened in this conversation (skills that were invoked, skills that should have been but were not, user corrections that revealed unwritten rules, mid-session patches that suggest repeatable failure modes, almost-skipped steps) and proposes edits to the skills that would prevent those failures next time. Do not invoke at the start of a conversation — there is nothing to reflect on yet. Best used after substantial work, or when the user has pushed back on behavior multiple times. Always proposes and waits for user sign-off; never silently edits.
Use the Claude CLI as a peer collaborator. Trigger whenever you are about to delegate work to another Claude instance, compare Opus vs Sonnet, decide whether to add `--dangerously-skip-permissions`, run parallel Claude CLI subtasks, or continue a Claude session with an explicit UUID. This skill defines the house rules for Claude coworker delegation: stay in the Opus/Sonnet frame, keep orchestration with the main agent, and use explicit session IDs for deterministic continuity.
| name | user-service |
| description | Create, list, manage, or troubleshoot systemd user-level services for CLI tools. Use when the user wants to run a command as a persistent background service, create a systemd unit, enable/disable/restart a user service, list running services, or check service status and logs. |
This machine (Arch Linux) uses systemd --user services to run CLI tools as persistent background processes. Services are managed per-user without requiring root.
All user service files live in:
~/.config/systemd/user/<service-name>.service
CLI tools are typically installed via mise. Always resolve the full path:
which <command>
This usually returns something like:
/home/thesobercoder/.local/share/mise/installs/node/<version>/bin/<command>
Always use the full absolute path in ExecStart — systemd user services don't load shell profiles, so PATH-dependent commands will fail silently.
Create ~/.config/systemd/user/<service-name>.service:
[Unit]
Description=<Service Name> Service
After=network-online.target
Wants=network-online.target
[Service]
ExecStart=<full-binary-path> <args>
Restart=on-failure
RestartSec=5
[Install]
WantedBy=default.target
Notes:
After=network-online.target ensures network is ready (important for web services)Restart=on-failure with RestartSec=5 provides automatic recoveryWantedBy=default.target starts the service on user loginTell the user to run:
systemctl --user daemon-reload && systemctl --user enable --now <service-name>.service
daemon-reload picks up the new unit file. enable --now both enables on boot and starts immediately.
If the service needs to be accessible from other devices on the LAN, use the lan-proxy skill after creating the service. The port convention is:
127.0.0.1:<internal-port> (prefix external port with 1)0.0.0.0:<external-port> to the internal port# Check status
systemctl --user status <service-name>
# View logs
journalctl --user -u <service-name> -f
# Restart
systemctl --user restart <service-name>
# Stop and disable
systemctl --user disable --now <service-name>
# List all user services
systemctl --user list-units --type=service --all
| Symptom | Cause | Fix |
|---|---|---|
(code=exited, status=203/EXEC) | Binary path wrong or not executable | Verify with which, use full path |
(code=exited, status=217/USER) | User directive in a user service | Remove User= line — user services already run as the user |
| Service stops after logout | Lingering not enabled | loginctl enable-linger thesobercoder |
| Service starts but port not listening | Wrong --port or bind address | Check with ss -tlnp | grep <port> |
systemctl --user disable --now <service-name>
rm ~/.config/systemd/user/<service-name>.service
systemctl --user daemon-reload
If the service was exposed via LAN proxy, also remove the Caddy config and firewall rules using the lan-proxy skill.