feat(integrations): suggest curated skills per integration with one-click add#4912
Conversation
…lick add Curate research-backed, capability-grounded skills for every catalog integration and surface them on the integration detail page. Each skill maps to operations the block actually supports and can be added to the workspace in one click; track adds in PostHog. - Add SuggestedSkill type + skills field on BlockMeta; populate skills for all 193 catalog integrations (3 audit passes for grounding/sourcing) - getSuggestedSkillsForBlock() with versioned-type (e.g. notion_v2) base fallback - Skills section on the integration detail page with add/added states - integration_skill_added PostHog event with workspace/integration metadata
|
The latest updates on your projects. Learn more about Vercel for GitHub. |
PR SummaryMedium Risk Overview On each integration detail page, a new Skills section lists those suggestions with Add / Added state (matched to workspace skill names through Authoring rules are tightened in add-block / validate-integration docs and Reviewed by Cursor Bugbot for commit 04ca966. Configure here. |
…r add The row derived Added state solely from the useSkills cache, so between a successful create and the list refetch the row still showed Add and could be clicked again, hitting the server duplicate-name check. Track added names in local state so the row reflects the add immediately.
|
@greptile |
|
@cursor review |
Greptile SummaryThis PR adds curated skill suggestions to all 193 integration detail pages, with one-click "Add" buttons that create workspace skills via the existing
Confidence Score: 5/5Safe to merge — the changes are additive (static curated data on block metas, a new UI section, and a cache-merge optimisation) and do not touch any execution, auth, or data-persistence paths. All changed paths are either pure static data (skills fields on BlockMeta), UI-only (the new section component), or a narrow query-cache improvement in useCreateSkill's onSuccess. The concurrent-add guard uses both a ref and a Set, error handling toasts on failure, and getSuggestedSkillsForBlock correctly handles versioned type look-ups. No mutations to execution logic, auth, or database schema are present. No files require special attention. Important Files Changed
Sequence DiagramsequenceDiagram
participant Page as IntegrationBlockDetail
participant Section as IntegrationSkillsSection
participant Hook as useCreateSkill
participant Cache as React Query Cache
participant API as POST /api/skills
Page->>Page: getSuggestedSkillsForBlock(type)
Page->>Section: skills[], workspaceId, integrationType
Note over Section: useSkills() → existingNames Set
Note over Section: skillsReady = !isPending && !isPlaceholderData
Section->>Section: User clicks Add
Section->>Section: inFlightRef.add(name) + setPendingNames
Section->>Hook: "mutateAsync({ workspaceId, skill })"
Hook->>API: "POST /api/skills { skills:[{name,desc,content}], workspaceId }"
API-->>Hook: "{ success: true, data: SkillDefinition[] }"
Hook->>Cache: setQueryData — merge new skills by ID
Hook->>Cache: invalidateQueries (background refetch)
Cache-->>Section: "existingNames updated → added=true"
Section->>Section: captureEvent integration_skill_added
Section->>Section: finally: pendingNames.delete(name)
Reviews (6): Last reviewed commit: "chore(integrations): drop local-variable..." | Re-trigger Greptile |
…thoring Address PR review feedback on the suggested-skills section: - Make useSkills the single source of truth for Added state by writing the created skill into the React Query cache onSuccess (fixes stale Added that survived a delete, and the lag that allowed a duplicate click) - Track in-flight adds in a Set so concurrent adds keep independent pending state and cannot be double-submitted - Surface failures with toast.error instead of swallowing the rejection - Extract the duplicated SkillTile into a shared workspace component Also document the new BlockMeta.skills field in the add-block and validate-integration skills (+ blocks AGENTS.md): skills must be grounded in the block's tools.access and sourced from real online use cases, never invented.
|
@cursor review |
|
@greptile |
…ursor docs - Guard handleAdd with a ref so two rapid clicks cannot both fire a create before the disabled state re-renders (pendingNames is async) - Fold the create-cache-merge rationale into the hook's TSDoc and drop non-TSDoc inline comments to match the repo convention - Align .cursor add-block/validate-integration command docs with the newer .claude/.agents versions: BlockMeta section + skills authoring/validation guidance (grounded in tools.access, sourced from real online use cases)
|
@cursor review |
|
@greptile |
…ills useSkills uses keepPreviousData, so during initial load or a workspace switch the list could be empty or a prior workspace's placeholder — making rows show a misleading Add (duplicate-submittable) or a false Added. Derive skillsReady from !isPending && !isPlaceholderData, only mark Added when ready, and disable Add until the current workspace's list has loaded.
Keep to the repo's TSDoc-on-declarations convention — the in-flight guard and skillsReady derivation are self-evident from naming.
|
@cursor review |
|
@greptile |
There was a problem hiding this comment.
✅ Bugbot reviewed your changes and found no new issues!
Comment @cursor review or bugbot run to trigger another review on this PR
Reviewed by Cursor Bugbot for commit 04ca966. Configure here.
|
@greptile review |
1 similar comment
|
@greptile review |
Summary
useCreateSkillflow)tools.access) — and validated across 3 audit passes against live online sourcesSuggestedSkilltype + optionalskillsfield onBlockMeta;getSuggestedSkillsForBlock()resolves versioned catalog types (e.g.notion_v2) to the base metaintegration_skill_addedPostHog event capturingworkspace_id,integration_type,skill_name,position,skill_countType of Change
Testing
Tested manually. Typecheck clean, biome lint/format clean, API-validation audit passes; verified all 193 catalog integrations resolve ≥2 grounded skills.
Checklist