agentleFS
Sign inStart free
dzianisvdzianisv/opencode-mobile/.agents/skills/readiness-check/SKILL.md

readiness-check

Skill295 starsChanged 4 months agoMITView on GitHub

Verify OpenCode Mobile is PRODUCTION READY end-to-end. Triggers like "check production readiness", "are we ready to ship", "readiness check", "is opencode-mobile live", "is the app published". Runs a script that confirms both Google Play and F-Droid (self-hosted + mainline) are PUBLISHED and the app/site are healthy.

5 other projects use a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

1 rule. 0 are common, 0 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 5 edited versions we read keep these.

  • 0

    Distinctive

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    If, and only if, every REQUIRED gate passes, the verdict is PRODUCTION READY.

    line 20

“Common” is measured: kept by at least 6 in 10 of the 5 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

OpenCode Mobile — Readiness Check

Single command that answers one question: is OpenCode Mobile production ready?

"Production ready" has a precise definition of done:

  • The app is PUBLISHED on Google Play (cc.agentlabs.opencode).
  • The app is PUBLISHED on F-Droid mainline (f-droid.org/packages/cc.agentlabs.opencode).
  • The self-hosted F-Droid repo serves the latest APK.
  • The app builds and tests green (typecheck + node:test suite).
  • The web presence (landing, guide, privacy, sitemap, robots, OG image, QR codes) is all live.

If, and only if, every REQUIRED gate passes, the verdict is PRODUCTION READY.

How to run

From the repo root (the check is a TypeScript file run directly by Node — no build, no deps):

node .agents/skills/readiness-check/check.ts

Fast mode — skip the slow npm app-health gates, only check live published-status URLs:

node .agents/skills/readiness-check/check.ts --quick

Requires Node ≥ 23.6 (this repo runs Node 26), which executes .ts files natively via type-stripping — no transpile or extra dependencies. HTTP checks use the built-in fetch and JSON parsing is native, so there is no curl/jq/python3 dependency. git is used to locate the repo root and gh for the optional repo-discoverability gate; both degrade gracefully if missing (gate reports WARN/UNKNOWN, never crashes).

What it checks

Gates are grouped. REQUIRED gates decide the verdict; nice-to-have gates only WARN.

  • A. App health (REQUIRED, skipped with --quick)
    • npm run typecheck exits clean.
    • npm test passes.
  • B. F-Droid self-hosted repo LIVE (REQUIRED)
    • https://dzianisv.github.io/opencode-mobile/fdroid/repo/index-v1.json parses and contains cc.agentlabs.opencode; prints served versionName.
    • https://github.com/dzianisv/opencode-mobile/releases/latest returns 200/3xx.
  • C. F-Droid MAINLINE published (REQUIRED, headline)
    • https://f-droid.org/packages/cc.agentlabs.opencode/ returns 200. A 404 means not yet merged on f-droid.org → this gate FAILS. Do not confuse with the self-hosted gate (B).
  • D. Google Play PUBLISHED (REQUIRED, headline)
    • https://play.google.com/store/apps/details?id=cc.agentlabs.opencode returns 200 with a real store page. While in-review/draft it 404s → gate FAILS.
  • E. Web presence (REQUIRED)
    • landing /, /guide/, /privacy/, sitemap.xml, robots.txt, og.png, fdroid-qr.png, apk-qr.png under https://dzianisv.github.io/opencode-mobile/ all return 200.
  • F. Repo discoverability (nice-to-have, WARN only)
    • gh repo view dzianisv/opencode-mobile --json repositoryTopics,homepageUrl shows topics + homepage. Skipped gracefully if gh is missing/unauthenticated.

Interpreting results

Each gate prints one line: [PASS] / [FAIL] / [WARN] / [UNKNOWN] <gate> — <detail>.

The summary at the bottom is the answer:

  • PRODUCTION READY ✅ — every REQUIRED gate passed. Both stores are live, app and site healthy. Script exits 0.
  • NOT READY ❌ — at least one REQUIRED gate failed; the failing gates are listed. Script exits 1.

The two headline gates are D (Google Play) and C (F-Droid mainline) because "published on both stores" is the definition of done. Until Play review completes and the F-Droid mainline MR is merged, expect those two to FAIL and the verdict to be NOT READY — that is correct behavior, not a script bug.

UNKNOWN means a network/tool problem prevented the check (e.g. offline). UNKNOWN on a REQUIRED gate is treated as not-passing, so the verdict will be NOT READY.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free