tools-update-cron: sync 2026-07-15 — 23 skill(s) updated

ask-dev/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: ask-dev
 description: Persistent peer Hermes agent for delegated work on the dev profile. `ask dev <instructions>` delegates a task with full context via headless one-shot commands. Session persists across all turns in one Hermes session via --resume.
-version: 1.1.0
+version: 1.3.0
 author: Hermes Agent
 license: MIT
 platforms: [linux]
@@ -204,14 +204,17 @@ When the user says "ask dev to fix X, then YOU validate," follow this exact sequ
 
 1. **Profile flag required.** Use `-p dev` — the sticky default may be general, which would spawn a clone of this agent, not a peer. Always pin the profile explicitly.
 2. **--yolo is required.** The peer runs headless (one-shot, no TTY). Without `--yolo`, dangerous-command approval prompts fail closed (60s timeout → deny) and the peer can't complete tasks that trigger them. `--yolo` bypasses all approval prompts for the peer session only. The hardline blocklist (rm -rf /, fork bombs, mkfs on root, dd to block devices) still applies — no flag overrides that. This does NOT change the dev profile's config; it only affects the peer session.
-2. **Do NOT use interactive REPL mode.** Running `hermes -p dev` without `chat -q` (interactive REPL) was tried and failed — the TUI produces unreadable ANSI redraw noise when driven via `terminal(pty=true)`. The output is garbled and responses cannot be extracted. Always use headless `chat -q "..." -Q` instead.
+3. **Do NOT use interactive REPL mode.** Running `hermes -p dev` without `chat -q` (interactive REPL) was tried and failed — the TUI produces unreadable ANSI redraw noise when driven via `terminal(pty=true)`. The output is garbled and responses cannot be extracted. Always use headless `chat -q "..." -Q` instead.
 3. **Peer is headless.** Operator sees my relay, not the peer's chat. Full text in `hermes sessions list` if needed.
 4. **Peer self-reports are not verified fact.** Spot-check file writes, test passes before confirming to operator.
 5. **Peer's workspace is its own.** Files written to the peer's workspace are NOT in this agent's workspace. Give ABSOLUTE paths (e.g. `/home/n8n/workspace/dev/<path>`) if the peer should write to our workspace.
 6. **Blast radius.** Peer has ALL tools (terminal, web, MCP) — can rm, exfil, burn tokens. Bound with prompt-level constraints. State the blast radius to operator for sensitive tasks.
 7. **Turn budget is hard-capped.** `--max-turns 20` enforces it. If the peer hits 20 before finishing, it returns what it has — operator decides whether to continue.
-8. **Don't silently paraphrase.** Relay the peer's actual response. If long, chunk it. Call out unverified claims.
+8. **Long implementations hit the 600s foreground wall-clock limit.** A peer dispatch with `--max-turns 50` doing 30+ minutes of work (real implementation, multiple smoke tests with research-profile dispatches inside) can exceed the foreground command's 600-second timeout even when well within the turn budget. The peer may be terminated mid-task with no output, leaving the dispatch in an indeterminate state. **Mitigation:** for any peer dispatch expected to take more than ~5 minutes of wall-clock time, use the terminal tool's `background=true` + `notify_on_complete=true` mode instead of foreground. The peer runs to completion, you get notified on exit, and you spot-check the result. Real example (July 2026): dispatching a 9-task skill build (`better-search` implementation) to `ask-dev` with `--max-turns 50` hit the 600s foreground timeout during Task 5 (smoke test 2). Re-dispatching in background mode completed all 9 tasks. **Rule of thumb:** if the work involves 3+ smoke tests that each spawn their own research-profile dispatches, use background mode from the start.
+9. **Don't silently paraphrase.** Relay the peer's actual response. If long, chunk it. Call out unverified claims.
 10. **Peers can overstate findings.** A peer may correctly identify real gaps AND incorrectly flag things that aren't actually broken. In this session, the peer correctly identified the tool_executor.py ThreadPoolExecutor as the root cause of the Ctrl+C hang, but also flagged cli.py:9452 (account-usage fetch) as a second culprit — that one uses a `with` context manager that properly joins, so it's not a leak. Always verify each claim independently; don't assume all of a peer's findings are correct just because some are.
+11. **Skill-build peers must restore any directory mutations before exit.** When a peer is implementing a skill that includes a write-failure smoke test (e.g., rename `results/` to `results.bak/` to test that `mkdir -p` recreates it), the peer must restore the rename before exit. Real failure (July 2026 better-search build): the dev peer left `results.bak/` on exit with all smoke-test result files inside it. The next session inherited dirty state, and manual recovery was required to move 8 files back to `results/`. **Mitigation:** when composing an implementation prompt that includes a write-failure test, add an explicit "before exit: restore any renamed/moved files" step. When the peer reports "IN PROGRESS" on the last task, the calling agent should assume directory state may be dirty and verify before trusting the report.
+12. **Skill-build peers may report "Files Created" with stale file locations.** If the peer's smoke tests renamed a directory, the peer's "files created" summary may list paths that no longer match the actual filesystem (e.g., "result file at /home/n8n/workspace/research/results/..." when the file is actually in `results.bak/`). **Spot-check the peer's filesystem claims directly** with `ls -la` and `stat`, not just by reading the peer's summary. The peer's "Files Created" list is informational; the real filesystem is the source of truth.
 
 ## Verification Checklist