Menú
Metabase analytics guidance for diplicity-react — native SQL patterns for multi-hop joins, base64 encoding workflow, and schema gotchas in the diplicity production database. Use when writing Metabase queries or working around schema limitations.
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
Django backend guidance for diplicity-react — views, serializers, models, permissions, constants, transactions, and codegen. Use when implementing or reviewing backend features, modifying the Django service, or debugging API behavior.
React frontend guidance for diplicity-react — components, state management, forms, data loading, routing, mock data, screenshots, and testing. Use when implementing or reviewing React features, refactoring frontend code, or taking PR screenshots.
Android Capacitor guidance for diplicity-react — build workflow, ADB setup, Firebase Cloud Messaging, Google Sign-In, keystore management, SHA-1 fingerprints, and Fastlane releases. Use when building, deploying, or debugging the Android app, or managing Android credentials.
iOS Capacitor guidance for diplicity-react — build workflow, Xcode project setup, APNs and ASC credentials, code signing strategy, Fastlane releases, and GitHub Actions. Use when building, deploying, or debugging the iOS app, or managing iOS credentials.
Production debugging guidance for diplicity-react — Railway CLI token conflict pattern, pgweb queries, write safety rules, and staging environments. Use when debugging production issues, querying the production database, or deploying PR staging environments.
Testing guidance for diplicity-react — frontend Vitest and backend pytest patterns, fixtures, conftest organisation, MSW mocks, and performance tips. Use when writing or running tests, setting up fixtures, or reviewing test code.
| name | metabase |
| description | Metabase analytics guidance for diplicity-react — native SQL patterns for multi-hop joins, base64 encoding workflow, and schema gotchas in the diplicity production database. Use when writing Metabase queries or working around schema limitations. |
| allowed-tools | Bash, Read, Glob, Grep |
Metabase MCP tools (query, construct_query) only support single-hop implicit FK traversal. For any query needing more than one FK hop, use native SQL.
Always write SQL to a file — never inline it in a shell command. Shell escaping corrupts SQL (= becomes :, DEL chars appear silently).
# 1. Write SQL to /tmp/query.sql via the Write tool
# 2. Encode
import json, base64
with open('/tmp/query.sql') as f:
sql = f.read().strip()
payload = {
'lib/type': 'mbql/query',
'stages': [{'lib/type': 'mbql.stage/native', 'native': sql, 'template-tags': {}}],
'database': 2 # production diplicity DB
}
encoded = base64.b64encode(json.dumps(payload).encode('ascii')).decode('ascii')
# 3. Always roundtrip-assert before using
decoded = json.loads(base64.b64decode(encoded))
assert decoded['stages'][0]['native'] == sql
print(encoded)
Use the base64 immediately in the next tool call — do not store it and reference it in a later message. The context window can corrupt long base64 strings between turns.
Always test with execute_query before create_question. If the query looks correct but execute_query fails with a syntax error, regenerate the base64 from the file rather than fixing the stored string.
To save to the root "Our analytics" collection, pass collection_id=null.
phase_phase.completed_at is always NULL — use status = 'completed' to identify resolved phasesphase_phase.updated_at is unreliable for time-bucketing — batch operations reset it, clustering all historical data in recent weeks. Use scheduled_resolution insteadphase_phase.scheduled_resolution IS NOT NULL is required — ~21% of phases have no deadline (manual-resolution games)phase_phase.started_at is always NULLphase_phasestate → phase_phase → game_game) require native SQL — implicit FK fails with "missing FROM-clause entry"