Skip to content

fix(skill): document bundle postings and topic ID resolution - #157

Closed
joshRpowell wants to merge 2 commits into
basecamp:mainfrom
joshRpowell:fix/box-topic-id-guidance
Closed

fix(skill): document bundle postings and topic ID resolution#157
joshRpowell wants to merge 2 commits into
basecamp:mainfrom
joshRpowell:fix/box-topic-id-guidance

Conversation

@joshRpowell

@joshRpowelljoshRpowell commented Aug 4, 2026

Copy link
Copy Markdown

The embedded skill documented a topic_id on every hey box posting. No live posting carries that field, so the documented boxthreads workflow fails.

This corrects the guidance to describe what postings actually carry. Agents resolve a topic ID from the first /topics/<id> URL a posting offers — app_url on a kind: "topic" posting, or app_bundle_url on a kind: "bundle" posting wrapping a single message. A bundle wrapping several messages names a contact rather than a thread, so no topic ID exists for it; agents are told to direct the user to HEY rather than substituting the posting ID, which 404s as /topics/<posting-id>/entries.

Measured on a 500-posting Imbox: 262 topic postings, 70 single-entry bundles resolvable via app_bundle_url, 168 multi-message bundles unresolvable. Reading app_url alone would give up on all 238 bundles.

Also corrects the documented response envelope ({ok, data:{...}}, not {box, postings}) and notes that a bundle's name concatenates several subjects.

This is a docs-only change to bundled agent guidance; it does not make unreachable bodies readable. Bundle expansion is tracked in #156.

Validation: GOCACHE=/private/tmp/hey-cli-go-build make test

Post-Deploy Monitoring & Validation

No additional operational monitoring required; this only corrects bundled agent guidance and has no runtime service behavior.


Summary by cubic

Clarifies ID handling in the HEY skill so hey threads/hey reply always use a topic ID and never a posting ID. Updates hey box --json docs with the correct {"ok": true, "data": {...}} envelope, defines kind: "topic" and kind: "bundle", states postings don’t include topic_id, and explains resolving topic IDs from app_url or app_bundle_url (single-message bundles); multi-message bundles have no topic ID and should be opened in HEY.

Written for commit 90be0bb. Summary will update on new commits.

Review in cubic

CopilotAI balanced review requested due to automatic review settings August 4, 2026 13:02

CopilotAI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR corrects the bundled agent guidance in skills/hey/SKILL.md so that AI agents no longer treat an Imbox posting id as a topic ID when calling hey threads or hey reply. As described in issue #156, hey box --json does not guarantee a topic_id, and passing a posting ID to hey threads requests /topics/<posting-id>/entries, which returns 404. The updated skill distinguishes posting IDs from topic IDs and instructs the agent to fall back to the topic ID in app_url when present, or direct the user to HEY otherwise.

Changes:

  • Updated the box response-format note to clarify that topic_id is not currently guaranteed in posting output.
  • Rewrote the "ID note" so agents extract the topic ID from app_url (/topics/<id>) and avoid substituting the posting ID when no topic route exists.

Tip

If you aren't ready for review, convert to a draft PR.
Click "Convert to draft" or run gh pr ready --undo.
Click "Ready for review" or run gh pr ready to reengage.


💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

The previous revision told agents to give up whenever a posting's app_url
was not topic-shaped. That discards the bundles that wrap a single message,
which carry their topic in app_bundle_url and read fine — 70 of 238 bundles
(29%) in a 500-posting sample.
Document the two posting kinds instead. A kind=topic posting always has a
/topics/ app_url; a kind=bundle posting has a contact-shaped app_url and is
resolvable via app_bundle_url only when it wraps one message. A bundle of
several messages names a contact rather than a thread, so no topic ID exists
for it and there is no CLI command to list its contents.
Also correct the documented envelope ({ok, data:{...}} rather than
{box, postings}), note that a bundle's name concatenates several subjects,
and state plainly that no posting carries a topic_id rather than that one is
not "guaranteed".
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
CopilotAI review requested due to automatic review settings August 4, 2026 13:42
@joshRpowelljoshRpowell changed the title fix(skill): clarify box topic IDsfix(skill): document bundle postings and topic ID resolutionAug 4, 2026

CopilotAI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated no new comments.

robzolkos added a commit that referenced this pull request Aug 24, 2026
A bundle posting's app_url names its sender's contact page, so the
topic_id resolved out of it was always zero and hey box view --json
served bundle rows with no way to read the thread they open.
haystack's bundle_posting route points app_bundle_url at a topic exactly
when the bundle holds one unseen thread — the thread the row opens in
the web app. mail.TopicIDOf now tries app_url and falls back to
app_bundle_url, so those rows carry a usable topic_id in the CLI's
listings and the TUI alike. A bundle with several unseen threads (or
none) still answers zero, and the skill now says what a bundle row is,
that topic_id can be absent on one, and to reach the bundled mail
through hey contacts unbundle rather than passing the box item id to
hey threads.
Surfaced by #157, which documented the workaround; resolving it in the
CLI keeps the skill's contract (every posting names its thread where one
exists) true instead.
@robzolkos

Copy link
Copy Markdown
Collaborator

Closing as superseded. The core complaint — the skill documenting a topic_id no posting carried — was fixed at the source: the CLI resolves topic_id from the posting's URLs itself (mail.TopicIDOf), so the skill's documented field is now real. #301 carried this PR's remaining findings home: the app_bundle_url fallback for single-unseen-thread bundles is now done in the CLI rather than documented as an agent workaround, and the skill covers bundle rows and the missing-topic_id case (with hey contacts unbundle as the remedy). Thanks — the bundle analysis here is what surfaced both. #156 stays open for multi-unseen-thread bundles.

Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants

@joshRpowell@robzolkos