Word Fixer Onboarding

Guide the user through a managed Word Fixer setup until the installed app is ready to use.

This skill covers the macOS app. On Omarchy the setup is ./linux/install followed by ./linux/install --check (see README); the macOS steps below do not apply there.

Step 1: Inspect the current state

Start by checking the environment before proposing changes.

Inspect:

• repository root and expected project files
• whether pi exists at all
• whether ~/.config/word-fixer/ exists
• whether ~/.config/word-fixer/config.json exists
• whether ~/.config/word-fixer/.pi/SYSTEM.md exists
• whether global Pi auth exists at ~/.pi/agent/auth.json
• whether ~/Applications/Word Fixer.app exists
• whether /Applications/Word Fixer.app exists

Step 2: Summarize onboarding status

Report the current status as a short checklist before taking action.

Use this structure:

Word Fixer onboarding status
- Repo: present / missing
- pi: found at ... / missing
- Word Fixer config: present / missing
- Global Pi auth: present / missing
- Installed app: present at ... / not installed
- Accessibility permission: requires manual confirmation in System Settings

If something is missing, state the exact next action needed.

Step 3: Propose the next actions

Propose the smallest set of actions needed to finish onboarding.

Typical actions:

Do not perform config edits or installation until the user agrees. Word Fixer reads Pi's canonical auth file directly; do not copy OAuth credentials into its app-specific config directory.

Step 4: Execute approved actions

After the user approves, perform only the agreed actions.

Allowed actions include:

• run swift build, make build, make install, make install-system, or make reinstall
• create ~/.config/word-fixer/.pi/ if needed
• show the current config file and explain fields
• point the user to ~/.config/word-fixer/.pi/SYSTEM.md for prompt customization

Step 5: Guide macOS permission setup

Treat Accessibility permission as a manual checkpoint.

Tell the user:

• open System Settings -> Privacy & Security -> Accessibility
• enable the installed app path they are actually using
• prefer ~/Applications/Word Fixer.app if installed there
• avoid switching between swift run, dist/Word Fixer.app, and the installed app during permission setup

If the user reports odd behavior, ask them to verify the authorized app path first.

Step 6: Verify the app is ready

Before declaring success, verify what can be verified automatically.

Check:

• the app builds successfully if you ran a build
• the installed app exists if you ran install
• the config directory exists
• config.json exists and nodeBinaryPath points at the dedicated app-data Node link when install/bootstrap was part of the workflow
• ~/.local/share/word-fixer/sdk/ contains the locked app-owned SDK
• ~/.config/word-fixer/.pi/SYSTEM.md and settings.json exist
• ~/.pi/agent/auth.json exists when auth is required

Then give the user a final manual verification sequence:

1. Open the installed Word Fixer app
2. Confirm Accessibility permission is enabled for that exact app path
3. Select text in another app
4. Press the configured shortcut
5. Review the diff overlay
6. Press Enter to apply or Escape to cancel

Step 7: End with a clear outcome

End with one of these outcomes:

• Onboarding complete — all required setup is in place, with any remaining manual Accessibility check called out explicitly
• Blocked on pi installation — Pi runtime is missing
• Blocked on user confirmation — waiting to install or edit config
• Blocked on macOS permission — app is installed but Accessibility is not yet granted

Use concise bullets. Include exact file paths and commands actually used.