ops-and-scale-os

Ops & Scale OS

An open-source operating system for GTM engineering and AI ops, built as Claude Code skills.

The layer underneath the playbooks. Define the data model, build the enrichment and scoring pipelines, ship AI agents your team actually uses, prove the output is good, and fix the reporting nobody trusts. Twenty-six skills that assume the constraint is your systems rather than your strategy.

No app to host. No account. No database. Skills plus plain text in a workspace/ folder on your machine.

Why this exists

Most GTM content stops at the play. Run this campaign, build this sequence, target these accounts. Then you go to run it and the account list has three versions of the same company, nobody can say what "qualified" means, the enrichment bill tripled without explanation, and the AI agent somebody built two months ago has four users.

That gap is where the work actually is, and almost nobody writes about it.

This repo is the operating detail for that layer. It comes from building enrichment and scoring pipelines, shipping outbound copilots to working reps, running evaluation infrastructure over AI-generated marketing, and auditing stacks under CFO budget pressure.

Three beliefs run through every skill:

• The bottleneck is almost never the model. A very good agent pointed at bad data produces confident, well-written, wrong output faster than a person could. Diagnose the data layer before building anything on top of it.
• No system evaluates its own output. The context that wrote a thing is the worst possible judge of it, because it knows what it meant. The generator and the judge are separated at the architecture level, not by asking nicely.
• Guardrails are the product. An agent without spend ceilings, conflict checks, and a refusal set is a liability with a good interface. Any budget a user can burn, a user will eventually burn.

The 26 skills

Start here

• ops-and-scale-os – the router: reads the symptom, names the constraint, routes to one skill
• gtm-systems-audit – scores all four layers, returns the single constraint and a gated plan

Data plane – who is worth touching, and when

• data-model-and-sync – what an account is, the key, direction of truth per field, sync design
• tam-and-sourcing – size the universe before pulling it, reconcile before paying for it
• enrichment-waterfall – the free gate, cost-ordered tiers, verification, graceful exit
• icp-scoring-engine – fit and intent as separate axes, thresholds from the real distribution
• signal-pipeline – decay windows, dedup, severity thresholds, signal-to-play routing
• data-hygiene – normalize, dedup, merge, and a refresh queue driven by staleness
• credit-and-cost-control – forecast, ceilings that fail closed, cost per usable record
• warehouse-and-pipes – whether a warehouse is justified yet, and the layers if it is

Agent plane – what does the work

• agent-scoping – the refusal test, work classification, and the mandatory kill criterion
• context-portfolio – the ten-module operating manual every agent reads instead of guessing
• skill-authoring – trigger design, negative boundaries, context economy, the router pattern
• agent-guardrails – refusal sets, pre-checks, and putting hard limits where persuasion cannot reach
• ai-governance – shadow AI, the three-tier data boundary, disclosure rules, and the fear nobody names
• agent-rollout – packaging, first-run engineering, accountability, and the adoption numbers

Quality plane – is any of this good

• eval-spec-authoring – gates before scores, anchored dimensions, a frozen calibration set
• eval-loop – generate, judge independently, revise, re-judge, with every cycle logged
• eval-calibration – regrade the anchors, because a rising pass rate is ambiguous
• agent-observability – what to log, what to alert on, and diagnosing degradation in the right order

Systems of record – what is true, and who owns it

• martech-stack-audit – inventory, spend against revenue, the add test, verdicts with dollars and dates
• attribution-architecture – sourced, influenced, accelerated, and the rules that stop double counting
• lifecycle-and-routing – stages as exit criteria, deterministic routing, SLAs that get measured
• reporting-architecture – one definition, one owner, three layers, and the stop-reporting list

Gates – run on output regardless of layer

• writing-quality – strips the machine tells from anything a human outside the team will read
• artifact-eval – checks the deliverable against the failures its type is prone to

Quickstart

git clone https://github.com/guerrilla2799/ops-and-scale-os.git
cd ops-and-scale-os

Then, in Claude Code:

Read skills/ops-and-scale-os/SKILL.md and run the systems audit.

Full install options in INSTALL.md.

Cold start, in order: audit, then the object model, then hygiene, then scoring, then the context portfolio, then decide what agent deserves to exist.

The four layers

They stack, and each one fails in a way that looks like a problem in the layer above it.

Build order is systems of record, data, agents, quality. Fix order is data, systems of record, quality, agents. Most teams try to build agents first and then wonder why it does not work.

Full model in docs/architecture.md.

Docs

Reference stack

Opinionated because vague is useless. Every layer has documented swaps and a no-budget path in docs/stack.md.

The no-budget path is not a lesser version of the method. It is the same method by hand, and running it by hand first is the best way to find out whether it is worth automating.

What this is not

• Not a revenue operations library. Forecasting, quota, comp design, deal desk, CS operations, and renewals are deliberately out of scope. NEON-Rutger/B2B-revops-skills covers that layer well and the two compose cleanly.
• Not a playbook repo. It does not tell you which campaign to run.
• Not vendor-neutral. It has opinions. The swaps are documented so you can disagree specifically.
• Not a service. These are frameworks for self-serve implementation.

Benchmarks and numbers

Benchmarks in this repo are directional, drawn from growth-stage B2B software, and marked as such where they appear. Use your own history wherever you have it. Where a number is borrowed, the skills require you to label it as borrowed at the point of use rather than in a footnote, because an unlabeled benchmark becomes the company's own number by the second reading.

No client names, customer metrics, venues, or dollar figures appear anywhere in this repo. Every worked example is an anonymized composite.

License

MIT. See LICENSE.

Built by Brandon Redlinger · Stack & Scale