专为百度秒哒应用打造的SecondMe OAuth2登录和API集成工具，完成Connect to SecondMe OAuth2接入

This package is coherent for its stated goal, but follow these safety checks before deploying: - Treat SUPABASE_SERVICE_ROLE_KEY and SECONDME_CLIENT_SECRET as highly sensitive: configure them only in server/Edge Function secrets (e.g., supabase secrets), never commit to source or expose to the frontend. - Rigorously test Row-Level Security (RLS) in your Supabase project: authenticate as different users and confirm SELECT/UPDATE only returns each user's own profile row. If RLS is misconfigured, stored access_tokens could be exposed. - Consider whether the frontend truly needs direct access to the raw SecondMe access_token. If possible, proxy API calls through the Edge Function (server-side) to avoid giving tokens to client code. - Configure ALLOWED_ORIGINS strictly (do not use '*'). Verify the getAllowedOrigins/CORS implementation behaves as you expect in your deployment environment. - Review Edge Function logs and the token-exchange endpoint usage (https://api.mindverse.com...) to ensure tokens are obtained and stored exactly as intended; confirm that the skill is calling the official SecondMe endpoints for your integration. - The registry metadata had a formatting bug for the env listing — rely on SKILL.md and the template files to understand required env vars. - Perform a light code review of the Edge Function's use of supabase.admin APIs (listUsers/createUser/generateLink) and ensure it matches your Supabase plan/ACLs and that magic-link behavior meets your security requirements (token lifetime, revocation). If you are not comfortable managing high-privilege keys or verifying RLS/CORS yourself, involve a developer or security engineer before deploying to production.