compass-calendar: Skill for Codex

When

Before a production release, or when asked for exploratory / chaos testing.

Steps

Prepare → happy path → focused probes → diagnose/fix → simplify/review/ship.

Output

Evidence of signed-in exercise plus shipped fixes, or a report of stops.

Pass

Happy path worked; probes were focused; credentials were not entered by the agent.

Anti-patterns

Do not enter credentials. See anti-patterns.md.

Escalate

Auth/setup missing, production-only defect, or a product fork.

Chaos

Treat a real, existing signed-in profile as an observation and interaction surface—not a source for credentials, cookies, tokens, or private data. Build confidence from visible behavior and reproducible evidence, then make the smallest fix that removes a confirmed defect.

Boundaries

• Target local development or an explicitly named non-production environment. Never probe production, payment flows, or third-party systems by default.
• Verify the selected account visibly before mutating data. If the expected test account is unknown, ambiguous, or not signed in, stop and ask the user.
• Use unique, clearly test-labelled records. Preserve pre-existing records; remove only records created by this run through the normal recoverable UI, then reload to confirm cleanup persisted.
• Do not enter credentials, grant/revoke OAuth, change account/security settings, bypass browser security warnings, or perform irreversible actions. Report those cases with a safe manual reproduction instead.
• Bound adversarial testing: do not use load generation, fuzz external APIs, scrape data, bypass authorization, or test other users' data. Test only the current account and normal product surfaces.
• Treat an exception, failed request, data loss, stale UI, inaccessible flow, privacy exposure, or significant interaction latency as a finding even when the UI appears to complete the action.

1. Prepare the test surface

1. Read AGENTS.md, inspect the current branch and diff, and identify the release-critical and recently changed user-visible flows.
2. Read the relevant acceptance docs and tests. Follow docs/development/local-development.md if the required local services or configuration are not healthy.
3. Select the best available real-browser surface that holds the signed-in test session. Honor an explicitly requested browser. Prefer a user-connected browser or Chrome session for authenticated flows; use Computer Use only when a browser-specific tool cannot perform the required visible action. Use isolated Playwright only for repeatable coverage that does not require the real account.
4. Navigate to the named environment, identify the account from rendered UI, and record the target URL, browser surface, account state, and baseline console/network condition. Do not inspect browser storage, cookies, or passwords.
5. If the selected environment or session is not suitable, stop with the exact setup needed. Do not substitute anonymous coverage for an authenticated pass.