ota

Hi HN, We're building Ota. Ota is open repo readiness infrastructure. It makes software repositories runnable and trustworthy for human, CI, and AI agents. The problem we kept seeing is that the real truth of how a repo gets set up and run is usually scattered across READMEs, scripts, CI config, env files, and maintainer memory. That slows onboarding, causes local and CI drift, and makes automation brittle. Ota gives each repo one explicit operational contract for what it needs, how it becomes ready, and how tasks should run. The core flow is: - `ota doctor` to diagnose what is missing - `ota up` to prepare the repo - `ota run` to execute named tasks from the contract The product idea is "doctor first, contract second." We want it to be useful even before a repo is perfectly modeled. What we're trying to build is not just another task run

I think AI-readiness needs to be more operational than just better docs and cleaner patterns. In a large monorepo, the agent needs to know which commands are safe to run, which package or app a change belongs to, what setup is required, what tests validate that area, and what "ready" means for that path through the repo. `CLAUDE.md` can help, but I would not make it the only source of truth. It can drift like a README. The stronger pattern is to make the repo's operational expectations explicit in a structured way, then let humans and agents consume the same source of truth. A few practical things I'd look at: clear ownership boundaries inside the monorepo, an obvious setup and verification path for each major package or app, standardized task names where possible, explicit safe commands and expected validation steps This is very close to

Source Code: https://github.com/ota-run/ota