Publish Rewind with complete local setup#2345
Conversation
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
Here's a visual recap of what changed: Open the full interactive recap |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
We've been automatically notified and are looking into it. Push a new commit to re-trigger the review, or contact support@builder.io if this keeps happening. Error ID: |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
Builder reviewed your changes and found 1 potential issue 🟡
Review Details
Incremental Code Review Summary
PR #2345 updates the Rewind public-skill publication flow and keeps the installer centered on Core's local Clips Screen Memory setup. The latest code preserves the useful fail-closed behavior: Rewind rejects disconnected MCP modes, checks for the local store before writing skill or agent configuration, and documents explicit user consent for opening Clips and enabling capture. The CLI delegation and client-specific coverage remain sound.
This is a standard-risk change because it alters shared CLI installation behavior and cross-repository synchronization. One new integration issue was confirmed in the latest state: the producer now emits agent-native-public-skills-updated, but the current BuilderIO/skills repository only declares a repository_dispatch listener for agent-native-plan-skills-updated. GitHub accepts the dispatch successfully even when no workflow handles it, so the new event can silently fail to mirror Rewind unless the companion listener is landed or the event is changed to one the receiver handles.
✅ Good patterns: preflight-before-write ordering, explicit privacy and native-permission boundaries, canonical Core ownership of MCP setup, and tests covering the new failure paths.
🧪 Browser testing: Skipped — PR only modifies CLI logic, skill content, tests, workflow configuration, and release metadata; it has no user-facing browser impact.
| -f "client_payload[sourceSha]=${{ github.sha }}" \ | ||
| -f "client_payload[sourceRunUrl]=${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ github.run_id }}" | ||
|
|
||
| gh api repos/BuilderIO/skills/dispatches \ |
There was a problem hiding this comment.
🟡 Dispatch target has no listener for the new public-skill event
The added agent-native-public-skills-updated dispatch is currently a no-op: the current BuilderIO/skills repository only declares a repository_dispatch listener for agent-native-plan-skills-updated. GitHub accepts repository-dispatch event names without a matching workflow, so this step succeeds while never mirroring Rewind. Add or land the corresponding downstream listener and sync logic before emitting this event, or dispatch an event that an existing receiver handles.
Additional Info
Verified against the current BuilderIO/skills default branch via GitHub API: only ci.yml and update-agent-native-plan-skills.yml exist, and the latter listens only for agent-native-plan-skills-updated.
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
Builder reviewed your changes and found 1 potential issue 🟡
Review Details
Incremental Code Review Summary
The latest commit adds lazy installation-ID creation to both CLI telemetry implementations so failed Rewind preflights do not create telemetry state merely by constructing a telemetry client. The change also adds coverage for that behavior, while the existing Rewind installer and public synchronization changes remain otherwise unchanged. The unresolved public dispatch comment was intentionally not reposted.
This is a standard-risk change because the PR modifies shared CLI routing, telemetry initialization, and local MCP installation semantics. One new medium-severity issue remains: the Rewind preflight exits early for --no-mcp and --mcp-url, so a multi-skill invocation can install an earlier skill before Rewind reaches its incompatible-flag rejection. That violates the stated fail-before-writes guarantee for invalid multi-selection requests.
✅ Good patterns: lazy telemetry initialization avoids unnecessary local state on failed commands, the new test directly verifies no installation ID is created, and focused Core/skills test suites pass.
🧪 Browser testing: Skipped — PR only modifies CLI logic, skill content, tests, workflow configuration, and release metadata; it has no user-facing browser impact.
| if ( | ||
| parsed.command !== "add" || | ||
| parsed.dryRun || | ||
| !parsed.mcp || | ||
| parsed.mcpUrl | ||
| ) { | ||
| return undefined; | ||
| } |
There was a problem hiding this comment.
🟡 Preflight Rewind when its required MCP is disabled
runSkills() uses this preflight before iterating selected targets, but the guard returns for --no-mcp and --mcp-url. A multi-skill invocation such as skills add --skill assets --skill rewind --no-mcp --client codex --yes can therefore install Assets first, then reach Rewind's incompatible-flag rejection and fail after writing files. Check Rewind selection and reject incompatible flags in the early preflight before target iteration.
Additional Info
The existing direct Rewind checks in addAgentNativeSkill occur after target routing and cannot protect earlier selections in a multi-skill invocation.
There was a problem hiding this comment.
Builder reviewed your changes and found 2 potential issues 🟡
Review Details
Incremental Code Review Summary
The latest commit adds rollback snapshots around Rewind’s skill/configuration writes and restores prior files when MCP setup fails. The rollback path is covered for Codex and Claude Code, and the existing open comments were respected: the public dispatch issue and the --no-mcp preflight comment were not reposted or resolved.
This remains a standard-risk change because it affects shared CLI installation, telemetry, and local MCP configuration. Two new medium-severity issues remain: supported Rewind aliases are not consistently recognized by telemetry routing, and the standalone skills package delegates only the literal rewind name. As a result, equivalent aliases can create telemetry before preflight or trigger an unnecessary public-catalog fetch before Core performs local setup.
✅ Good patterns: snapshot/restore is scoped to Rewind paths, rollback is attempted on MCP failures, existing files are restored in tests, and successful Rewind completion telemetry is delayed until MCP registration succeeds.
🧪 Browser testing: Skipped — PR only modifies CLI logic, telemetry, skill content, tests, workflow configuration, and release metadata; it has no user-facing browser impact.
| const explicitlyTargetsRewind = args.some( | ||
| (arg, index) => | ||
| arg === "rewind" || |
There was a problem hiding this comment.
🟡 Defer Rewind telemetry for all supported aliases
skills.ts recognizes screen-memory, clips-rewind, and agent-native-rewind as Rewind aliases, and preflightRewindStore normalizes them before rejecting an unavailable local store. This routing check only recognizes the literal rewind, so agent-native skills add screen-memory ... executes cli.run tracking before preflight; createCliTelemetry.track() can create ~/.agent-native/installation-id and send telemetry for an equivalent failed Rewind install. Normalize the positional and --skill values through the same alias mapping or cover all supported aliases.
Additional Info
Confirmed against BUILT_IN_APP_SKILL_ALIASES in packages/core/src/cli/skills.ts and the new preflight path.
| function isCoreDelegatedSkill(skillName: string): boolean { | ||
| // Rewind uses Core's local Screen Memory installer, not the standalone | ||
| // package's hosted MCP descriptor path. | ||
| return skillName === "rewind" || Boolean(resolveAppForSkill(skillName)); |
There was a problem hiding this comment.
🟡 Recognize Rewind aliases when delegating standalone installs
Core accepts screen-memory, clips-rewind, and agent-native-rewind as Rewind aliases, but the standalone installer only treats the literal rewind as core-delegated here. @agent-native/skills add screen-memory ... can therefore materialize/fetch the public BuilderIO/skills catalog before Core is invoked, making the supported alias depend on an unrelated network operation and potentially fail offline before local-store preflight. Share Core’s alias normalization or maintain the complete alias set, with delegation coverage for each alias.
Additional Info
Confirmed against BUILT_IN_APP_SKILL_ALIASES in packages/core/src/cli/skills.ts; isCoreDelegatedSkill currently checks only skillName === "rewind".

Problem
Rewind is a local screen-memory capability in Clips Desktop, not a standalone prompt. An agent needs both the Rewind instructions and a local Model Context Protocol (MCP) connection to Clips. The public skills installer previously treated Rewind like an ordinary copied skill, which could leave users with instructions that referenced tools their agent could not call.
First-time users also need a safe path to install Clips. Because Clips can capture screen and audio, an agent must not silently install the app, approve macOS permissions, enable capture, or claim setup succeeded without checking the real local connection.
Approach
Keep Agent Native as the single source of truth for Rewind's instructions, privacy boundaries, and local connection setup. The public
BuilderIO/skillsrepository receives an exact generated copy for discovery, while both advertised Agent Native installers converge on Core's fail-closed setup flow.The skill may offer to open the official Clips download page after the user agrees. Native installation, Gatekeeper approval, macOS capture permissions, and enabling Rewind remain human-controlled. Setup is complete only when the local Screen Memory store exists, the skill and MCP configuration are installed together, and
screen_memory_statussucceeds.What changed
BuilderIO/skillscan mirror it without maintaining a second copy by hand.@agent-native/skills add --skill rewindto Core's complete local Screen Memory installer.--no-mcp, remote MCP URLs, and missing-store setup before writing either the skill or agent configuration.Safety and operations
Verification
--no-mcprejection, consent guidance, and Cursor/Claude Code configuration.@agent-native/skillstypecheck proved Rewind delegates to Core and preserves CLI arguments and errors.SKILL.mdmatches its Agent Native source.57e81e745—Build, Typecheck, Fast tests, Core integration, Content DB/parity, Plan E2E, and lint/format.spawn tsx ENOENT. H1–H10 must still be rerun with a clean profile and runnable branch-built CLI before merge. Existing Clips state, permissions, configuration, and Screen Memory data were not touched.Review focus
Companion PR
Public catalog and documentation: BuilderIO/skills#54