soia-env-workbuddy-install

WorkBuddy is a desktop application, and its installation path differs from Node/Python. First open the official site and download page, select the installer package for the corresponding system, and then have the customer complete system security prompts, login, and service authorization.

Customer-readable description

What this skill can do

Customer wants	Skill will do	Customer can see
Install WorkBuddy	Identify the system/architecture and open the official download and installation entry point	Official download link and installation status
Check for WorkBuddy updates	Identify the installed version, source, and signature; do not update automatically	Current version, latest version, and signature
Update WorkBuddy to the latest version	After the customer explicitly requests the latest version, follow the official update path	Intermediate status, signature, and startup verification
WorkBuddy won't open	Check the installation result, signature prompts, network, and version	Reproducible blocking category and next step
Can't log in	Guide login through the official interface	The customer completes authorization themselves and does not hand over the password

How the customer uses it

Other recognizable phrasings include "Update WorkBuddy to the latest version", "Install Tencent Lobster", and "WorkBuddy won't open".

Say "Install WorkBuddy" and specify the system; the Agent first confirms the system and chip architecture.
The Agent only uses the official workbuddy.cn download entry point and does not download DMG/EXE files from unknown sources.
If a new version is found when already installed, only report it; when only "Update WorkBuddy" is said, first ask whether to update to the latest version, and execute only after the latest version is explicitly chosen.
The customer completes opening, dragging, permissions, and login in the system installer; the Agent does not require the customer to use a terminal.
During installation or an explicitly authorized update, continuously display and record checks, plan, execution, verification, and final state.

First launch and real usability verification

The existence of application files only means "installed"; it does not mean login, service authorization, and the workspace are already usable.
After installation is complete, the Agent launches WorkBuddy, and the customer completes login, verification code, system security prompts, and service authorization in the official graphical interface; the Agent does not fill in the password on their behalf.
The Agent rechecks application startup, account status, and one side-effect-free workspace operation; if any of these steps is not completed, write the running status as "unverified" and the handling result as "waiting for first login/authorization", and do not falsely report "normal".

After installation

This skill is only responsible forthe client itself. Installing the SOIA skill into WorkBuddy is a separate matter, handled by soia-meta-skill-release — the customer saying "install into WorkBuddy" triggers it.

Dependencies and installation

No Node/Python dependencies. For the official entry point, currently visible platforms, and post-installation verification boundaries, see official-sources.md. When the network is abnormal, call soia-env-network-diagnose。

Standard process

Read-only identification of macOS/Windows, CPU architecture, installed application version, signature, and whether the current user can install applications; for Linux, first explain that the official desktop support scope is unverified.
Open the product download entry point on the official site: for macOS, distinguish ARM64/x64; for Windows, choose x64/compatible ARM64 version; do not guess the download URL.
Show the installation action and system permission impact; start the installer only after the customer confirms.
The customer completes security prompts, login, CAPTCHA, and privacy/service authorization in the official UI; the Agent does not fill these in on their behalf.
Verify app launch, version, or the "About" page; if only the installer package landing can be confirmed, clearly mark the remaining verification.

Installed status and updates

First check for an already existing app; when the status is normal, prompt "WorkBuddy is already installed, no need to reinstall", do not overwrite, do not uninstall, and do not treat downloading again as the default update method.

macOS: record the app version and installation location, and execute codesign --verify --deep --strict <WorkBuddy.app>; when available, then execute spctl --assess --type execute <WorkBuddy.app>。
Windows: record the version, publisher, and system security prompts in "Apps & features"; do not disable SmartScreen or antivirus software.
Installed and signature/publisher verification passed: first show the target version and impact; only after the customer explicitly requests updating to the latest, execute from the WorkBuddy official site or the in-app official update entry point.
App exists but signature verification fails, publisher is unknown, or version cannot be read: mark as invalid_signature or installed_unverified, address the source issue first, and do not prompt "installation normal".
WorkBuddy has no npm/CLI update path promised by this skill; do not use npm, unknown download scripts, or third-party mirrors to update.

Before updating, retain the old version, source, and verification results. If the update fails, retain the old version and error evidence; do not automatically uninstall, delete user data, or bypass system security policies.

An ambiguous "update WorkBuddy" only performs a version comparison and returns "waiting to confirm whether to update to the latest". Explicitly installing a missing WorkBuddy may install the official currently recommended version and is not considered updating an existing app.

Customer status list (mandatory)

Skill	Current status	Current version	Latest version	Running status	Update time	Handling result
WorkBuddy	<installed/not installed/blocked>	<version or not obtained>	<version or not obtained>	<normal/abnormal/unverified>		<no need to reinstall/updatable, not executed/waiting to confirm whether to update to the latest/updated/waiting for confirmation before installation/blocked: reason>

Output only the WorkBuddy row; do not add rows for Node.js, Python, npm, or other tools.
更新时间 Record the time after version, signature, and launch verification are completed.
When signature or publisher verification fails,运行状态 write "abnormal",处理结果 state the source blockage.
After the table, retain only the installation, login, or system security steps that must be completed by the customer in the official UI.

Intermediate states of installation and update

When actually performing installation or an update authorized to the latest version, use a random run_id to immediately call at the moment each stage actually occurs scripts/record_install_progress.py: record once before checking, after the plan is formed, before invoking the installer/updater, before signature and launch verification, and at the final state; record again when administrator privileges are required or the source is switched waiting_confirmation. Do not write after completion; timestamps are generated by the recorder. Read-only checks do not invoke it. Only when the customer's own words explicitly request the latest version does the update execution phase include --customer-requested-latest。

python3 scripts/record_install_progress.py --run-id <run-id> --action <install|update> --stage checking --status in_progress --result-code checking_started
python3 scripts/record_install_progress.py --run-id <run-id> --action update --stage updating --status in_progress --result-code update_started --customer-requested-latest

At the same time, continuously display the fixed phase table; on success, failure, cancellation, or waiting for a system operation, append the terminal state:

Phase	Current status	Update time	Processing result
<check/plan/wait for confirmation/install or update/verify/complete or fail>	<in progress/waiting/completed/failed/blocked>		<redacted result>

Permissions and rollback

Do not disable Gatekeeper, SmartScreen, antivirus software, or system security policies.
Do not delete the old version; if the old and new versions conflict, stop first and let the customer choose.
Uninstalling, clearing user data, or revoking authorization must be a separate request and cannot be an automatic rollback for an installation failure.

Private information and intermediate data

The WorkBuddy account, token, and session are kept only in the official client login state or the system credential store; the SOIA configuration stores only non-secret preferences.
During the install or update phase, use the progress recorder to append redacted actions, phases, results, and times; read-only checks are not written to disk by default.
Download metadata may be placed in the cache; installer and signature-check intermediate files are placed in the system temporary directory and cleaned up after success or failure.
Do not copy client user data, and do not record accounts, sessions, chat content, or customer private absolute paths.

Logs and completion receipt

| 技能 | 当前状态 | 当前版本 | 最新版本 | 运行状态 | 更新时间 | 处理结果 |
|---|---|---|---|---|---|---|
| WorkBuddy | <状态> | <当前版本> | <最新版本> | <运行状态> | <RFC3339-with-timezone> | <处理结果> |

Forward testing

Use platform fixtures to verify the selection logic for macOS ARM64, macOS x64, Windows x64, and unknown platforms; real acceptance must have the customer confirm the official installer and login page, and must not treat web page reachability as client availability.

Install the entire domain (Claude Code and Codex share the same domain plugin):

claude plugin marketplace add soia-team/soia-open-skills
claude plugin install soia-env@soia

Install only this one skill:

npx skills add soia-team/soia-open-env-skills -g -a '*' -s soia-env-workbuddy-install -y