> ## Documentation Index
> Fetch the complete documentation index at: https://docs.crewship.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Crewship use cases

> Match common engineering operations to a Crewship crew, routine, credential policy, and the command or manifest that starts them.

# What would I use Crewship for?

The useful question is not whether an agent can do a task once. It is whether the task has a repeatable trigger, a bounded workspace, an observable result, and a clear owner for exceptions.

## Continuous dependency upgrades

**Problem:** upgrades are easy to postpone, but a backlog of small changes becomes a risky batch. **Crew actually does:** a maintenance agent reads the repository's lockfiles and contribution rules, changes one dependency band at a time, runs the project's checks, and leaves a bounded issue when a major version needs a human decision. A routine provides the recurring trigger; the issue and Journal provide the handoff. **Cost:** model calls plus the crew container for each bounded run, with repository CI and human review still required. **Start with:** [routine scheduling](/guides/scheduling) and `crewship routine list` using the [routine CLI reference](/cli/routine).

## Incident triage

**Problem:** the first responder needs a timeline, related issues, and a safe next action before changing production. **Crew actually does:** a lead assigns a triage agent to collect the incident's issue, recent Journal events, deploy identifiers, and known runbooks; the agent produces a hypothesis with evidence and opens a waitpoint before any destructive action. **Cost:** one or more model runs per incident and operator review time; the result is an evidence pack, not an incident command system or an automatic production fix. **Start with:** `crewship journal --crew docs-lab --lines 20` and [Harbormaster approvals](/api-reference/approvals).

## PR review that actually runs the code

**Problem:** a static review can miss a failing test or a changed contract. **Crew actually does:** a review agent checks the diff, runs the relevant suite in its crew workspace, compares the result with the task's acceptance criteria, and reports file/line findings with the command that reproduced them. **Cost:** model tokens and crew/CI time; it complements required human review and branch protection rather than replacing either. **Start with:** `crewship ask --agent writer "Create /crew/shared/hello.txt containing exactly: hello from Crewship"` as the harness-verified task shape, then adapt the prompt to the pull request using the [good review examples](/guides/writing-good-tasks#writing-a-good-task-for-an-agent).

## Secret-aware integration work

**Problem:** an agent needs an API or Git credential, but copying it into a prompt or repository creates an avoidable exposure. **Crew actually does:** an operator creates a named credential, binds it to the agent's environment slot, and lets the sidecar deliver it only while the run needs it; Keeper can turn an unusual request into a human escalation. The agent receives a capability, not the stored value through the CLI listing. **Cost:** credential-provider setup, model-run cost, and possible approval latency; Crewship does not remove provider quotas or your data-classification obligations. **Start with:** `crewship credential create --name demo-token --type API_KEY --value local-demo-value` and `crewship credential assign demo-token writer --env-var-name DEMO_TOKEN`, then read [Credentials](/guides/credentials).

## Recurring data or content normalization

**Problem:** the same deterministic cleanup must happen on a schedule, but exceptions still need a trace. **Crew actually does:** a routine runs a script or agent step against a bounded input, writes the result to crew-shared storage, and leaves run status and step events in the Journal; a later run can use durable state instead of pretending every run is the first. **Cost:** scheduled model or script execution and storage. If the transform has no judgment or exception handling, a plain data pipeline is cheaper and clearer. **Start with:** [routine scripts and schedules](/guides/routines) and `crewship routine list`.

## Repository onboarding and documentation

**Problem:** a new codebase has useful conventions scattered across files and history. **Crew actually does:** one agent inventories entry points and tests, a lead challenges unsupported assumptions, and the crew stores a reviewed brief in shared memory before turning unknowns into issues. **Cost:** an initial exploration run, container time, and review time; memory is a working context, not authoritative source documentation. **Start with:** `crewship crew create --name "Docs Lab" --slug docs-lab`, `crewship agent create --name "Writer" --slug writer --crew docs-lab --role AGENT --memory`, and [First projects](/guides/first-projects).

## Human-gated change workflows

**Problem:** an automated workflow should prepare a change but pause before a destructive or externally visible step. **Crew actually does:** an agent prepares the diff or action plan, the routine enters a durable waitpoint with its run context, and Harbormaster records approve, reject, or timeout before the run resumes or stops. **Cost:** the run plus operator decision time; if every step needs a person, a conventional ticket workflow may be simpler. **Start with:** the [waitpoint API](/api-reference/waitpoints) and [orchestration guide](/guides/orchestration).

The common shape is bounded work plus a durable handoff. If the result cannot be checked, the exception cannot be owned, or the required capability cannot be scoped to a crew, choose a simpler tool or read [When not to use Crewship](/guides/when-not-to-use).