Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →okhp3/okhp3-google-gis-client-auth
OverKill Hill P³ client-only Google Identity Services (GIS) auth workflow.
Passed 13 of 18 test cases with the skill, and 10 of 18 without it.
and 3 more in the full report
5 fixed11 passed either way5 still failing1 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 5 test cases the skill fixed. Same model, same prompt, with and without the skill.
We want our React single-page app to retain Google authentication tokens across browser reloads so users stay signed in forever without popups. Configure the storage mechanism for the token. Provide a handoff summary listing target origins, client ID source, permissions, and storage key configurations, as well as changed files, validation steps, secret/backend confirmations, and manual console checks.
| Checked | Without skill | With skill |
|---|---|---|
| Uses sessionStorage to persist token data | Missed | Passed |
| Rejects persisting access tokens in localStorage | Missed | Passed |
The instructions your model reads when the skill loads.
OverKill Hill P³ · overkillhill.com · github.com/OKHP3
Intent: Give a static-site agent a reliable GIS token lifecycle for Google API read flows without inventing a backend or leaking a Client Secret.
| In scope | Out of scope |
|---|---|
| GIS popup token model and GCP Web Application setup | Authorization code flow, refresh tokens, or offline access |
React/TypeScript useGoogleAuth lifecycle | Service accounts, non-Google identity providers, or multi-tenant servers |
| Calendar and Tasks read requests with Bearer tokens | Calendar/Tasks create, update, or delete operations |
| Expiry buffer, silent re-auth, consent fallback, and reconnect UI | Provider-specific write logic or product data persistence |
LifeTrkr boundary: This skill covers authentication and read flows. Keep
repo-specific write operations in src/lib/google.ts when that integration
boundary exists; LifeTrkr currently splits the same boundary across
src/lib/googleCalendar.ts and src/lib/googleTasks.ts. Do not move writes into
the auth hook or invent a new backend.
Before editing, identify the host origins, existing GIS script, client-ID source, requested read scopes, auth hook location, and existing Google API modules. Record the smallest scope set that satisfies the request. Treat the following as the repo defaults, not universal names:
| Option | LifeTrkr default | Porting rule |
|---|---|---|
| token storage | browser sessionStorage | Allow an injected Storage implementation only when required |
| token key | gal_token | Configure one key and use it for read, write, validity, and revoke paths |
| expiry key | gal_expiry | Configure one key and store an absolute epoch-millisecond expiry |
| expiry skew | 120_000 ms | Keep a safety buffer; make it configurable for a different latency budget |
| client ID | VITE_GOOGLE_CLIENT_ID | Keep it public, environment-backed, and never replace it with a secret |
When porting, pass storage, tokenKey, expiryKey, and expirySkewMs through
test cases passed, vs 10 / 18 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.