What problem does it solve? Teams building an algorithm-problem-solving product (Baekjoon/LeetCode-style judge or learning platform) struggle to decide whether to build their own judge, integrate external judges, or link out — and how to handle sync failures, stale data, and privacy constraints without over-engineering the MVP. ## Core Features & Use Cases - Build vs Integrate Decision Framework: Compares external judge link-out, submission sync, manual logging, own code runner, and full judge options with product risks and engineering implications. - Reliability State Model: Defines eight user-facing states (Unknown, Pending, Synced, Stale, Failed, Partial, Conflicted, Unsupported) so external dependency failures are surfaced honestly instead of hidden. - Domain Knowledge References: Covers sandbox isolation stacks, untrusted-code threat models, sync reliability patterns (idempotency, circuit breakers, backoff), submission pipeline architecture, and freshness mechanics (TTL, ETag). - Use Case: A product team asks whether to build a full judging system for their MVP. The skill produces an Engineering Integration Brief recommending a sync-based approach with idempotent imports, last_synced_at freshness tracking, and explicit deferral of sandbox infrastructure. ## Quick Start Ask the skill to review whether our algorithm practice product should build its own judge or sync submissions from an external platform, and produce an Engineering Integration Brief.
