Readiness check
Point the readiness check at a GitHub repository and see, before you create a project or install anything, which of the three first-upload paths already fits — or exactly what's missing.
What it reads
The check inspects repository metadata and file contents only, through GitHub's own REST API: CI workflow configuration, dependency manifests (for a configured JUnit-shaped reporter or a recognized feature-flag SDK), and existing files (for a ReleaseTwin case file). It never clones the repository, installs dependencies, or runs any command from it.
Public vs. private repositories
- A public repository can be checked anonymously — no account, no authorization.
- A private repository needs a signed-in session and its own, separate GitHub authorization — distinct from any other GitHub connection on your account, and scoped to read only the specific files this check inspects.
- That authorization is used only for the single check request and is discarded immediately afterward — never written to storage, never logged, and never reusable by another connection.
What the verdict means
The verdict reports two things independently: whether any evidence can be ingested at all (mapping to the authored-case or JUnit-upload first-upload path, or naming what's missing), and, separately, whether a recognized feature-flag SDK was found. A repository using an unrecognized or homegrown flag system reads as "not detected", never as "unsupported" — the check recognizes a fixed, growing list of SDKs, and a gap in that list is a detection limit, not a product one.
What it doesn't do yet
This is a static check, not a dry run: it doesn't execute your test suite to confirm a detected reporter actually produces output, and it doesn't open a remediation pull request for a detected gap. Installing the ReleaseTwin GitHub App and connecting a project are separate steps this check doesn't perform on your behalf.