domain-skills: google voice - messaging (existing-thread sends, deterministic thread URLs)

[amarin76]

Adds a Google Voice messaging domain skill, verified live 2026-08-05 with a real send.

What it documents:

• The rule that decides automatability: sending in an EXISTING thread works normally, while new-recipient compose is not automatable (the send button stays disabled because synthetic input never creates the recipient chip; two input approaches failed).
• Deterministic thread URLs: itemId is t. plus the E.164 number, so a known number goes straight to its thread with no virtualized-list scroll hunt.
• Thread list mechanics: cdk-virtual-scroll-viewport with GV-THREAD-LIST-ITEM rows, ~12 in DOM at once, JS scroll only (Input mouseWheel blocks on background tabs).
• A working compose recipe: focus the visible textarea, Input.insertText, exact value check, click the aria-label Send message button, verify by screenshot.
• Traps: a hidden second textarea holding a token blob that must not be read as compose state, both panes sharing innerText markers, fresh bubbles missing from DOM text heuristics, contact labels not matching business names, and the bare-weekday timestamp that parses as a fake inbound reply.

🤖 Generated with Claude Code

---

Summary by cubic

Documents reading threads and sending in existing Google Voice threads, with deterministic thread URLs and a reliable send flow. Confirms new-recipient compose is not automatable.

• New Features
  • Defines the rule: sending works in existing threads; new-recipient compose stays disabled.
  • Documents deterministic thread URLs (itemId = t. + E.164) to open threads directly.
  • Provides a working send flow: focus visible textarea, insert text, verify value, click "Send message," confirm by screenshot.
  • Notes GV specifics: virtualized thread list with JS scroll-only, hidden second textarea, mixed-pane innerText pitfalls, delayed bubble render, contact label mismatches, outbound "You:" detection signal, and weekday timestamp false positives.

^{Written for commit 48b000c. Summary will update on new commits.}

[cubic-dev-ai]

1 issue found across 1 file

Prompt for AI agents (unresolved issues)

Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.


<file name="domain-skills/google-voice/messaging.md">

<violation number="1" location="domain-skills/google-voice/messaging.md:40">
P3: The compose-focus step tells the agent to "Click its center coordinates" but never specifies how to obtain those coordinates, and it contradicts the recipe's other steps, which drive the DOM via JS (element `.click()`, `document.activeElement`, `Input.insertText`). In an executable skill, an unscripted coordinate click is the one instruction most likely to land on the wrong element — and given the doc itself warns a second hidden textarea exists, a blind coordinate click can focus that hidden textarea (a `TEXTAREA` tag passes the `activeElement.tagName === 'TEXTAREA'` assertion), routing the later `activeElement.value === MSG` check and the send to the wrong element. Suggest specifying a mechanism (e.g., obtain the visible `textarea[aria-label='Type a message']` rect via `js()`/`getBoundingClientRect` and click through `Input.dispatchMouseEvent`, matching how the rest of the skill interacts) or drive focus the same JS way as the button step.</violation>
</file>

<sub>Reply with feedback, questions, or to request a fix.

Fix all with cubic | Re-trigger cubic</sub>

[cubic-dev-ai]

P3: The compose-focus step tells the agent to "Click its center coordinates" but never specifies how to obtain those coordinates, and it contradicts the recipe's other steps, which drive the DOM via JS (element .click(), document.activeElement, Input.insertText). In an executable skill, an unscripted coordinate click is the one instruction most likely to land on the wrong element — and given the doc itself warns a second hidden textarea exists, a blind coordinate click can focus that hidden textarea (a TEXTAREA tag passes the activeElement.tagName === 'TEXTAREA' assertion), routing the later activeElement.value === MSG check and the send to the wrong element. Suggest specifying a mechanism (e.g., obtain the visible textarea[aria-label='Type a message'] rect via js()/getBoundingClientRect and click through Input.dispatchMouseEvent, matching how the rest of the skill interacts) or drive focus the same JS way as the button step.

Prompt for AI agents

Check if this issue is valid — if so, understand the root cause and fix it. At domain-skills/google-voice/messaging.md, line 40:

<comment>The compose-focus step tells the agent to "Click its center coordinates" but never specifies how to obtain those coordinates, and it contradicts the recipe's other steps, which drive the DOM via JS (element `.click()`, `document.activeElement`, `Input.insertText`). In an executable skill, an unscripted coordinate click is the one instruction most likely to land on the wrong element — and given the doc itself warns a second hidden textarea exists, a blind coordinate click can focus that hidden textarea (a `TEXTAREA` tag passes the `activeElement.tagName === 'TEXTAREA'` assertion), routing the later `activeElement.value === MSG` check and the send to the wrong element. Suggest specifying a mechanism (e.g., obtain the visible `textarea[aria-label='Type a message']` rect via `js()`/`getBoundingClientRect` and click through `Input.dispatchMouseEvent`, matching how the rest of the skill interacts) or drive focus the same JS way as the button step.</comment>

<file context>
@@ -0,0 +1,63 @@
+## Sending in an existing thread (working recipe)
+
+1. Open the thread by itemId URL (above), wait, verify header.
+2. Compose box: the VISIBLE `<textarea>` (aria-label "Type a message"). Click its
+   center coordinates to focus, confirm `document.activeElement.tagName === 'TEXTAREA'`.
+3. `cdp("Input.insertText", text=MSG)` into the focused box. Then verify
</file context>