Summary

Skill Workshop can leave a proposal visible as waiting in the UI even after the skill has already been installed manually and is visible/active in the skills list. This creates a confusing duplicate-action path: the user sees both an active skill and a pending Use it proposal for what appears to be the same skill.

Observed case

• Date: 2026-06-04
• Skill/proposal: tweet-argument-analysis
• Proposal id observed from the backend: tweet-argument-analysis-20260604-48830a3731
• The original workshop lifecycle calls (apply, then later reject) timed out in the agent turn.
• The skill was then manually installed at skills/tweet-argument-analysis/SKILL.md.
• openclaw skills check showed the skill as ready/visible to the model.
• The Skill Workshop UI still showed the proposal as waiting, causing uncertainty about whether pressing Use it would overwrite or duplicate the already-active skill.
• A later backend check via skill_workshop list returned the same proposal as [rejected, create, clean], while the user had seen waiting in the UI. That suggests either stale UI/cache state or a lifecycle-status sync gap.

Expected behavior

One of these should happen automatically:

1. If a proposal's target skill name/path is already active, auto-resolve the proposal as applied/rejected/stale with a clear reason.
2. If auto-resolve is unsafe, show an explicit UI warning such as: A skill with this name is already active. Using this proposal may overwrite it.
3. Refresh/sync the proposal state after lifecycle actions time out or after the skills list detects the same skill as active.

Why it matters

The current state makes the user choose between Use it and Skip without knowing whether Use it will create a duplicate, overwrite the installed skill, or no-op. For a workshop feature meant to simplify skill creation, this is a sharp UX edge.

Suggested fix

• Add a reconciliation check between workshop proposals and active skills by normalized skill name/path.
• Mark orphaned/duplicate proposals as stale or resolved when an active skill with the same name exists.
• In the UI, disable Use it or require explicit confirmation when the target skill already exists.
• After failed/timed-out apply/reject, force a status refresh instead of leaving the previous waiting state visible.