Crewship manifest reference

The manifest is Crewship’s declarative deployment surface: a YAML (or JSON, since JSON is YAML 1.2) file that captures every user-creatable entity as data. One crewship apply --file foo.yaml (or crewship apply --dir ./manifests/) converges the workspace to match. crewship export workspace round-trips back. This page is the index. Per-kind details live in docs/manifest/<kind>.md.

Why manifests

GitOps for Crewship. Commit a manifest to git, deploy to dev / staging / prod from CI. No clickops drift.
Sharing without screenshots. Send a workspace YAML to a teammate; they apply it and have an identical setup.
Reproducible disasters. Backups + export = a complete restore path.
Less surface for human error. YAML linting + manifest validation catch typos before they reach the server.

Kinds at a glance

Every document has the shape:

apiVersion: crewship/v1
kind: <Kind>
metadata:
  name: <human-readable>
  slug: <kebab-case, unique within workspace>
spec:
  ...kind-specific...

Workspace structure

Kind	What it is	Lifecycle	Doc
`Workspace`	Top-level bundle: credentials + skills + crews	full CRUD	workspace.md
`Crew`	One crew: agents + sidecars + MCP servers + credentials	full CRUD	crew.md
`Agent`	Single agent within a crew (used inline under `Crew.spec.agents` or standalone)	full CRUD	agent.md
`Skill`	Skill registry entry (used inline under `Workspace.spec.skills`)	full CRUD	skill.md
`Integration`	MCP server integration (workspace-, crew-, or agent-scoped)	full CRUD	integration.md
`Issue`	Issue tracker row (rarely declared standalone — typically managed via the API/CLI)	full CRUD	issue.md
`Project`	Container for missions and milestones	full CRUD	project.md
`Label`	Tag for issues and missions	full CRUD	label.md
`Milestone`	Time-boxed project goal	full CRUD	milestone.md

Workflow + automation

Kind	What it is	Lifecycle	Doc
`Routine`	Workflow DSL (steps + schedules + webhook)	full CRUD	routine.md
`RecurringIssue`	Issue template + cron → periodic issue creation	full CRUD	recurring_issue.md
`TriageRule`	Match + actions for auto-routing incoming issues	full CRUD	triage_rule.md
`WorkflowTemplate`	Custom issue status flow (Kanban-style stages)	full CRUD	workflow_template.md

Views + ops

Kind	What it is	Lifecycle	Doc
`SavedView`	Shared filtered list (issues / missions / runs)	full CRUD	saved_view.md
`Page`	Dashboard of typed, permissioned panels that producers push into	full CRUD	page.md
`Hook`	Toggle for code-registered lifecycle hooks	enable/disable only	hook.md

Catalog references (install / deploy)

Kind	What it is	Lifecycle	Doc
`Recipe`	Install a recipe from the server catalog	install only	recipe.md
`CrewTemplate`	Deploy a crew from a template blueprint	deploy only (one-shot)	crew_template.md
`Connector`	Install an OAuth connector (Linear, GitHub, …)	install only	connector.md

Instance / org config

Kind	What it is	Lifecycle	Doc
`FeatureFlag`	Toggle experimental features (instance-default + per-workspace override)	full CRUD	feature_flag.md
`InstanceSetting`	Key/value config (SMTP, branding, …) — admin-only	full CRUD	instance_setting.md

Foreign-key references

Cross-kind references always use the slug of the referenced entity. The apply pipeline resolves slug → id after the dependency is created.

# Milestone references Project by slug
kind: Milestone
spec:
  project_slug: q2-roadmap   # ← resolves to projects.id

# RecurringIssue references Project + Labels + Crew by slug
kind: RecurringIssue
spec:
  template:
    project_slug: q2-roadmap
    labels: [recurring, status]
    crew_slug: my-crew

Apply order (topological)

crewship apply runs kinds in this order so dependencies are created before dependents:

Workspace credentials + skills (existing)
Crews + agents (existing)
Projects, Labels (no deps)
Milestones (deps: Projects)
WorkflowTemplates
FeatureFlags, InstanceSettings
Recipes, CrewTemplates, Connectors (catalog installs)
Routines (deps: Crews, Agents)
Schedules + Webhooks (nested in Routines)
RecurringIssues (deps: Projects, Labels, Crews)
TriageRules (deps: Projects, Labels, Crews)
SavedViews (deps: Labels, Projects)
Pages (deps: Crews, Agents, Routines)
Hooks (toggles only)

Apply modes

crewship apply --file foo.yaml                # ApplyUpsert (default): create/update/delete to match
crewship apply --file foo.yaml --strict       # Fail if any slug already exists
crewship apply --file foo.yaml --replace --yes # Destructive: delete existing, recreate fresh
crewship apply --file foo.yaml --dry-run      # Plan only — no mutations
crewship apply --dir ./manifests/             # Walk a directory; apply every YAML/JSON in topo order

Round-trip via export

crewship export workspace                     # everything in the workspace (multi-doc YAML)
crewship export workspace --output ws.yaml    # write to a file instead of stdout
crewship export crew uo-outlands              # the crew + everything labelled `crew: uo-outlands`
crewship export crew uo-outlands --no-skill-bodies  # slug-only skill references

CLI per-kind admin commands

Every kind also has a per-entity CLI surface for one-off operations (no manifest needed):

Kind	Command
Project	`crewship project list/get/create/update/delete`
Label	`crewship label list/create/update/delete`
Milestone	`crewship project milestone list/create/update/delete`
Routine	`crewship routine list/save/run/schedules/webhooks/...` (alias: `pipeline`)
RecurringIssue	`crewship recurring list/delete`
TriageRule	`crewship triage list/process`
SavedView	`crewship saved-view list/delete`
Page	`crewship page list/get/create/update/delete/set/grant/revoke`
WorkflowTemplate	`crewship workflow list/get/create/delete`
FeatureFlag	`crewship feature-flag list/enable/disable/inherit`
InstanceSetting	`crewship instance settings list/get/set/delete`
Hook	`crewship hooks list/enable/disable`
Recipe	(manifest-only — install via `crewship apply`)
CrewTemplate	`crewship template list/get/deploy`
Connector	(manifest-only — install via `crewship apply`)

Examples

examples/manifests/full-complete.yaml — one document per kind in one file
examples/manifests/full-team.workspace.yaml — multi-crew workspace (legacy shape)
examples/manifests/code-review.crew.yaml — single-crew (legacy shape)

What’s NOT in the manifest (and why)

Some entities are deliberately out of scope:

Entity	Why not
`missions`, `agent_runs`, `pipeline_runs`, `chats`	Runtime instances, not declarative state
`audit_logs`, `notifications`, `cost_ledger`	Telemetry, not config
`workspace_members`, `crew_members`	IAM lives in SSO / UI / CSV import, not YAML
`sessions`, `cli_pairings`, `oauth_states`	Ephemeral auth state
`backup_catalog`, `scheduled_jobs`	System runtime
`keeper_requests`, `approvals_queue`	Runtime instances of policies (policies themselves may land in a future `kind: ApprovalPolicy`)

Get Started

Guides

Security

Configuration

Manifest Reference

Overview

Crewship manifest reference

Why manifests

Kinds at a glance

Workspace structure

Workflow + automation

Views + ops

Catalog references (install / deploy)

Instance / org config

Foreign-key references

Apply order (topological)

Apply modes

Round-trip via export

CLI per-kind admin commands

Examples

What’s NOT in the manifest (and why)

See also

​Crewship manifest reference

​Why manifests

​Kinds at a glance

​Workspace structure

​Workflow + automation

​Views + ops

​Catalog references (install / deploy)

​Instance / org config

​Foreign-key references

​Apply order (topological)

​Apply modes

​Round-trip via export

​CLI per-kind admin commands

​Examples

​What’s NOT in the manifest (and why)

​See also

Crewship manifest reference

Why manifests

Kinds at a glance

Workspace structure

Workflow + automation

Views + ops

Catalog references (install / deploy)

Instance / org config

Foreign-key references

Apply order (topological)

Apply modes

Round-trip via export

CLI per-kind admin commands

Examples

What’s NOT in the manifest (and why)

See also