This catalog describes packaged workflow kits for operators and buyers. The Agent Lab runtime also seeds a separate suite of 10 live autonomous workflows into every workspace. See Autonomous runtime workflows for that set.
What a workflow kit contains
Every kit follows the same folder shape so operators know exactly where to look. A typical kit includes:README.md: packaging status and registry metadata for the workflow.kit.md: the operative manifest that governs the kit (see The kit/1.0 manifest).automation/: blueprint files for Make.com, n8n, or other runtimes when the workflow is automated.trackers/: Excel or CSV tracker templates the workflow relies on.source/: reference documents extracted from the original workflow source.
kit.md is the file to open first. It carries the trigger, owner, cycle time, inputs, setup steps, validation checklist, and change log for the workflow.
The kit/1.0 manifest
Every kit is described by a YAML frontmatter block at the top ofkit.md that conforms to the kit/1.0 schema. The manifest is what makes a kit reproducible and reviewable, not just a folder of files.
A representative manifest looks like this:
workflowIdanddepartment: where the kit lives in the catalog.triggerandcycleTime: when to run it and how often.primaryOwner: who is accountable for outcomes.automationLevel: rough share of the workflow the automation handles.statusandconformance: how mature the kit is (see below).changeLog: dated entries for every meaningful change to the kit.
Kit status: Draft, Active, and Certified
Kits move through three status levels. Do not treat a lower-status kit as if it were higher. The differences are about how much evidence backs the kit, not just how polished it looks.README.md in each kit calls out the current packaging status. kit.md records the same status in frontmatter and expands on what still blocks certification.
Two package variants
Most kits eventually split into two variants:- URC/internal package: runs the internal operating system and may keep internal roles, tools, and targets.
- Client-facing package: scrubbed of internal specifics and safe to hand to a buyer.
The seven series
Kits are grouped into seven series, one per department. Each series uses a stableXXX-NN slug so operators can reference a workflow without ambiguity.
Each series follows the same numbering convention, so
MKT-06 always means Content Creation & Dissemination, and SAL-01 always means Proposals & Contracts. Reference kits by that ID in commit messages, change control entries, and cross-workflow handoffs.
How to navigate the catalog
Start from the problem you are trying to solve, not from the folder listing.- If you are a buyer, read the department-level series that matches your pain. Open the specific kit whose
triggermatches when you would actually run it. TheautomationLevelfield tells you how much of the workflow is automated versus manual. - If you are an operator, open
kit.mdfirst and work through Setup and Quickstart. Only dive intosource/,automation/, ortrackers/when the manifest points you there. Record every meaningful change through the change log in the manifest and the change control register. - If you are certifying a kit, walk the Validation checklist in
kit.md. Confirm the manifest’sstatusandconformancereflect reality. Split the URC/internal and client-facing variants before promoting the kit to Active or Certified.
The flagship: Founder Signal System
Themarketing-founder-signal-system kit is the flagship starter package. It is a thin vertical slice across six Marketing workflows (MKT-01, MKT-02, MKT-03, MKT-04, MKT-05, and MKT-06) aimed at solo founders and small service-based businesses.
The flagship is a Draft kit today. It is the first sellable cut while the underlying Marketing kits are still being converted. It deliberately excludes paid advertising (MKT-07), social media management (MKT-08), and event marketing (MKT-09). Use it as a template for how to package future cross-series bundles.
