Skip to content

feat(skills): offer to update stale skills after commands - #237

Open
gjtorikian wants to merge 3 commits into
mainfrom
feat/skills-update-prompt
Open

feat(skills): offer to update stale skills after commands#237
gjtorikian wants to merge 3 commits into
mainfrom
feat/skills-update-prompt

Conversation

@gjtorikian

Copy link
Copy Markdown
Contributor

Summary

  • Skills ship inside the binary and are copied into each agent's skills/ dir, so every release that bumps @workos/skills leaves installed copies behind. Until now the only signal was workos doctor, and the setup offer never re-fires once completed — a user who set up once would never learn their skills were stale.
  • After each successful command in a human TTY, the CLI now offers to refresh agents whose .workos-skill-version marker trails the bundled version. ("latest" is whatever this binary bundles, so there is no remote fetch, cache, or cooldown.)
  • Reuses what already exists — checkSkills() (doctor's staleness check) for detection and refreshWorkOSSkills() (atomic per-skill backup/rename) for the refresh. The new code is the prompt and its gating.
  • Consent: defaults to No (AUTH-6734: "an absent-minded Enter never writes to an agent dir"), honors a prior setup decline, and is silent in JSON / agent / CI / non-TTY. Asked at most once per bundled version — a "no" is remembered in preferences.json (setup.skillsUpdateOfferedVersion) until a newer CLI ships newer skills. Ctrl-C is not remembered, matching setup.
  • Exempt commands: root (--help / --version), skills, setup, doctor.

Skills ship inside the binary and are copied into each agent's skills
dir, so every CLI release that bumps @workos/skills silently leaves
installed copies behind. The only signal was `workos doctor`, which
nobody runs routinely, and the setup offer never re-fires once
completed — so a user who set up once would never learn their skills
were stale.

After each successful command in a human TTY, offer to refresh agents
whose version marker trails the bundled version. Mirrors wrangler's
update prompt (cloudflare/workers-sdk#14872) minus the network: the
latest version is whatever this binary bundles, so there is no remote
fetch, cache, or cooldown to manage.

The prompt defaults to No (AUTH-6734: an absent-minded Enter never
writes to an agent dir), honours a prior setup decline, and is asked
at most once per bundled version — a "no" is remembered until a newer
CLI ships newer skills. Ctrl-C is not remembered, matching setup.
@greptile-apps

greptile-apps Bot commented Sep 10, 2026

Copy link
Copy Markdown

RetriggerConfidence Score: 5/5

The changes since the previous review appear safe to merge, with both prior findings resolved and no new actionable defect identified.

Summary

  • Runs only after successful, non-exempt commands in a prompt-capable human TTY.
  • Defaults the update confirmation to No and remembers declines per bundled skills version.
  • Detects partial multi-agent refreshes, reports the remaining stale agents, and allows one additional offer.
  • The changes since the previous review correctly address partial-refresh retry eligibility without violating mounted repository rules.

Diagram

%%{init: {'theme': 'neutral'}}%%
flowchart TD
  A[Successful CLI command] --> B{Prompt-capable human TTY?}
  B -- No --> Z[Remain silent]
  B -- Yes --> C{Command exempt or setup declined?}
  C -- Yes --> Z
  C -- No --> D[Check installed skill versions]
  D --> E{Stale agents and version not already offered?}
  E -- No --> Z
  E -- Yes --> F[Offer update, default No]
  F -->|Cancel| Z
  F -->|Decline| G[Record offered version]
  F -->|Accept| H[Record offered version and refresh stale agents]
  H --> I{Refresh result}
  I -->|All updated| J[Report success]
  I -->|None updated| K[Report explicit retry command]
  I -->|Partial, first attempt| L[Clear offered version and record retry marker]
  I -->|Partial, retry spent| M[Keep offered version and report remaining agents]
  L --> N[Allow one more offer]
Loading

Reviews (3) · Last reviewed commit: "fix(skills): give an incomplete skill re..."

Comment thread src/commands/setup.ts Outdated
Comment thread src/commands/setup.ts Outdated
…irected stdin

Two review findings on the stale-skills offer:

refreshWorkOSSkills is truthy as soon as one agent lands, so a multi-agent
refresh where one target failed was reported as a clean success. The offered
version is recorded before the refresh — deliberately, so a persistently
broken refresh cannot nag after every command — which meant the failed agent
stayed stale with no second offer and no mention of it. Partial refreshes now
name what did not update and point at `workos skills install`.

Interaction mode is resolved from stdout/stderr, so `workos org list </dev/null`
still resolves to human mode: the offer printed, ui.confirm threw on the
non-TTY stdin, and the catch swallowed it before the version was recorded — so
every later command re-printed an offer nobody could answer. Gate on
process.stdin.isTTY before any prompt-related output.
A partial refresh left the failed agent stale with no further automatic
offer: the bundled version is recorded before the refresh runs, so the
warning plus `workos skills install` was the only remaining path.

Some agents landing proves the refresh mechanism works, so the miss is
worth retrying. A partial outcome now clears the recorded version and
marks the version retried, which re-opens the offer for exactly one more
command; a second incomplete refresh lets the recorded version stand.

The pre-refresh record stays: a refresh that throws, or a process killed
mid-way, must not turn into an offer after every subsequent command. A
refresh that lands nothing at all is still remembered outright, since
nothing about it suggests a retry would fare better.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

1 participant