القائمة
Triage a stalled aicoder-opencode server, dr-repo autopilot loop, or child tool process — decide whether it is working, waiting, blocked, or dead before signalling anything
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use when asked to work in a continuous loop until done or truly blocked. Orchestrates pickup, planning, TDD execution, implementation waves when needed, debugging side-chains, verification, and resume behavior.
Use before planning when a feature or change request is underspecified. Resolve high-impact ambiguity around scope, consumers, security, failure handling, and acceptance criteria before writing the implementation plan.
Use for both preparing work for review and responding to review feedback. Keep review evidence local, concrete, and scoped to the real contract. Verify technically before agreeing or changing code.
Use before implementation. Merge design discovery and plan writing into one DR-specific flow: identify the consumer, inspect the repo, debate boundaries with partner and combatant, and produce an execution-ready plan that hands off cleanly into DR-native tasks, TDD, and implementation waves.
Use for the last mile: rerun verification, inspect diffs, commit or push if requested, and perform local docker-compose checks when needed. This is the DR local-tools replacement for MCP-style finish/deploy carryovers.
Use after planning and before implementation when you need a concrete, dependency-ordered task list. Turn the DR feature spec and plan into independently testable task slices with exact file paths and verification commands.
| name | diagnose-stuck |
| description | Triage a stalled aicoder-opencode server, dr-repo autopilot loop, or child tool process — decide whether it is working, waiting, blocked, or dead before signalling anything |
| user-invocable | true |
| models | ["ollama-cloud/kimi-k2-thinking","ollama-cloud/glm-5.1","ollama-cloud/minimax-m2.7"] |
| routing_role | maintenance |
| routing_complexity | small |
Triage a suspected stuck agent, autopilot loop, opencode server, or child tool process. Answer one question first:
Diagnose before killing. Reflexive kill -9 destroys session state, loses the resumable session-id, and leaves stale lock files that block the next autopilot cycle.
run.lock and the next cycle refuses to startRun top-to-bottom. Stop at the first check that fully explains the symptom.
Paths below use $REPO for the control-plane repo root (/home/mhugo/code/aicoder-opencode on this host). Substitute your own checkout if different.
Identify parent and children. Never assume the top-level opencode PID is the one stuck — it is usually a child tool.
pgrep -a -f opencode
pgrep -a -f 'dr-maintenance-autonomous'
ps -axo pid=,ppid=,pcpu=,rss=,etime=,state=,comm=,command= | grep -E '(opencode|autopilot|aicoder)' | grep -v grep
pgrep -lP <suspect_pid>
Process state column (first char only; ignore +, s, <):
R running · S sleeping (normal idle) · D uninterruptible sleep (I/O hang) · T stopped (stray Ctrl+Z) · Z zombie (parent not reaping)One sample lies. Take two, one second apart.
ps -p <pid> -o pid=,pcpu=,rss=,state= ; sleep 1 ; ps -p <pid> -o pid=,pcpu=,rss=,state=
S → waiting on I/O or model stream (probably fine)Only if the process looks network-bound or file-bound.
lsof -p <pid> 2>/dev/null | head -50
ss -tnp 2>/dev/null | grep <pid>
Look for an ESTABLISHED socket to a model provider (ollama-cloud, iflowcn, openrouter) — if present and in state 2 above, it is waiting on a model stream, not hung.
Autopilot state and run logs:
ls -lt $REPO/targets/dr-repo/overlay/.opencode/state/autopilot/
tail -100 $REPO/targets/dr-repo/overlay/.opencode/state/autopilot/status.json
Opencode server logs for the repo the suspect belongs to (check whichever server is attached):
ls -lt $REPO/targets/dr-repo/overlay/.opencode/xdg-state/
ls -lt $REPO/targets/dr-repo/overlay/.opencode/xdg-cache/
The last few hundred lines usually show the tool call that did not return.
ls -l $REPO/targets/dr-repo/overlay/.opencode/state/autopilot/run.lock
cat $REPO/targets/dr-repo/overlay/.opencode/state/autopilot/run.lock
A lock file whose recorded PID no longer exists in ps is stale. Stale locks block the next timer cycle and are the most common "autopilot silently stopped running" cause.
If an interactive opencode session exposes a tool-approval prompt and nothing answers it, the worker will sit at 0% CPU forever. Check the opencode portal / TUI for a pending approval before assuming the process is dead. Autonomous agents should not hit this — if one did, the agent is misconfigured (user-invocable path instead of autonomous path).
Act only after the checks above identify a category.
rm $REPO/targets/dr-repo/overlay/.opencode/state/autopilot/run.lock
kill -TERM <child_pid> # wait 5s
kill -KILL <child_pid> # only if TERM was ignored
kill -TERM <pid> ; sleep 5 ; kill -0 <pid> 2>/dev/null && kill -KILL <pid>
Z state) → the parent is the bug. Find ppid, restart the parent.cp $REPO/targets/dr-repo/overlay/.opencode/state/autopilot/status.json /tmp/autopilot-status.backup
# stop the repo-specific opencode server, then restart via its bin shim
$REPO/targets/dr-repo/overlay/.opencode/bin/dr-maintenance-autonomous-start
kill -9 on an opencode worker loses the resumable session.kill -9 as the first action. Always SIGTERM first, wait, verify, then escalate.run.lock without confirming the recorded PID is gone from ps.control-plane-maintenance-base Autopilot continuation rules before restarting — a second runner must not race the first.kill -9 on any opencode or autopilot PIDrun.lock while its PID is still alive