Repository navigation
Package as a Cursor plugin (skill + Context7 MCP) - #2
Merged
Merged
Conversation
Cursor 3.9+ supports Anthropic Agent Skills and a plugin system that bundles skills and MCP servers, mirroring the Claude Code plugin this repo already ships. Add the Cursor equivalents so Cursor users get the same one-step install instead of the previous manual symlink (which wired no doc source and broke without SSH keys). - .cursor-plugin/plugin.json + marketplace.json — mirror the .claude-plugin manifests; point skills at ./iterable-android and declare the Context7 MCP server inline (an mcpServers path reference silently fails to register). - README: rewrite the Cursor install section around the plugin, with a skill-only fallback and a one-click Context7 MCP deeplink; note both plugins in the repo layout. - SKILL.md: make the AskUserQuestion references host-agnostic so the skill degrades gracefully under Cursor's agent. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
franco-zalamena-iterable
added a commit
that referenced
this pull request
Sep 25, 2026
PITFALLS #2 said the init callback "should log initialization and nothing else". The canonical pattern in SKILL.md said "keep it empty" and shipped a comment-only body. A client trial followed the canonical pattern — correctly, it is the one labelled "start here" — and read "should log" as optional. Both halves meant the same thing: do not call SDK methods there. Only one of them said it in code someone copies, so make that one concrete. The log line earns its place: the SDK's verbose output proves the SDK initialized, but only the callback's own line proves the callback ran, which is the difference between "init never fired" and "init fired, identify didn't". Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
franco-zalamena-iterable
added a commit
that referenced
this pull request
Sep 25, 2026
The canonical pattern takes identity as a String, which assumes it exists at Application.onCreate(). Real apps often keep it in a DataStore or ViewModel Flow that emits at login and again on account switch. This was the single largest cost in a client trial — fifteen minutes to work out that the value has to be collected and that setEmail still belongs inside onSDKInitialized, with pitfalls #2 and #3 each pulling in a plausible wrong direction. Both wrappers are needed and the section says why: onSDKInitialized covers an identity that arrives before the SDK is ready, the collector covers one that arrives after. It also names the two shortcuts that look like simplifications — hoisting setEmail into the init callback, and first()-ing the flow back into a String, which silently drops the account switch. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.