Division packs
Division packs template Maestro's persona + role + order-type system for teams that don't run
a classic software-delivery lifecycle — Test Engineering, SecOps, Technical BA, DevOps, and
Operations/Business-Process-Automation, per the divisions investigated in
PLAN-PLN-MSO-2026-0371. A pack is data: a manifest plus optional persona, role overlays,
order templates, gates, and workspace defaults. Installing one requires no engine change and no
Python code.
What a pack is
Maestro's canonical 7 roles (PLN/BLD/TST/DOC/SEC/REL/LEAD) are generic delivery
archetypes, not software-specific job titles: plan, build, verify, document, audit, release,
and interactively partner. A division pack relabels and re-scopes those archetypes for a
different delivery process — e.g. a QA/test-automation division calls PLN the "Strategist"
and TST the "Explorer" — using the same overlay and order-template mechanisms every Maestro
workspace already has:
- Persona — renames roles, the product, and vocabulary throughout CLI output and prompts
- Role overlays — the same
.mso/config/roles/<CODE>.mdoverlay files, pre-written for the division - Order-type templates — division-specific order types (e.g.
TSD,AUT) with their own role sequence over the canonical archetypes - Gates — a division-appropriate default human-review gate config
- Workspace defaults — suggested verify command, per-role timeouts, and other workspace settings, merged in at install time
Nothing in a pack requires a code change. If a pack author needs something the engine doesn't support, that's a framework feature request, not a pack problem.
Pack anatomy
A pack is a directory. Only pack.json is required — everything else is optional and applied
only if present:
<pack-id>/
├── pack.json # required — manifest (id, displayName, description, tier, ...)
├── persona.json # optional — persona this pack activates
├── roles/ # optional — role overlays, e.g. PLN.md, BLD.md, TST.md
├── order-templates/ # optional — *-template.json files with a roleSequence
├── gates.json # optional — division default human-review gate config
├── workspace-defaults.json # optional — deep-merged into workspace.json
├── requirements/ # optional — order-description templates
└── QUICKSTART.md # optional — division onboarding doc
pack.json fields
| Field | Required | Type | Description |
|---|---|---|---|
id | Yes | string | Slug — lowercase, hyphens allowed. Must match the pack's directory name. |
displayName | Yes | string | Human-readable pack name. |
description | Yes | string | One-line summary of the division this pack templates. |
tier | Yes | free | team | enterprise | Licence tier required by mso init --pack. |
persona | No | string | Persona id this pack activates — a built-in persona id, or the id of a persona.json shipped alongside pack.json. Defaults to default (no persona file written). |
roles | No | array | Canonical archetype codes this division uses — a subset of PLN/BLD/TST/DOC/SEC/REL/LEAD. |
orderTypes | No | object | Division order types keyed by type code, each with a role sequence and optional description. |
scaffoldDirs | No | array | Extra workspace-relative directories to create at init time. |
verifyCommand | No | string | Suggested verifyCommand for this division, merged in at init if the pack ships no workspace-defaults.json that already sets it. |
Where each asset lands on mso init --pack
| Pack asset | Installed to |
|---|---|
roles/*.md | .mso/config/roles/ — ordinary role overlays |
persona.json (or a built-in persona id) | <workspace>/.maestro/config/persona.json — the persona-resolver location, distinct from the .mso/ artefact directory |
order-templates/*-template.json | .mso/orders/templates/ |
gates.json | .mso/config/gates.json (overwrites) |
workspace-defaults.json (and/or verifyCommand) | deep-merged into .mso/config/workspace.json — existing keys are preserved |
scaffoldDirs | created under the workspace root |
requirements/* | .mso/requirements/ |
QUICKSTART.md | .mso/QUICKSTART-<pack-id>.md |
A pack that ships nothing beyond pack.json (the built-in sdlc pack) leaves the workspace
byte-identical to a plain mso init — proof that the mechanism round-trips cleanly.
Built-in packs
Honest, at-a-glance fit — ratings and gaps as investigated in PLAN-PLN-MSO-2026-0371. None of
these are marketing copy: a pack that oversells its fit burns the first team that adopts it.
| Pack | Tier | Engine fit | Known gap |
|---|---|---|---|
sdlc | free | — (native) | none — this is the engine's default behaviour |
test-engineering | team | HIGH | none identified — pilot division, zero engine change required |
secops | team | MEDIUM-HIGH | live SIEM deployment out of scope (detection-as-code stops at the repo) |
tech-ba | team | MEDIUM | no Word/Confluence export — stakeholders who don't live in GitHub are an adoption risk, not an engine limitation |
devops | team | HIGHEST | none outstanding — the one real gap (generic pre-deploy gate) was closed by FTR-MSO-2026-0427 |
ops-bpa | team | MEDIUM | scoped to n8n only — no Power Automate / other external-SaaS adapter |
sdlc (pack #0)
tier: free. Formalises Maestro's own default software-delivery behaviour as a pack — the same
PLN→BLD→TST→DOC→SEC→REL process every existing Maestro workspace already runs. It ships only
its manifest: no role overlays, no persona file, no order templates. mso init without
--pack is equivalent to mso init --pack sdlc.
| Order type | Sequence | Description |
|---|---|---|
FTR | PLN → BLD → TST → DOC → SEC → REL | Feature |
BUG | PLN → BLD → TST → REL | Bug fix |
SEC | SEC → BLD → TST → REL | Security fix — review-first |
INV | PLN | Investigation — planning deliverable only |
PLN | PLN | Planner document |
DOC | DOC | Documentation only |
test-engineering
tier: team. A QA/test-automation division: risk-based test strategy, automation
implementation, exploratory gap-finding, and quality/release-readiness reporting.
| Archetype | Division title | Does |
|---|---|---|
| PLN | Strategist | Risk assessment, coverage-gap analysis, tooling choice (Playwright / pytest / k6) |
| BLD | Automator | Implements automation code in the test repo |
| TST | Explorer | Exploratory charters, session notes, gap-finding against the automation |
| DOC | Reporter | Coverage / quality / release-readiness reports |
| SEC | Auditor | Read-only test-quality and flaky-test audit (optional in a sequence) |
| Order type | Sequence | Use for |
|---|---|---|
TSD | PLN | Test strategy — a single-role planning deliverable |
AUT | PLN → BLD → TST | Automation — strategy refinement, implementation, gap-check |
EXP | PLN → TST → DOC | Exploratory charter — scope, execute, report |
QRP | TST → DOC | Quality report — assess, report |
The pack ships all five role overlays, four order templates, a review gate that pauses AUT
orders between the Strategist and the Automator for human review (mirroring the sdlc pack's
PLN → BLD gate), workspace defaults (a placeholder verify command, per-role timeouts, e2e
testing on by default), four requirement templates, an extra scaffold directory for QA
charters, and a division-specific quickstart doc.
Engine fit: HIGH. Automation code is repo-shaped and strategy docs/reports ride the artefact plane — this is why the pilot required zero engine change.
secops
tier: team. A SecOps division: threat intel, detection engineering, attack validation,
baseline/IaC hardening, and compliance reporting.
| Archetype | Division title | Does |
|---|---|---|
| PLN | Threat Intel Analyst | Intel briefs, ATT&CK-mapped threat modelling, prioritised backlog |
| BLD | Detection Engineer | Detection-as-code (Sigma/KQL/Splunk); also baseline/IaC hardening on HRD orders |
| TST | Attack Validator | Simulated triggers, detection unit tests, false-positive analysis, hardening regression checks |
| DOC | Compliance & Runbook Writer | Compliance reports (fed by the SEC audit on CMP orders), incident-response runbooks |
| SEC | Compliance Auditor | Read-only audit — the sole role on CMP orders before DOC writes the report |
| Order type | Sequence | Use for |
|---|---|---|
INT | PLN | Intel — threat intel brief, threat model, prioritised backlog (single-role planning deliverable) |
DET | PLN → BLD → TST | Detection — plan, detection-as-code implementation, attack-simulation validation |
HRD | PLN → BLD → TST → SEC | Hardening — baseline/IaC hardening plan, implementation, attack/regression validation, independent compliance audit |
CMP | SEC → DOC | Compliance — read-only audit feeding a stakeholder-facing compliance report |
IRP | PLN → DOC | IR runbook — incident scoping, step-by-step incident-response runbook |
The pack ships all five role overlays, five order templates, workspace defaults, five requirement templates, three extra scaffold directories for security intel/compliance/runbook reports, and a division-specific quickstart doc.
Engine fit: MEDIUM-HIGH. The SEC archetype's built-in read-only tool scoping is a
ready-made compliance-auditor posture, and detection-as-code is an industry-standard
repo-shaped deliverable.
This pack stops at versioned detection-as-code in a repo. Pushing a detection rule into a running Splunk/Sentinel/Elastic instance is out of scope until a deliverable adapter exists — tracked as demand-driven future work, not part of this pack. Don't represent it as covering live detection deployment to a SecOps team evaluating it.
tech-ba
tier: team. A Technical Business Analyst division: stakeholder elicitation, process mapping,
spec writing, and requirements validation — content only, no test automation.
| Archetype | Division title | Does |
|---|---|---|
| PLN | Elicitor | Stakeholder question capture, scope analysis |
| BLD | Process Mapper | BPMN/Mermaid process maps, committed as docs-as-code |
| DOC | Spec Writer | BRD/FSD documents |
| TST | Validator | Traceability matrix, walkthrough scripts, AC verification |
| Order type | Sequence | Use for |
|---|---|---|
ELC | PLN | Elicitation — a single-role planning deliverable |
MAP | PLN → BLD | Process map — scope confirmation, then the diagram |
SPC | PLN → BLD → DOC → TST | Spec — scope, map, BRD/FSD, traceability + AC validation |
VAL | TST | Validation — a single-role deliverable, standalone or against a prior SPC |
The pack's delivery model is a content repo: process maps and specs are Markdown files with
embedded Mermaid diagrams, committed alongside the code they describe — Mermaid/Markdown render
natively on GitHub, so the PR that adds a diagram or spec becomes the stakeholder-review
artefact. The pack ships all four role overlays, four order templates, a review gate that
pauses SPC orders after the Elicitor for human scope approval, workspace defaults (markdown
lint + Mermaid render check as verifyCommand), four requirement templates, an extra scaffold
directory for traceability reports, and a division-specific quickstart doc.
Engine fit: MEDIUM. Fits the everything-as-repo model cleanly — but the adoption risk is organisational, not technical.
Most non-technical stakeholders live in Word documents and Confluence spaces, not GitHub. This
pack does not solve that gap — a BRD/FSD → Confluence/.docx export/sync adapter is
demand-driven future work, not part of this pilot. Don't represent this pack as solving the
"get it in front of stakeholders" problem — it solves authoring and traceability, not
distribution.
devops
tier: team. A DevOps division: infra planning, Terraform/Helm/pipeline implementation,
terraform plan/policy/smoke-test validation, and controlled deploys.
| Archetype | Division title | Does |
|---|---|---|
| PLN | Infra Planner | Architecture, capacity, change plans |
| BLD | Pipeline/IaC Builder | Terraform/Helm/pipeline code |
| TST | Change Validator | terraform plan, policy checks (checkov/OPA), smoke tests |
| DOC | Runbook Writer | Operational runbooks, dashboards-as-code documentation |
| REL | Deployer | Controlled rollout, environment promotion |
| Order type | Sequence | Use for |
|---|---|---|
INF | PLN → BLD → TST → REL | Infra — change plan, IaC implementation, plan/policy/smoke-test validation, controlled rollout |
PIP | PLN → BLD → TST | Pipeline — CI/CD pipeline change plan, implementation, policy/dry-run validation. No REL — a pipeline change ships via PR merge |
OBS | PLN → BLD → DOC | Observability — signals/alerting plan, dashboards-as-code implementation, runbook + dashboard documentation |
The pack ships all five role overlays, three order templates, a schema-v2 gates.json with
two active gates — the legacy planning gate (PLN → BLD) plus a transitions["*->REL"]
pre-deploy gate with no priority exemption, so no infra change deploys to a real environment
without explicit human approval — workspace defaults, three requirement templates, and a
division-specific quickstart doc.
Engine fit: HIGHEST. Everything is already a repo and verifyCommand maps directly onto
terraform validate / policy checks. This is the one division where the pilot's original gate
gap (no generic pre-deploy human gate) mattered enough to require an engine change — the
per-transition gates schema closed it, so DevOps has no outstanding known gap.
ops-bpa
tier: team. An Operations/Business-Process-Automation division: as-is/to-be process
discovery, automation-candidate scoring, and export-as-code (n8n) workflow automation.
| Archetype | Division title | Does |
|---|---|---|
| PLN | Process Discoverer | As-is/to-be process analysis, automation-candidate scoring, n8n tooling-scope check |
| BLD | Automation Builder | n8n workflow implementation, delivered as versioned JSON exports in git |
| TST | UAT Runner | UAT case execution against the deployed workflow, evidence capture |
| DOC | Runbook Writer | Operating procedures, failure playbooks |
| Order type | Sequence | Use for |
|---|---|---|
DSC | PLN | Discovery — as-is/to-be process analysis and automation-candidate scoring (single-role planning deliverable) |
WFL | PLN → BLD → TST → DOC | Workflow — discovery refinement, n8n implementation, UAT execution, runbook authoring |
The pack ships four role overlays, two order templates, a review gate pausing WFL orders
between the Process Discoverer and the Automation Builder (the deliverable exports into an
external SaaS and is not trivially reverted once deployed there), workspace defaults, two
requirement templates, an extra scaffold directory for UAT/runbook reports, and a
division-specific quickstart doc.
Engine fit: MEDIUM. Workflow-export-as-code works well for n8n specifically, because its CLI export/import commands give a clean round trip onto Maestro's git/PR delivery model.
This pack does not build a Power Automate (or other external-SaaS) adapter. Power
Automate's deliverable is a solution .zip with no comparably clean export/import/verify CLI
loop — supporting it means writing a genuine deliverable adapter, deferred as demand-driven
future work. Practical effect: the Discoverer's Tooling Scope Check must flag any
Power-Automate-only automation candidate as out of scope, and the Builder must raise a blocker
rather than attempt a Power Automate build. If your organisation's automation candidate
genuinely requires Power Automate or another adapter-less SaaS, this pack is not yet the right
tool for it.
Command reference
mso packs list
mso packs list
Pack Tier Access Description
---- ---- ------ -----------
devops team upgrade Infra planning, Terraform/Helm/pipeline implementation, terraform-plan/policy/smoke-test validation, and controlled deploys — ...
ops-bpa team upgrade As-is/to-be process discovery, automation-candidate scoring, and export-as-code (n8n) workflow automation — ...
sdlc free yes Maestro's built-in software-delivery process — the default behaviour, formalised as pack #0.
secops team upgrade Threat intel, detection engineering, attack validation, baseline hardening, and compliance reporting — ...
tech-ba team upgrade Stakeholder elicitation, process mapping, spec writing, and requirements validation — ...
test-engineering team upgrade Risk-based test strategy, automation engineering, exploratory testing, and quality reporting — ...
The Access column is yes for free packs and for non-free packs when the current licence
already meets the required tier; otherwise it reads upgrade.
mso packs show
mso packs show test-engineering
mso packs show test-engineering --json # raw pack.json manifest
Prints the manifest fields, the order types with their role sequences, and an anatomy
block showing which optional assets the pack actually ships on disk (persona.json, role
overlays, order templates, gates.json, workspace-defaults.json, requirements/,
QUICKSTART.md).
mso packs validate
mso packs validate # every built-in pack
mso packs validate sdlc # one built-in pack by id
mso packs validate --path ./my-pack # an arbitrary directory, e.g. while authoring
Validates a pack's entire asset set — manifest, role overlays, persona, order templates,
gates, and workspace defaults — not just the manifest schema check that loading a pack already
performs. Exit code 0 if everything is valid, 1 otherwise, so it drops straight into a
pack-authoring CI step:
mso packs validate --path ./my-pack || exit 1
Output is grouped per pack under a [pack-id] header; every checked file prints ok <path> or
INVALID <path> followed by its diagnostics — the whole pack is checked in one run, not
fail-fast on the first bad file. Role overlay files are validated through the exact same code
path as mso roles validate, so the two commands never drift apart.
All six built-in packs (sdlc, test-engineering, secops, tech-ba, devops, ops-bpa)
pass mso packs validate cleanly — $schema / schemaVersion / _notes metadata keys in a
pack's gates.json are recognised and skipped rather than mistaken for gate objects, and the
devops pack's schema-v2 transitions map is checked through its own dedicated validation.
| Asset | Check |
|---|---|
pack.json | Manifest-schema check |
roles/*.md | Same overlay-validation path as mso roles validate |
persona.json (if shipped) | Persona schema; if absent, the manifest's persona id must resolve to a real built-in persona |
order-templates/*-template.json | Requires an order type, a non-empty role sequence, and a description placeholder |
gates.json | Every gate entry (metadata keys skipped) must be an object; enabled, if present, must be boolean. Schema v2's transitions map is validated per <FROM>-><TO> entry. |
workspace-defaults.json | Must be a JSON object |
mso init --pack
mso init --project QA1 --pack test-engineering
Runs a normal mso init, then layers the pack's assets on top. Omit --pack (or pass --pack sdlc) for the default SDLC workspace.
# Default SDLC workspace — byte-identical
mso init --project MYPROJ
mso init --project MYPROJ --pack sdlc
# Team/Enterprise-tier division pack
mso init --project QA1 --pack test-engineering
# Trial a non-free pack without a Team/Enterprise licence
MAESTRO_SKIP_AUTH=1 mso init --project QA1 --pack test-engineering
Tiers and licensing
tier: free packs (the built-in sdlc pack) install at any licence tier. tier: team and
tier: enterprise packs — all five division packs (test-engineering, secops, tech-ba,
devops, ops-bpa), every one shipped at tier: team — are gated through the same licence
check every other Team/Enterprise feature uses — mso init --pack <non-free-pack> exits
non-zero without a sufficient licence, printing an upgrade message.
For local trial without activating a licence, set MAESTRO_SKIP_AUTH=1 — the same escape
hatch used everywhere else in Maestro for CI and offline development.
Authoring your own pack
There's no mso packs create scaffolding command yet — author a pack directory by hand,
validate it as you go, and reference it with --path.
- Start with the manifest — write
pack.jsonwithid,displayName,description, andtier, then validate it alone:mso packs validate --path ./my-division. - Write role overlays (optional) — each
roles/<CODE>.mdfile is an ordinary role overlay. Dump the core role to start:mso roles show PLN --core > my-division/roles/PLN.md, set"extends": "core", and chooseextend/override/replaceper section. Division packs typicallyreplacemost prose sections andextendlist sections. - Write order-type templates (optional) — each
order-templates/<TYPE>-template.jsonneeds an order type, a non-empty role sequence, and a description placeholder. - Add gates, workspace defaults, requirements, and a quickstart (all optional) — gates reuse the engine's existing gate keys (a pack can't invent new ones); workspace defaults deep-merge; requirement templates and the quickstart are plain files.
- Validate the whole pack:
mso packs validate --path ./my-division— fix everyINVALIDline; the command checks everything in one pass. - Try a full init against a scratch workspace:
MAESTRO_SKIP_AUTH=1 mso init --project TRY --pack ./path/to/my-division(built-in pack ids resolve from the pip package's ownpacks/directory — trialling a pack authored outside it currently means copying or symlinking it in, ahead of a futuremso packs install <path>command).
Common pitfalls
- Pack id doesn't match its directory name — loading a pack rejects it if
pack.json'sidfield doesn't match the containing directory's name. - Non-free tier with no persona/role overlay content — a manifest alone passes schema
validation, but a paid-tier pack with nothing else provides just a persona rename.
mso packs show <pack>'s anatomy block makes this obvious at a glance. personaid with no matching persona — if a pack names a non-defaultpersona and ships nopersona.json, that id must resolve to a real built-in persona ormso packs validateflags it.- Pack requirement templates aren't auto-discovered by
mso order --template— they land at.mso/requirements/on init, but the custom-template resolution path currently reads a different directory. Use them as copy-paste references for now. - The tier gate applies to
mso init --pack, notmso packs show/list— listing and showing packs never require a licence; only scaffolding a non-free pack does.
See also
- CLI reference — full
mso packsandmso initflag reference