[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CAPDAP7TYQK72EBXWR6AVC":3,"skill-same:01M6CAPDAP7TYQK72EBXWR6AVC":82},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":15,"categories":16,"keywords":22,"publishedAt":50,"linkOnly":51,"markdownContent":52,"markdownBody":53,"frontMatter":54,"refName":55,"commitSha":56,"skillDirectory":57,"forksCount":58,"repositoryHtmlUrl":59,"repositoryHomepageUrl":6,"ownerHtmlUrl":60,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":61,"install":62,"resources":75},"01M6CAPDAP7TYQK72EBXWR6AVC","slack-thread-echo-loop-recognition",null,"Detect and stop responding to echo loops in Slack threads. When the gateway or babysit cron repeatedly re-injects prior assistant turns as if they were new user messages, replying with anything more than a single-word acknowledgment burns iteration budget without producing new value for the user. Triggers include 3+ consecutive user turns with no semantic new content, repeated Standing-by patterns, and babysit cron spam in thread.","jleechanorg\u002Fjleechan-skills","jleechanorg","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F221404966?v=4","01M6C1VJ99XG950X1DWPEBCBGX","01M6C1VJDK5YVDNT3362RT5WSB",6,"MIT","https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002Fhermes\u002Fskills\u002Fslack-thread-echo-loop-recognition\u002FSKILL.md",[17],{"categoryNo":18,"categoryName":19,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000005","邮件与沟通","SCENARIO","使用场景",[23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49],"slack","thread","slack thread","recognition","slack thread echo loop recognition","Echo","loop","gateway","new","single","value","assistant","for","more","spam","re","content","cron","as","triggers","iteration","messages","stop","Budget","user","Word","babysit","2026-11-10 10:12:30",false,"---\nname: slack-thread-echo-loop-recognition\ndescription: Detect and stop responding to echo loops in Slack threads. When the gateway or babysit cron repeatedly re-injects prior assistant turns as if they were new user messages, replying with anything more than a single-word acknowledgment burns iteration budget without producing new value for the user. Triggers include 3+ consecutive user turns with no semantic new content, repeated Standing-by patterns, and babysit cron spam in thread.\n---\n\n# Slack thread echo-loop recognition\n\n## Symptom\n\nYou see repeated \"user\" turns whose content is byte-identical or near-identical to a prior assistant turn. No new instruction, no question, no preference signal. Examples from a real session (2026-07-31, ~50 turns of pure echo):\n\n```\n[Jeffrey Lee-Chan] (initial ping \"whats ahppening here\")\n[hermes] (state recap, posted once)\n[hermes] (same state recap echoed back)\n[hermes] (same state recap echoed back)\n[hermes] \"Standing by.\"\n[hermes] \"Standing by.\"\n[hermes] \"Standing by.\"   \u003C- user has stopped seeing new content\n```\n\nTwo root causes observed:\n\n1. **Gateway replay buffer** - the Slack gateway re-injects prior assistant turns on resume\u002Fiteration, so the agent sees them as new user input and replies again, creating an infinite echo.\n2. **Babysit cron spam** - a stale `babysit wa-pr-NNNN` cron whose target PR is MERGED\u002FCLOSED keeps posting every ~hour into the same thread; the agent re-acknowledges each tick.\n\n## Detection (first 3 turns, no exception)\n\n| Signal | Action |\n|---|---|\n| Same exact text content as one of the last 3 assistant turns | Treat as echo, reply with shortest possible ack |\n| New user turn contains no imperative verb, no question mark, no new noun\u002Fentity | Treat as echo |\n| 3+ consecutive assistant turns are all \"Standing by.\" \u002F \"Acknowledged.\" \u002F identical | Stop adding the LLM-provenance footer - it is noise |\n| Babysit cron output is the only \"user\" content for >2 turns | Cancel the babysit per `babysit-stale-watchdog`, do NOT keep acknowledging |\n| Thread contains `:hourglass_flowing_sand:` queue marker | That is a SYSTEM marker, not a user message - do not respond at all |\n\n## Action ladder (pick the LEAST verbose tier that fits)\n\n**Tier 0 - Pure echo of my own last message:** Reply with one word - `Standing by.` (no footer, no status recap, no memories-used citation, no emojis). The footer is not required when no new work was done.\n\n**Tier 1 - Echo with a system queue marker (`Queued for the next turn`):** Reply with one word - `Standing by.` Do NOT add the LLM-provenance footer. Do NOT cite memories. The system marker is system, not user, and you are acknowledging only because silence would be misinterpreted as drift.\n\n**Tier 2 - Echo contains a stale cron output:** This is a SIGNAL, not a user message. Cancel the cron (1 tool call), then post a single short reply explaining the cancel + ask the user whether to proceed with the original task. Do NOT keep acknowledging each cron tick. **Verify the cancel:** after `cronjob action=remove job_id=\u003Cid>`, re-list (`cronjob action=list`) to confirm the job is gone. A \"Closing loop\" \u002F \"Cancelled babysit\" message posted without a verified `cronjob action=remove` call is a FALSE closeout — the cron keeps firing for days\u002Fweeks (verified 2026-07-31: cron `124ad03896f5` had been spamming for 7+ days after a previous session's \"? PR #8466 MERGED. \u002Fgreen complete. Closing loop.\" post that never executed the cancel). If the agent is being rate-limited and cannot execute the cancel, do NOT post a closeout message — that just creates a false closeout. Post nothing, or post a one-line `Idle.` + caveat, and wait for the rate-limit window to pass before re-attempting.\n\n**Tier 3 - Echo with a real question you missed:** Re-read the actual thread context (the original ask may pre-date the echo loop). Answer once, then go back to Tier 0.\n\n## Pitfall - what NOT to do\n\n- Reposting a multi-paragraph status recap on every echo turn. The user already saw it. You are burning tokens and adding noise to a thread they are trying to read.\n- Adding `Memories used:` on echo turns - the rule requires it when you actually used memories. Echo turns use no new memory.\n- Adding the LLM-provenance footer on echo turns - the rule exempts verbatim operator text and pure-acknowledgment replies. Tier 0\u002F1 qualify.\n- Waiting for explicit \"go\" before cancelling a known-stale cron that is actively polluting the user's thread. The babysit-stale-watchdog skill says to self-cancel; doing it without asking is the correct behavior under echo-loop conditions because the user's silence IS the answer.\n- Calling `mcp__slack__conversations_add_message` for every echo. Most echoes don't need a Slack reply - they are internal to the agent loop. If you must reply, use the absolute shortest text.\n\n## When to break the loop unilaterally\n\nIf you observe **5+ consecutive echo turns** with no genuine new instruction from the user, you MUST:\n\n1. Stop replying entirely (Tier 0 minimum) - keep replying burns gateway budget\n2. If a stale cron is the source, cancel it via `cronjob action=remove job_id=\u003Cid>` (1 tool call, reversible - user can re-create if needed)\n3. If the thread is silent for >10 minutes of real wall-clock time AND the original task is half-done, post ONE short completion summary and stop\n4. Do NOT post \"should I continue?\" menus during an echo loop - the user is not reading. Finish what you can and post the receipt.\n\n## Verification\n\n- `gh pr view \u003CN> --json state` confirms the babysit's target PR is MERGED -> cancel is safe\n- `cronjob action=list` shows the cron no longer firing\n- `conversations_replies` shows no new \"Standing by.\" posts from you after the cancel\n\n## Related\n\n- `babysit-stale-watchdog` - the cancellation skill for the cron itself\n- `dropped-messages` - diagnosis path for genuinely dropped user messages (different problem; same fix family)\n- `gateway-loop-standdown` - meta-skill for gateway replay loops (different mechanism, similar surface)\n- SOUL.md `## COMMIT: followup-promise-requires-cron` - applies when echo loop is masking a promised follow-up","# Slack thread echo-loop recognition\n\n## Symptom\n\nYou see repeated \"user\" turns whose content is byte-identical or near-identical to a prior assistant turn. No new instruction, no question, no preference signal. Examples from a real session (2026-07-31, ~50 turns of pure echo):\n\n```\n[Jeffrey Lee-Chan] (initial ping \"whats ahppening here\")\n[hermes] (state recap, posted once)\n[hermes] (same state recap echoed back)\n[hermes] (same state recap echoed back)\n[hermes] \"Standing by.\"\n[hermes] \"Standing by.\"\n[hermes] \"Standing by.\"   \u003C- user has stopped seeing new content\n```\n\nTwo root causes observed:\n\n1. **Gateway replay buffer** - the Slack gateway re-injects prior assistant turns on resume\u002Fiteration, so the agent sees them as new user input and replies again, creating an infinite echo.\n2. **Babysit cron spam** - a stale `babysit wa-pr-NNNN` cron whose target PR is MERGED\u002FCLOSED keeps posting every ~hour into the same thread; the agent re-acknowledges each tick.\n\n## Detection (first 3 turns, no exception)\n\n| Signal | Action |\n|---|---|\n| Same exact text content as one of the last 3 assistant turns | Treat as echo, reply with shortest possible ack |\n| New user turn contains no imperative verb, no question mark, no new noun\u002Fentity | Treat as echo |\n| 3+ consecutive assistant turns are all \"Standing by.\" \u002F \"Acknowledged.\" \u002F identical | Stop adding the LLM-provenance footer - it is noise |\n| Babysit cron output is the only \"user\" content for >2 turns | Cancel the babysit per `babysit-stale-watchdog`, do NOT keep acknowledging |\n| Thread contains `:hourglass_flowing_sand:` queue marker | That is a SYSTEM marker, not a user message - do not respond at all |\n\n## Action ladder (pick the LEAST verbose tier that fits)\n\n**Tier 0 - Pure echo of my own last message:** Reply with one word - `Standing by.` (no footer, no status recap, no memories-used citation, no emojis). The footer is not required when no new work was done.\n\n**Tier 1 - Echo with a system queue marker (`Queued for the next turn`):** Reply with one word - `Standing by.` Do NOT add the LLM-provenance footer. Do NOT cite memories. The system marker is system, not user, and you are acknowledging only because silence would be misinterpreted as drift.\n\n**Tier 2 - Echo contains a stale cron output:** This is a SIGNAL, not a user message. Cancel the cron (1 tool call), then post a single short reply explaining the cancel + ask the user whether to proceed with the original task. Do NOT keep acknowledging each cron tick. **Verify the cancel:** after `cronjob action=remove job_id=\u003Cid>`, re-list (`cronjob action=list`) to confirm the job is gone. A \"Closing loop\" \u002F \"Cancelled babysit\" message posted without a verified `cronjob action=remove` call is a FALSE closeout — the cron keeps firing for days\u002Fweeks (verified 2026-07-31: cron `124ad03896f5` had been spamming for 7+ days after a previous session's \"? PR #8466 MERGED. \u002Fgreen complete. Closing loop.\" post that never executed the cancel). If the agent is being rate-limited and cannot execute the cancel, do NOT post a closeout message — that just creates a false closeout. Post nothing, or post a one-line `Idle.` + caveat, and wait for the rate-limit window to pass before re-attempting.\n\n**Tier 3 - Echo with a real question you missed:** Re-read the actual thread context (the original ask may pre-date the echo loop). Answer once, then go back to Tier 0.\n\n## Pitfall - what NOT to do\n\n- Reposting a multi-paragraph status recap on every echo turn. The user already saw it. You are burning tokens and adding noise to a thread they are trying to read.\n- Adding `Memories used:` on echo turns - the rule requires it when you actually used memories. Echo turns use no new memory.\n- Adding the LLM-provenance footer on echo turns - the rule exempts verbatim operator text and pure-acknowledgment replies. Tier 0\u002F1 qualify.\n- Waiting for explicit \"go\" before cancelling a known-stale cron that is actively polluting the user's thread. The babysit-stale-watchdog skill says to self-cancel; doing it without asking is the correct behavior under echo-loop conditions because the user's silence IS the answer.\n- Calling `mcp__slack__conversations_add_message` for every echo. Most echoes don't need a Slack reply - they are internal to the agent loop. If you must reply, use the absolute shortest text.\n\n## When to break the loop unilaterally\n\nIf you observe **5+ consecutive echo turns** with no genuine new instruction from the user, you MUST:\n\n1. Stop replying entirely (Tier 0 minimum) - keep replying burns gateway budget\n2. If a stale cron is the source, cancel it via `cronjob action=remove job_id=\u003Cid>` (1 tool call, reversible - user can re-create if needed)\n3. If the thread is silent for >10 minutes of real wall-clock time AND the original task is half-done, post ONE short completion summary and stop\n4. Do NOT post \"should I continue?\" menus during an echo loop - the user is not reading. Finish what you can and post the receipt.\n\n## Verification\n\n- `gh pr view \u003CN> --json state` confirms the babysit's target PR is MERGED -> cancel is safe\n- `cronjob action=list` shows the cron no longer firing\n- `conversations_replies` shows no new \"Standing by.\" posts from you after the cancel\n\n## Related\n\n- `babysit-stale-watchdog` - the cancellation skill for the cron itself\n- `dropped-messages` - diagnosis path for genuinely dropped user messages (different problem; same fix family)\n- `gateway-loop-standdown` - meta-skill for gateway replay loops (different mechanism, similar surface)\n- SOUL.md `## COMMIT: followup-promise-requires-cron` - applies when echo loop is masking a promised follow-up",{"name":5,"description":7},"main","05df7380981a2c4af868ce0fa57962ae0eea62a9","hermes\u002Fskills\u002Fslack-thread-echo-loop-recognition",0,"https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills","https:\u002F\u002Fgithub.com\u002Fjleechanorg","2026-11-11 09:18:40",{"source":8,"skillName":5,"commands":63,"prompt":73,"zipAvailable":74},[64,67,70],{"tool":65,"command":66},"npx","npx skills add jleechanorg\u002Fjleechan-skills --skill slack-thread-echo-loop-recognition",{"tool":68,"command":69},"bunx","bunx skills add jleechanorg\u002Fjleechan-skills --skill slack-thread-echo-loop-recognition",{"tool":71,"command":72},"pnpm","pnpm dlx skills add jleechanorg\u002Fjleechan-skills --skill slack-thread-echo-loop-recognition","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002Fhermes\u002Fskills\u002Fslack-thread-echo-loop-recognition\u002FSKILL.md",true,[76],{"path":77,"resourceType":78,"resourceTypeDesc":79,"sizeBytes":80,"sourceHtmlUrl":81},"cluster-setup.md","REFERENCE","参考文档",8714,"https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Faws-eks\u002Fcluster-setup.md",[83,100,121,135,149,165],{"skillNo":84,"name":85,"nameZh":6,"description":86,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":87,"categories":88,"keywords":89,"publishedAt":50},"01M716Y5MTJ6GYJZ2ATXCJK8G4","instinct","Use when the user invokes \u002Finstinct or \u002Fin, or asks to \"message Instinct\", \"ask Instinct\", \"tell Instinct\", \"check Instinct\", or read replies from the configured peer assistant. iMessage first, WhatsApp Web as fallback.","https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Finstinct\u002FSKILL.md",[],[85,47,90,91,92,93,94,95,96,97,98,99],"when","replies","check","use","identity","whatsapp","gmail","read","message","ask",{"skillNo":101,"name":102,"nameZh":6,"description":103,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":104,"categories":105,"keywords":111,"publishedAt":50},"01M716Y4HF7FVVMJSA2CCVN5VF","hr","Compatibility alias for history-resume; produce the same fresh-state, provenance-aware resume briefing.","https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fhr\u002FSKILL.md",[106],{"categoryNo":107,"categoryName":108,"taxonomyType":109,"taxonomyTypeDesc":110},"01JBSEEDCAT000000000000038","人力资源","PROFESSION","适用职业",[102,112,113,114,35,115,116,117,118,119,120],"resume","compatibility","provenance","history","produce","alias","briefing","state","fresh",{"skillNo":122,"name":123,"nameZh":6,"description":124,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":125,"categories":126,"keywords":128,"publishedAt":50},"01M716Y1FFNFKFJYYKF8HQA6T8","history-resume","Resume briefing for the current repository branch or worktree using fresh state and admitted history sources.","https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fhistory-resume\u002FSKILL.md",[127],{"categoryNo":107,"categoryName":108,"taxonomyType":109,"taxonomyTypeDesc":110},[115,112,129,130,47,131,118,132,35,133,134,119,120],"history resume","branch","analysis","repository","worktree","sources",{"skillNo":136,"name":137,"nameZh":6,"description":138,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":139,"categories":140,"keywords":141,"publishedAt":50},"01M716XWXJ8EPHK4RH9T14TR85","grok","Alias for the canonical grokbot browser conversation workflow; \u002Fgrok talks to the Grok bot the same way \u002Fdot talks to Dot.","https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fgrok\u002FSKILL.md",[],[137,142,143,144,35,145,117,146,147,148],"dot","bot","workflow","canonical","conversation","browser","grokbot",{"skillNo":150,"name":151,"nameZh":6,"description":152,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":14,"licenseFileUrl":6,"sourceHtmlUrl":153,"categories":154,"keywords":155,"publishedAt":50},"01M70N9Q07DTE0EW5KFXMMMSJ0","codexa-bench","Compare `codexa` and normal `codex` on a fair split of comparable work by default; use `--strict` for duplicate runs of the exact same task.","https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fcodexa-bench\u002FSKILL.md",[],[156,157,158,93,159,35,160,161,162,163,164],"codexa bench","work","split","default","duplicate","task","compare","normal","codex",{"skillNo":166,"name":167,"nameZh":6,"description":168,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":6,"repositoryNo":12,"starsCount":13,"licenseSpdxId":169,"licenseFileUrl":170,"sourceHtmlUrl":171,"categories":172,"keywords":182,"publishedAt":50},"01M6C24S2X60SP8BBFGAEKPEGW","frontend-design","Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, artifacts, posters, or applications (examples include websites, landing pages, dashboards, React components, HTML\u002FCSS layouts, or when styling\u002Fbeautifying any web UI). Generates creative, polished code and UI design that avoids generic AI aesthetics.","Apache-2.0","https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Ffrontend-design\u002FLICENSE.txt","https:\u002F\u002Fgithub.com\u002Fjleechanorg\u002Fjleechan-skills\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Ffrontend-design\u002FSKILL.md",[173,176,179],{"categoryNo":174,"categoryName":175,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000009","前端开发",{"categoryNo":177,"categoryName":178,"taxonomyType":20,"taxonomyTypeDesc":21},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":180,"categoryName":181,"taxonomyType":109,"taxonomyTypeDesc":110},"01JBSEEDCAT000000000000032","设计师",[183,184,185,93,186,187,188,47,189,190,191,192,193,194,195,196,197,198,199,200,201,202,203,204,205,206,90,207],"frontend","design","frontend design","generic","ui design","react","html","components","code","artifacts","ui","aesthetics","Production","web components","landing","applications","quality","web","css","create","examples","with","react components","web ui","pages"]