Process
Every product company runs on processes.
Building a product is not a one-shot delivery. It is a continuous flow of work and adjustments — features get scoped, shipped, reviewed, and refined; bugs get triaged, fixed, regressed; releases get planned and rolled back. The processes already exist in your team. Ship makes them legible.
The problem
Invisible processes drift.
Most teams know how their work moves — but the knowledge lives in heads, in Slack threads, in the muscle memory of three senior engineers. When those heads change roles, the process drifts. When two people disagree, neither version wins. The process becomes folklore: real, but unreviewable.
What changes
Written-down processes can be improved.
A process you can read is a process you can argue about — and improve. Ship gives every workspace a place to write its processes down: the states, the order, the conditions, the people responsible. Once they are written, the work that follows them is trackable, and the work that breaks them is visible.
Step one
A workspace is a graph of processes.
Every Ship workspace holds a graph. The root node is the workspace itself; below it sit the processes the team runs. Today, every workspace ships with one live process — Development — and four drafted ones attaching to the same root. As more processes graduate from draft to production depth, the graph fills out.
Solid edge: live, running today. Dashed edges: drafted shapes attaching to the same workspace root.
Step two
Inside a process: states, routines, specialists.
Open one process and three named pieces do the work. They build on each other in this order — states first, then the routines that fire along the way, then the specialists who play roles inside both.
States are the columns work moves through.
A state is a stage of progress. Intake. Analysis. Implementation. Review. Done. Each state has a name, an owner, a capacity (how many items belong there at once), and a set of allowed transitions to other states. The state machine is the contract: work cannot skip review, cannot return to analysis from done, cannot stay in 'in progress' for ninety days without flagging.
Routines fire on schedule or events.
A routine is a named, recurring job. Daily security review. Architecture sweep. Daily digest. Each routine has a prompt, a default cadence (cron or event trigger), and a defined output — a comment, an Inbox item, a draft article, a tracker update. Routines run inside the process so they always have the right context: which state work is in, which specialist owns it, what evidence has already been gathered.
Specialists are the roles that run the work.
A specialist is a versioned role definition — intake, business analyst, product manager, developer, technical architect, designer, code reviewer, QA, devops, security, data/ML, support, technical writer, marketing operator. When a routine fires, it takes on a specialist for the duration of the run. Same routine + different specialist = different output. The specialist is the role; the executor (the AI agent — Cursor, Claude Code, Codex, Copilot) is who actually reads the prompt and writes the diff.
States define where work is. Routines define when the system acts. Specialists define in what role. Get those three right and the rest is configuration.
Step three — the canonical example
LiveDevelopment — the SDLC, fully drawn.
The Development process is what every workspace gets at activation, and it is the only top-level process Ship ships at production depth today. Eight states from intake to PR review, three nested sub-processes (Requirements, Implementation, Quality review), eight scheduled routines, owners on every step.
Requirements
Intake
task_intakeRequirements
Requirements
ba_requirementsImplementation
Architecture plan
tech_arch_planImplementation
QA plan
qa_arch_planImplementation
Implementation
dev_implementationQuality review
Manual QA
qa_manualQuality review
Automation QA
qa_automationQuality review
PR review
pr_reviewRequirements
2 states
- IntakeIntake specialist
- RequirementsBusiness analyst
Implementation
3 states
- Architecture planTechnical architect
- QA planQA engineer
- ImplementationDeveloper
Quality review
3 states
- Manual QAQA engineer
- Automation QAQA automation
- PR reviewCode reviewer
Eight routines firing inside the process
Each routine takes on a specialist for its run, reads the relevant tracker context and knowledge, produces evidence (a comment, an Inbox item, a draft). Cron-driven by default; some are event-triggered.
Security review
Scans dependencies and secrets policy on a daily cron.
06:00 dailyDaily standup
Asynchronous standup nudge with state and blocker summary.
09:00 weekdaysDaily digest
Consolidated summary of in-flight work and blockers.
08:00 weekdaysArchitecture tests review
Recurring check on test architecture and coverage.
08:00 weekdaysArchitecture review
Architecture drift and design consistency review.
10:00 MondaysSelf-heal
Reconciles CI, workflows, and guardrails after failed runs.
every 2hRetro
Lightweight team retro prompts and follow-ups.
16:00 FridaysTech debt sweep
Triages and sizes technical-debt work for upcoming cycles.
04:00 SundaysAbove every process
Policies are guardrails that apply everywhere.
Processes describe how work flows. Policies describe what is never allowed regardless of which process is running. They sit one layer above and get injected into every agent's system prompt — so a routine can't accidentally violate a rule the team has agreed on, no matter which specialist is on the keyboard.
Workspace policies
Injected into every agent's system prompt.
Below are the processes — Development, Marketing, Support, Compliance, Data & ML. Above them sits the policy layer. A policy added today applies to every routine that fires tomorrow, in every process, on every executor.
Policy layer · 6 active
No force-push to main
Every executor refuses force-push regardless of which routine asked, which branch they are on, or what the prompt says.
Cite the source
Any summary that quotes knowledge or a tracker item must include a clickable reference. Routines that try to ship without one fail closed.
Never share customer data
Policy guards the data classes the workspace marks as sensitive — they cannot leave designated processes, even in chat.
Respect on-call
No deploy routines fire on the on-call's off hours. The policy reads the on-call schedule integration and gates the execution.
Policies are versioned the same way specialists are. When the team agrees on a new rule, it lands as a diff, gets reviewed, and starts applying on the next routine run — no per-process retrofit needed.
Continuous learning
The system gets smarter with every interaction.
Every clarification answered, every approval recorded, every retro logged, every casual chat that turns into a decision — Ship captures the signal, distills it, and stores it as knowledge. Over time the workspace builds an honest model of your team's working style: which routines are noisy, which states stall, which specialists need more context, which policies need refinement. Then it suggests improvements — for your team, in your voice.
The loop
Capture → distill → propose → apply.
Improvements come from your team's actual behaviour, not from a generic playbook.
Capture
Every interaction lands in the audit log: a clarification, an approval, a retro note, a chat thread. Nothing is silently discarded.
Distill
The distiller routes raw signal into the right knowledge bucket. Recurring questions become articles. Repeated objections become policy candidates.
Propose
The system reads the patterns and proposes improvements: tighten this routine's prompt, split that bucket, move standup an hour later, retire the routine that has produced nothing for three weeks.
Apply
A human reviews the proposal and accepts, declines, or defers it — same Inbox, same disposition vocabulary. The accepted change ships and starts producing better signal on the next loop.
Same model, growing depth
Coming soonFour other processes the catalogue can already express.
The model — states + routines + specialists — is general. Below are four processes drafted with the same building blocks: Marketing operations, Customer success, Compliance & security, Data & ML release. The roles already ship in the catalogue; the process shapes are forming. Each one moves from draft to production depth as we run it ourselves first.
Marketing
Marketing operations
Briefs, creative, review, ship, measure — using the marketing_operator, designer, technical_writer, devops_platform, and data_ml_engineer specialists already in the catalogue.
States
Brief intake
Intake specialist
Research
Marketing operator
Creative
Designer
Produce
Technical writer
Review
Marketing operator
Ship
DevOps / platform
Measure
Data / ML engineer
Drafted routines
- Weekly campaign digest
09:00 Mondays - Monthly attribution review
1st of month - Brand voice audit
fortnightly
Support
Customer success
Triage, reproduce, fix, validate, loop back to product — using support_success, developer, qa_engineer, and product_manager.
States
Ticket intake
Intake specialist
Triage
Support / success
Reproduce
Support / success
Fix
Developer
Validate
QA engineer
Close
Support / success
Loop back
Product manager
Drafted routines
- Daily unresolved digest
08:00 daily - Weekly pattern review
10:00 Fridays - Monthly CSAT summary
1st of month
Compliance
Compliance & security
Change intake, impact assessment, control check, approval, ship, audit — primarily security_engineer, with developer and devops_platform.
States
Change intake
Intake specialist
Impact assessment
Security engineer
Control check
Security engineer
Approval
Security engineer
Ship
Developer
Audit review
Security engineer
Drafted routines
- Daily dependency scan
06:00 daily - Weekly compliance check
07:00 Mondays - Monthly audit summary
1st of month
Data / ML
Data & ML release
Experiment intake, data review, eval, train, release decision, monitor — using data_ml_engineer, qa_engineer, and product_manager.
States
Experiment intake
Intake specialist
Data review
Data / ML engineer
Eval setup
Data / ML engineer
Train
Data / ML engineer
Release decision
Product manager
Monitor
Data / ML engineer
Drafted routines
- Daily drift check
06:00 daily - Weekly eval report
09:00 Mondays - Model card freshness
fortnightly
The cast
Fifteen specialists ship in the catalogue today.
Every process you saw above pulls from the same pool. Engineering, Product, and Operations roles versioned like code — bump the role definition once and every routine that runs as that specialist gets the new context.
Engineering
technical_architectTechnical architect
Plans architecture, migration strategy, boundaries, and technical risks.
developerDeveloper
Implements code changes, tests, docs, and prepares PRs.
code_reviewerCode reviewer
Reviews PRs for correctness, maintainability, risks, and test coverage.
qa_engineerQA engineer
Validates acceptance criteria, edge cases, and user-facing quality.
qa_automationQA automation
Adds or maintains automated tests and regression coverage.
devops_platformDevOps / platform
Handles CI/CD, environments, deployment, infrastructure, and operations.
security_engineerSecurity engineer
Reviews auth, permissions, secrets, dependencies, and security policy.
data_ml_engineerData / ML engineer
Handles data pipelines, evaluations, experiments, and ML release checks.
Product
intakeIntake specialist
Clarifies incoming work, checks minimum context, and routes tasks.
business_analystBusiness analyst
Turns ambiguous requests into requirements and acceptance criteria.
product_managerProduct manager
Clarifies scope, priority, tradeoffs, and launch criteria.
designerDesigner
Reviews UX flows, product copy, accessibility intent, and design quality.
Operations
support_successSupport / success
Turns customer reports into reproducible tasks and validates fixes.
technical_writerTechnical writer
Writes release notes, user docs, internal docs, and runbooks.
marketing_operatorMarketing operator
Handles content, site, campaign, and marketing workflow tasks.
Why this model
Why processes on specialists beats hardcoded workflows.
Specialists are versioned roles
Not 'use the developer agent on this ticket' as a one-line prompt. Specialists are versioned role definitions; Ship records which version ran each step, so a regression in role behaviour traces to a specific role bump, not a vibe shift.
Routines are reviewable jobs
Every scheduled routine has a name, a prompt, a default cadence, and an owner. When a routine drifts, you read the diff. When a routine misbehaves, you point at the row in the audit log.
States carry the contract
The process declares which state allows which transition, what evidence is required, and which specialist owns each step. The tracker mirrors it; routines respect it; humans review it like code.
Next
Map your team's first process.
The Development process is what most teams adopt first. Once it is running, the same specialists carry over into Marketing, Customer success, Compliance, and Data & ML as those processes mature. The contract is the same; the roles are the same; only the shape of the graph differs.