ask-forum: promote to a full skill + wire into skill-first routing
Add .claude/skills/ask-forum/SKILL.md (usage contract, correlation model, forum-only scope, access/permissions) and route to it from CLAUDE.md (skill-first covered domains) + SKILL_ROUTING.md, so sessions invoke the skill instead of hand-rolling the Discord API — the footgun that produced a broken background wait. Capture that footgun as memory feedback_background_task_no_ampersand (run_in_background, never a shell &). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -225,3 +225,5 @@
|
||||
- [Fire #dev-alerts for client/RMM work](feedback_fire_dev_alerts_for_client_work.md) — Howard+Mike watch #dev-alerts Discord for live visibility into what techs/sessions touch. Fire post-bot-alert.sh ([DEV]/[RMM]/[DEPLOY]/[GURURMM] prefix -> #dev-alerts) at the START of any RMM/Dev or active-client-machine action. No CLAUDE.md rule yet — this memory is the rule.
|
||||
- [M365 app: SharePoint needs CERT](reference_m365_app_sharepoint_rest_vs_graph.md) — SP app-only works via the CERT (get-token.sh <tenant> sharepoint); the secret gives "Unsupported app only token". Graph app-only uses the secret.
|
||||
- [EDR auto-isolates GuruRMM PowerShell](project_edr_rmm_autoisolation_fp.md) — Datto "Exfiltration Over HTTP" rule auto-isolates benign GuruRMM scripts fleet-wide (vwp-qbs 4h outage); watcher + narrow suppression deployed, policy fix pending Mike
|
||||
- [Background tasks — no shell `&`](feedback_background_task_no_ampersand.md) — with run_in_background:true, run the command in the foreground of the shell; adding `&`/`disown` forks + exits 0 instantly, orphaning a blocking wait so it never delivers (hit twice building ask-forum)
|
||||
- [ask-forum — human-in-the-loop via #ct-forum](../skills/ask-forum/SKILL.md) — ask a teammate a question in the private ct-forum Discord forum, get their human answer back in-session; forum-only, any human can answer, run the --wait as a proper background task
|
||||
|
||||
26
.claude/memory/feedback_background_task_no_ampersand.md
Normal file
26
.claude/memory/feedback_background_task_no_ampersand.md
Normal file
@@ -0,0 +1,26 @@
|
||||
---
|
||||
name: Background tasks — run_in_background only, never add a shell `&`
|
||||
description: When launching a long-running command as a background task (run_in_background:true), do NOT also append a shell `&`/`disown`/`nohup`. The shell forks the command and exits 0 immediately, orphaning it — a blocking wait then never delivers its result. Run it in the FOREGROUND of that shell; the harness does the backgrounding.
|
||||
type: feedback
|
||||
---
|
||||
|
||||
When you want a long-running command (e.g. `ask-forum.sh --wait`, a poll loop, a blocking
|
||||
watcher) to run in the background, use the Bash tool's **`run_in_background: true`** and run
|
||||
the command in the **foreground of that shell** — a bare `bash script.sh ...` with **no
|
||||
trailing `&`, no `disown`, no `nohup`**.
|
||||
|
||||
**Why:** appending `&` forks the command off inside the shell; the shell then reaches the
|
||||
end and exits **0 immediately**. The harness sees exit 0 and reports the task "completed"
|
||||
right away, while the forked process is orphaned (and often killed). A blocking `--wait`
|
||||
that was supposed to sit for minutes and deliver an answer instead returns nothing — its
|
||||
result is never captured or notified.
|
||||
|
||||
**How to apply:**
|
||||
- Background wait, CORRECT: `Bash(command="bash .claude/scripts/ask-forum.sh --wait <id> --timeout 1800", run_in_background=true)` — the wait truly blocks server-side, costs zero tokens while pending, and the harness pings you the instant it completes.
|
||||
- WRONG: `Bash(command="bash ... --wait ... &", run_in_background=true)` and `... & disown` — orphans the wait, "completes" instantly, no answer.
|
||||
- The two mechanisms are redundant: `run_in_background` IS the backgrounding. Never stack a shell `&` on top of it.
|
||||
|
||||
**Incident:** hit TWICE in one session (2026-07-08) building the [[ask-forum]] flow — each
|
||||
time the "background wait" for a Discord reply exited 0 instantly and never delivered the
|
||||
answer, which looked like the reply was lost and forced the user to manually prompt "did
|
||||
they answer?". Logged as `--friction` in `errorlog.md`. Related: [[ask-forum]].
|
||||
Reference in New Issue
Block a user