GHL Skill Feedback — hl.bulkFollowupByTag | Skill not implemented + skill registry discrepancy between prompt metadata and sandbox

Michael Gorski · 2026-04-28T21:22:16.163Z

@Shivam Tiwari Here’s my final report for the day. This one produced the most detailed diagnostic output. The agent failed on execution but delivered something genuinely valuable in the process. It created a self-audit of the skill registry that surfaced a structural discrepancy worth your team's attention. Environment: MoltClaw version: v2026.4.12-mc.14 Model: Claude Opus 4.7 (1M) Surface: AskClaw Action: hl.bulkFollowupByTag Steps to Reproduce: Ask MoltClaw to send a follow-up message to every contact tagged 'demo-scheduled' who hasn't replied in the last 7 days Agent correctly parses both filter conditions (tag + inactivity) and requests message content The user approves drafted message and instructs agent to prepare the send proposal Agent stalls with no confirmation card surfaces User nudges the agent by typing "Please prepare the send proposal now" Agent generates confirmation card using action type hl.bulkFollowupByTag Action fails and the SKILL is not implemented Agent self-audits SKILL registry and produces capability map from locally mounted docs Failure #1 | Agent Stall Before Confirmation Card After acknowledging it would prepare the send proposal, the agent stopped without surfacing a confirmation card or error message. No timeout, no status update, no visible signal that the task had stopped. This is a consistent pattern observed across my other tests. The stall occurs specifically at the transition point between task acknowledgment and confirmation card generation on multi-step operations. (Already documented) Failure #2 | Error 400 Action Type “hl.bulkFollowupByTag” Not Yet Implemented After being nudged, the agent generated a confirmation card using "hl.bulkFollowupByTag" is a plausible but non-existent action type. This is the second fabricated bulk action type observed in consecutive test sessions. My previous test session produced "hl.bulkMessageByTag". Both follow correct MoltClaw naming conventions, making them difficult to identify as fabricated without attempting execution. The agent later correctly acknowledged this was its own mistake. Failure #3 | Skill Registry Discrepancy Between Prompt Metadata and Sandbox During self-audit, the agent discovered that skill paths listed in the available_skills prompt metadata are not all physically present in the sandbox. The specific files the agent attempted to read included: “highlevel-conversations-add-an-outbound-message-write” and “highlevel-contacts-list-read” were listed in the prompt but not mounted locally. The agent correctly flagged this as a structural issue. What the agent DID confirm as available from locally mounted docs: Confirmed read operations: POST /proxy/contacts/search (supports tag filters, date filters, pagination) GET /proxy/contacts/{contactId} GET /proxy/contacts GET /proxy/conversations/search Confirmed write action types: hl.createContact hl.updateContact hl.deleteContact hl.upsertContact What the agent could did NOT confirm: Any supported action type for outbound conversation messaging Any supported bulk messaging action Any supported direct send SMS/email/message proposal schema Root Cause: Two compounding issues are present. First, the agent has no pre-card validation step to check whether a proposed action type exists in the current skill registry. This same root cause as the previous bulk messaging failure. Second, and more significantly, the available_skills list in the prompt metadata appears to be broader than the skill files actually mounted in the sandbox. In other words, the agent is operating with an incomplete and potentially misleading picture of what is actually executable. This goes back to an earlier discovery where the structural gap affects reliability across all skill categories, not just bulk messaging. Some Good News: 😃 The agent's compound filter logic worked great. It correctly parsed tag-based targeting combined with an activity-based inactivity condition simultaneously. After the execution failure, the agent self-audited rather than continuing to guess, correctly admitted its mistake, and produced a detailed and accurate capability map from the docs it could actually read. It then proposed a clean recovery path. First to complete the contact and conversation read pass, identify qualifying contacts, and then work with whatever write path is confirmed by actual backend behavior. The reasoning quality throughout was solid. Potential Remediation Steps: Reconcile the available_skills prompt metadata with the skill files actually mounted in the sandbox. This will allow the agent the only see skills it can actually execute Add a pre-card validation step that checks whether the proposed action type exists in the confirmed skill registry before generating a confirmation card Surface a clear "capability not available in this version" message when no matching skill is found, r

Public Group

MoltClaw by HighLevel (Beta)

Beta testers only 🧪. You're building the future of AI agents on HighLevel. Drop bugs 🐛, share wins 🏆, request features 💡

MoltClaw Website

HighLevel Website

Members

242

Posts

Admins

GHL Skill Feedback — hl.bulkFollowupByTag | Skill not implemented + skill registry discrepancy between prompt metadata and sandbox

GHL Skill Feedback — Agent stalling on multi-step fetch operations before confirmation card

GHL Skill Feedback - hl.bulkMessageByTag | Skill not implemented & agent generating placeholder action type

GHL Skill Feedback — hl.bulkFollowupByTag | Skill not implemented + skill registry discrepancy between prompt metadata and sandbox