berlinguyinca/autospec-baselines

Autospec-baselines is a collection of ready-made "playbooks" for software teams who use the Autospec ecosystem. Think of it as a library of blueprints that describe how to build specific types of applications, like a web app, an AI platform, or a data science project, following best practices from day one. Instead of starting from scratch to figure out what your project needs, you grab a pre-made pack that lays out the expectations, required features, and quality checks for your specific product type. The repository is organized into categories: application packs (covering domains like web, analytics, and financial integrity), technology packs (for specific tools like React, Python, and Postgres), testing packs, and AI packs (for things like RAG, local models, and external AI APIs). Each pack acts like a checklist that defines the purpose, required capabilities, quality gates, testing expectations, and documentation standards for that context. You mix and match these packs depending on what you are building, for example, a web-based AI product might layer together the web application pack, the React technology pack, the RAG AI pack, and a testing pack. This is designed for teams and founders who want a structured, opinionated starting point for defining what "done" and "quality" mean for a project, without writing all that policy from scratch. If you are launching a financial application, for instance, you could pull the financial integrity application pack alongside the Python and Postgres technology packs, and immediately have a set of standards covering security, compliance, and documentation that your team can build against. Notably, this repository is entirely documentation and does not contain any runnable code or automation tools. It is meant to be paired with the separate Autospec engine and constitution, where this project acts as the detailed instruction manual that sits between the high-level rules and the actual implementation work. When different packs have conflicting expectations, the project defaults to whichever rule is stricter, and any exceptions must be explicitly documented and owned by someone, with an expiration date.