Whooper

WHOOP GPT setup and repair

Deliver a private, working WHOOP-connected GPT in the user's own account. Each user supplies their own WHOOP developer application and authorizes their own data. This skill is a reusable procedure and template bundle, not a hosted integration or a way around ChatGPT account restrictions.

Establish what is possible first

Inspect the target account and current official product guidance before creating developer resources. Reuse a user-selected existing GPT or WHOOP application when repairing a connection; do not create duplicates or overwrite unrelated configuration.

As checked on 2026-09-03, personal ChatGPT accounts cannot create or publish new GPTs, but eligible existing GPTs can still be edited. Managed workspaces have their own permissions. Recheck this at execution time. See the current ChatGPT guidance. If the account has neither an editable GPT nor creation permission, explain the blocker and offer the portable configuration files. Do not promise a working GPT, purchase a subscription, or switch products without the user's direction.

Use the available authenticated connector, API, or browser tools as appropriate. For browser work, follow that environment's browser skill and supported controls. This skill does not depend on a particular browser extension, operating system, tool name, or local path. Without account access, prepare the files and provide a precise manual handoff instead of claiming live setup.

Choose the relevant workflow

• For a new setup or incomplete OAuth configuration, read references/setup.md.
• For a failing connection, inspect its actual error and read the matching entry in references/troubleshooting.md.
• Read openapi.yaml when importing or adjusting the Action. GPT_INSTRUCTIONS.md is the coach prompt template.
• If a privacy page is needed, adapt assets/privacy-policy-template.md. The repository's root PRIVACY.md is the maintainer's existing policy, not a substitute for another operator's privacy notice.

Infer the user's preferred name and language from the conversation; whooper is a suggested name, not a requirement. Ask only for missing choices that affect the setup, such as which editable GPT to use or which privacy URL to publish. Reuse explicit authorization already given for the same action and data scope. Obtain any additional authorization required by the host environment when the recipient, scope, publication target, or access materially changes.

Invariants that prevent common failures

1. Importing an OpenAPI securitySchemes section does not configure ChatGPT's authentication UI. Explicitly select OAuth, enter the application credentials and endpoints, save that dialog, then save/update the GPT itself.
2. Register the callback shown in the GPT editor after OAuth is saved. Its identifier can differ from the identifier in the GPT editor's address bar. Do not treat an address assembled from the visible GPT ID as the verified callback. Follow current OpenAI guidance for both ChatGPT callback domains, keeping the displayed path identical and using no wildcard.
3. Keep the offline scope when continuing access is requested. ChatGPT manages access/refresh tokens; the developer Client Secret is not a bearer token.
4. Keep this integration read-only. Profile and body-measurement operations are optional; omit their operations and requested scopes consistently if the user only wants recovery, sleep, strain, and training.
5. Keep passwords, Client Secrets, access tokens, refresh tokens, and real health responses out of prompts, Knowledge files, source control, reports, and issue trackers. Enter credentials only into the intended authentication controls. User login and any required interactive consent happen on WHOOP's site.
6. Stop retrying when there is no new evidence. A login requirement, account restriction, blocked browser control, or approval requirement is a handoff, not a reason to invent credentials, bypass a restriction, or create another app.

Verify the result, not just the configuration

After the user completes WHOOP authorization, check the ChatGPT connection confirmation and make a small real Action call. For the standard coach, test recoveries, sleeps, cycles, and workouts sequentially with limit=1 and no date filters. Use the copyable test prompt in setup.md. Avoid profile/measurement reads unless those features need verification.

Use actual Action response evidence where available. A chatbot's claim that it "read the data" is not sufficient on its own. A successful empty collection is different from an authorization failure. Report only operation status, record count, and relevant date unless the user requests health analysis. Recovery records may require a linked sleep/cycle to establish the physiological date; do not silently use created_at as the recovery day.

Save the final GPT settings and open its normal user-facing chat. If verification was done only in the editor preview, say so or make one small call in the normal chat before claiming that surface works. Do not repeatedly retrieve the same health data after the connection has been sufficiently verified.

Report the actual final state:

• Ready: settings saved, authorization completed, real data request succeeded.
• Connected, no records: successful response, but no matching records exist.
• Configured, awaiting user: exact remaining login/consent step and its page.
• Blocked: concrete account/tool/provider restriction and the required next step.

Say refresh is configured when offline is enabled; do not say long-term token renewal was tested unless it actually was. Keep the GPT private unless public publication is explicitly requested and supported. Publishing this skill does not publish a GPT or grant anyone access to the maintainer's WHOOP account.