Templates

Crewship provides two types of templates: crew templates (pre-configured teams with agents) and workflow templates (reusable mission execution patterns).

Crew Templates

Crew templates create a complete team in one step — a crew with pre-configured agents, roles, system prompts, and skill assignments. Deploy with crewship template deploy <slug> or the Settings UI.

Slugs, workspaces, and shadowing

A crew template is either built-in — shipped with the binary, seeded from embedded YAML, visible to every workspace — or workspace-owned, created inside one workspace and visible only there. Slugs are scoped accordingly:

Template kind	Slug must be unique across
Built-in	all built-ins (one shared catalog)
Workspace-owned	that workspace only

So two workspaces may both hold backend-team, and neither can see the other’s. A workspace-owned slug never collides with another tenant’s. A workspace template shadows the built-in of the same slug. When a workspace owns backend-team and a built-in backend-team exists, every by-slug operation in that workspace — template get, template deploy, the hire path, the onboarding wizard — resolves to the workspace’s version, and template list shows the slug once, as the workspace’s version. The more specific definition wins. Shadowing is why a customised template can keep the built-in’s slug: every existing reference to that slug picks up the workspace’s version, where renaming would break those references instead. Other workspaces are unaffected — they keep seeing the built-in, which is never modified, only hidden.

There is no supported way to author a workspace-owned template yet. The read path resolves and shadows them correctly, but the only crew-template routes are GET /api/v1/crew-templates, GET /api/v1/crew-templates/{slug} and POST /api/v1/crew-templates/{slug}/deploy — all read or deploy, none of them a write — and the only thing that writes the crew_templates table is the built-in seeder (internal/database/seed_crew_templates.go), which only ever writes is_builtin = 1 rows. No CLI command creates one either, and the manifest pipeline explicitly cannot: kind: CrewTemplate is deploy-only, see the manifest reference.So today a workspace-owned template is created out of band — a direct insert into crew_templates carrying that workspace’s workspace_id — and removed the same way. Deploy the built-in and edit the resulting crew and agents instead, unless you are the operator of the instance.

Seed Data Crews

The built-in seed data (cmd/crewship/seeddata/builtin/crews.yaml + agents.yaml) provisions three demo crews with seven agents total:

Engineering
Quality
Ops

Slug: engineering | Icon: terminal | Color: #3B82F6 (blue)

Agent	Role	Agent Role	Profile	Skills
Alex	Engineering Lead	LEAD	FULL	network-probe, script-runner, file-crafter, routine-author
Sam	Backend Engineer	AGENT	CODING	script-runner, file-crafter, system-inspector
Robin	Frontend Engineer	AGENT	CODING	file-crafter, web-scraper

Slug: quality | Icon: shield-check | Color: #10B981 (green)

Agent	Role	Agent Role	Profile	Skills
Jordan	QA Lead	LEAD	FULL	script-runner, file-crafter, routine-author
Casey	Test & Review Engineer	AGENT	CODING	system-inspector, script-runner, file-crafter

Slug: ops | Icon: server | Color: #EF4444 (red)

Agent	Role	Agent Role	Profile	Skills
Morgan	SRE / Ops Lead	LEAD	FULL	network-probe, system-inspector, routine-author
Riley	Platform Engineer	AGENT	CODING	web-scraper, script-runner, network-probe

Every seed agent runs the CLAUDE_CODE adapter. Skill assignments are the per-agent map in cmd/crewship/seeddata/skills.go (SkillAssignments); the catalog of five installable skills — network-probe, file-crafter, web-scraper, script-runner, system-inspector — lives in builtin/skills.yaml. routine-author is a bundled first-party skill installed on server startup (not in that catalog) and is assigned to each crew’s LEAD.

Agent Configuration

Each seed agent has these settings:

Setting	Default Value
LLM Provider	ANTHROPIC
LLM Model	claude-haiku-4-5
Memory Enabled	true
CLI Adapter	CLAUDE_CODE
Timeout (LEAD)	3600 seconds (1 hour)
Timeout (AGENT)	1800-2400 seconds (30-40 min)

System Prompts

Each agent has a dedicated system prompt file in cmd/crewship/seeddata/prompts/{prompt_slug}.md (the prompt_slug matches the agent slug — e.g. prompts/alex.md). These prompts define the agent’s persona, expertise areas, communication style, and behavioral guidelines.

Workflow Templates

Workflow templates define reusable execution patterns for missions. They are defined in internal/orchestrator/workflow.go and available via the sidecar at GET /mission/templates.

Built-in Templates

Sequential

Tasks execute one after another in order. Each step depends on the previous one.

step-1 --> step-2 --> step-3

Parallel

All tasks run simultaneously, then results are aggregated by a lead agent.

task-a --|
task-b --|-> aggregate
task-c --|

Dev-Test Loop

Developer implements, tester reviews. On failure, loops back (max 3 iterations). This is the Ralph Loop pattern.

develop <--(fail)-- test
(max 3 iterations)

Pipeline

Sequential preparation, parallel work streams, final aggregation by lead.

prepare -> work-a --|
        -> work-b --|-> finalize

Template Step Structure

Each template step defines:

type TemplateStep struct {
    ID            string   // Unique step identifier
    Title         string   // Human-readable step title
    AgentRole     string   // Role-based assignment ("developer", "tester", "lead")
    AgentSlug     string   // Or specific agent slug
    DependsOn     []string // Step IDs this depends on
    MaxIterations int      // Max retry attempts (0 = no retry)
    LoopBackTo    string   // On failure, restart from this step ID
}

Using Templates

A lead agent lists the available templates, then replicates the pattern it wants by shaping the mission’s tasks — /mission/create has no template field, so the lead expresses the dependency graph directly via each task’s depends_on and max_iterations (mirrors TemplateStep.DependsOn / MaxIterations). Both endpoints are served by the sidecar on :9119 (internal/sidecar/mission.go).

# List available templates (GET /mission/templates → orchestrator.ListTemplates)
curl -s http://localhost:9119/mission/templates

# Create a mission shaped like the dev-test-loop template
curl -s -X POST http://localhost:9119/mission/create \
  -H "Content-Type: application/json" \
  -d '{
    "title": "Implement auth module",
    "tasks": [
      {"title": "Write auth handlers", "assigned_to": "sam", "max_iterations": 3},
      {"title": "Test auth flow", "assigned_to": "casey", "depends_on": ["Write auth handlers"], "max_iterations": 3}
    ]
  }'

assigned_to is an agent slug within the caller’s own crew; use assigned_to_id (agent ID) to delegate cross-crew. crew_id in the request body is ignored — the sidecar always uses the trusted IPC crew identity.

Credential Templates

The seed data also includes credential templates in cmd/crewship/seeddata/credentials.go:

Anthropic Credential

ResolveAnthropicCredential reads SEED_ANTHROPIC_API_KEY (falling back to a demo-placeholder-* value when unset) and auto-detects the credential type from the value prefix:

Prefix	Type	Env Var Name
`sk-ant-oat`	`AI_CLI_TOKEN`	`CLAUDE_CODE_OAUTH_TOKEN`
Other	`API_KEY`	`ANTHROPIC_API_KEY`

GitHub Credential (optional)

ResolveGitHubCredential seeds a credential only when SEED_GITHUB_TOKEN is set. It is type CLI_TOKEN (not API_KEY) with env var GH_TOKEN — mounted into the container as a 0400 file plus an env var so the in-container gh CLI authenticates with zero extra setup.

Google Credential (optional)

ResolveGoogleCredential seeds a credential only when both SEED_GOOGLE_EMAIL and SEED_GOOGLE_PASSWORD are set. It is named GOOGLE_API_CREDENTIALS, stored as a JSON object ({"email":…,"password":…}) under the SECRET type.

Get Started

Guides

Security

Configuration

Manifest Reference

Templates

Templates

Crew Templates

Slugs, workspaces, and shadowing

Seed Data Crews

Agent Configuration

System Prompts

Workflow Templates

Built-in Templates

Sequential

Parallel

Dev-Test Loop

Pipeline

Template Step Structure

Using Templates

Credential Templates

Anthropic Credential

GitHub Credential (optional)

Google Credential (optional)

​Templates

​Crew Templates

​Slugs, workspaces, and shadowing

​Seed Data Crews

​Agent Configuration

​System Prompts

​Workflow Templates

​Built-in Templates

Sequential

Parallel

Dev-Test Loop

Pipeline

​Template Step Structure

​Using Templates

​Credential Templates

​Anthropic Credential

​GitHub Credential (optional)

​Google Credential (optional)

Templates

Crew Templates

Slugs, workspaces, and shadowing

Seed Data Crews

Agent Configuration

System Prompts

Workflow Templates

Built-in Templates

Template Step Structure

Using Templates

Credential Templates

Anthropic Credential

GitHub Credential (optional)

Google Credential (optional)