Samples

Every install already has these. pipelines/, steps/, webhooks/ (from the VectorStep image) and agents/, skills/ (from the VectorStep-Gateway image) are seeded into your live config directories — ~/.vectorstep/* by default — the first time you install, exactly once: if a directory already has content, seeding is skipped, so nothing overwrites work you’ve done. Nothing here is special config-only content; every file below is an ordinary pipeline/step/agent/skill you could have written yourself, sitting on your disk right now, that you’re free to edit, delete, or copy as a starting point.

Two subdirectories are not auto-seeded — security_policies/ and scripts/ — since seeding them unconditionally would be seeding live security config, not just examples. Both live inside the VectorStep image at /app/samples/... regardless; pull a file out with docker cp (the source is closed, so this — not git clone — is how you get it):

docker cp $(docker compose ps -q vectorstep):/app/samples/scripts/summarize_numbers.sh ~/.vectorstep/scripts/

scripts/ is already bind-mounted in the published docker-compose.yaml (./scripts:/etc/vectorstep/scripts:ro), so dropping the file in ~/.vectorstep/scripts/ on the host is all this one needs. security_policies/ has no such mount in the published compose file — using pci-dss-lite.yaml means adding your own volume line (./security_policies:/etc/vectorstep/security_policies:ro, say) and setting security_policies_dir in config/vectorstep.yaml yourself; see the config reference for the key.

Most of these are written to be read, not run — several reference a Confluence space, a Jira project, or a Grafana dashboard that doesn’t exist in your environment, and are meant as shape, not literal copy-paste. Where a sample is directly runnable as shipped (no external service required), or a tutorial walks through it step by step, that’s called out below.

Config (config.yaml.example, both images)

Every field, every switch, #-commented off by default wherever the feature itself defaults off — the annotated starting point behind ~/.vectorstep/config/vectorstep.yaml (VectorStep) and ~/.vectorstep/config/gateway.yaml (Gateway) that the installer writes on first run. This is the one sample that’s genuinely meant to be edited in place rather than copied piecemeal — uncomment a block, fill in the ${ENV_VAR} it references in .env, restart.

Full field-by-field documentation for every key in it: Service configuration reference and Gateway configuration reference.

One gap worth knowing about if you’re setting up multi-team webhook auth: the shipped example’s auth: block still uses the older teams/token form rather than the current auth.tokens model. Use the config reference’s tokens: shape instead if you’re setting up auth from scratch.

Pipelines (~/.vectorstep/pipelines/)

File	Pipeline name	What it demonstrates
mixed-executor-demo.yaml	mixed-executor-demo	A gateway LLM step, a executor: shell step consuming its output, another LLM step, and a final LLM step that loads a granted skill — the shape of passing output between different executor types. Directly runnable (needs security.shell_steps enabled — see below). stage: testing.
api-response-demo.yaml	api-response-demo	Two executor: webhook steps with parse_json: true — calls a public test API, then references its response fields ({{steps.fetch_user.name}}, etc.) in a second API call. Directly runnable as shipped, no config changes needed — both calls hit the public jsonplaceholder.typicode.com test API. No LLM involved at all. Walked through in Call an API and use its response. stage: testing.
alert-triage-investigation-using-steps.yaml	my-service-triage	A two-step triage → Grafana investigation flow, built from the reusable step library (use:) rather than inline prompt_templates — see the Steps table below.
alert-triage-dedup.yaml	my-service-triage-dedup	The same triage flow with a widened dedup window, for alerts that need longer before a duplicate is considered “new” again.
otel-triage-verified.yaml	otel-triage-verified	Two-step OTEL Collector triage with an always-on verifier reviewing the SRE investigation step before its confidence is accepted. Its header comment calls it a “verified variant of otel-triage-test” and suggests renaming it to that name to activate — but no otel-triage-test.yaml ships alongside it, so that note doesn’t apply as shipped; the file loads and matches on its trigger (severity: critical, service: otel-collector) under its current filename with no rename needed.
first-line-triage-trust-vector-demo.yaml	first-line-triage-trust-vector-demo	Every trust-vector knob turned on at once (verifier + enforced grounding + a deterministic check + calibration) on one step — a playground for repeated “Run now” clicks to bootstrap a calibration bucket. Deliberately stage: production so marks count toward real calibration.
trust-vector-remediation.yaml	trust-vector-remediation	The full trust vector (S+V+G+D+calibration) gating an auto-remediation action, rather than just informing a human.
fan-out-multi-service-triage.yaml	multi-service-triage	Fan-out: one step identifies affected services, a parallel group triages each independently, a final step summarises across all of them. Walked through in Fan out over services.
sub-pipeline-example.yaml	composite-incident-response	Calls a shared sub-pipeline for triage, then routes to remediation or escalation based on its output. See Chaining pipelines.
deterministic-checks-step-context.yaml	deterministic-checks-step-context	A deterministic check (shell/webhook/human) reading a prior step’s own structured output fields as template variables.
conditional-steps-and-notify.yaml	demo-conditional-notify	Conditional steps, failure policies, and outbound notifications.
durable-remediation-example.yaml	durable-remediation-example	A remediation step with a side effect, durable across a crash/restart via on_interrupted: escalate rather than silently re-running it.
human-approval-test.yaml	approval-test	Three steps with a human-in-the-loop approval gate in the middle.
stage-testing-example.yaml	stage-testing-example	stage: testing muting a notify step, an on_failure webhook, a human approval step, and pipeline notifications — all routed to the log/UI instead of firing for real.
promotion-readiness-criteria.yaml	promotion-readiness-criteria	Every readiness: knob, at both pipeline and step level, including an opt-out and a parallel group.
security-policy-restricted-pipeline.yaml	security-policy-restricted-pipeline	Opts into pci-dss-lite (below), which denies executor: shell/executor: webhook — every step here uses a permitted executor. Walked through in Enforcing a security policy.
tagged-example.yaml	tagged-example	Pipeline-level tags and a tagged library step — the filtering surface on /ui/pipelines.
generic-webhook-new-order.yaml	new-order	The generic webhook source (bypasses trigger.match entirely) — order intake followed by personalised customer comms. Walked through in Build your first agent.
research-brief.yaml	research-brief	Web research → synthesis → proofread, three steps producing/consuming artifacts. Walked through in Storing artifacts.

~/.vectorstep/webhooks/alertmanager_critical.json is a sample Alertmanager payload shape for testing the alertmanager webhook source against one of the alert-triage pipelines above without a real Alertmanager instance.

Steps (~/.vectorstep/steps/)

Reusable step library entries, referenced from a pipeline via use: instead of inlining a prompt_template. alert-triage-investigation-using-steps.yaml above is the pipeline that ties first-line-triage.yaml and sre-investigation.yaml together; the rest can be mixed into your own pipelines the same way.

File	What it does
first-line-triage.yaml	Looks up service documentation in Confluence, raises a Jira ticket, produces an investigation brief for the next step.
sre-investigation.yaml	Queries Grafana RED metrics, updates the Jira ticket, produces a probable-cause assessment.
sre-investigation-verified.yaml	Identical, plus an always-on principal-sre reviewer verifying every run.
service-health-check.yaml	A lightweight RED-metrics check, meant as a cheap first step before deciding whether deeper investigation is warranted.
order-intake.yaml	Reviews a new order, produces a dispatch brief and customer profile.
customer-comms.yaml	Drafts a personalised follow-up email from order-intake’s output — references steps.order_intake.* directly.
gather-research.yaml	Web search on a topic, stores raw findings as an artifact.
synthesise-report.yaml	Reads that artifact, produces a polished report artifact.

Security policies (~/.vectorstep/security_policies/, not auto-seeded)

File	What it does
pci-dss-lite.yaml	Denies executor: shell and executor: webhook outright, allows everything else — a restriction set a pipeline opts into via its own security_policies: [pci-dss-lite] field. See Restricting pipelines with security policies.

Scripts (~/.vectorstep/scripts/, not auto-seeded)

File

What it does

summarize_numbers.sh

The executor: shell step behind mixed-executor-demo.yaml above — takes a comma-separated list of integers, prints count/sum/avg/min/max. Deliberately plain POSIX /bin/sh with no external commands: the subprocess runs with a completely empty environment (no PATH), so a #!/usr/bin/env python3-style shebang can’t resolve its interpreter and fails with exit 127 — worth knowing before writing your own.

To actually run mixed-executor-demo.yaml, allowlist this script in config.yaml:

security:
  shell_steps:
    enabled: true
    allowed:
      - name: summarize-numbers
        path: summarize_numbers.sh
        sha256: cfca5f9526ab7d6b33cfba7b869018026fd571db9269da48fe3c980ee817722f

See Tutorial: run deterministic logic as a pipeline step for the full allowlist mechanics.

Agents (Gateway, ~/.vectorstep/agents/)

Directory	Model	Granted skills	What it’s for
generic-pipeline-step	anthropic/claude-haiku-4-5	—	A narrow, task-agnostic agent for simple structured-JSON steps — return the schema the prompt asks for, nothing else. Used across several tutorials as the default lightweight agent.
ops-triage-agent	anthropic/claude-haiku-4-5	incident-triage	Same narrow role as generic-pipeline-step, plus a skill grant — the agent behind mixed-executor-demo.yaml’s final step.
sre-triage	anthropic/claude-sonnet-4-6	incident-triage	Tool-using triage agent (Grafana, Atlassian, Tavily) that reaches for its skill when a task looks like an incident. Used in Build your first agent.
customer-comms	openrouter/nvidia/nemotron-...:free	—	Drafts customer-facing comms from order-intake’s output — the agent behind steps/customer-comms.yaml.
order-intake	openrouter/nvidia/nemotron-...:free	—	The agent behind steps/order-intake.yaml.
grounding-judge	anthropic/claude-haiku-4-5	—	Cross-references a step’s claims against its own tool-call trace — doesn’t need a frontier model for that. See Turning on grounding.
scoped-tools-example	anthropic/claude-sonnet-4-6	—	Demonstrates scoping a tools: grant down to specific tool names rather than a whole MCP server.
azure-gpt4o-analyst	azure/gpt-4o	—	An Azure OpenAI-backed agent, for confirming your Azure deployment name / API version are wired correctly.

Skills (Gateway, ~/.vectorstep/skills/)

Directory	What it’s for
incident-triage	Classifies a production incident’s severity, identifies the escalation path, and drafts an initial status update, per this org’s Sev1–Sev4 matrix (reference/escalation-matrix.md). Granted to sre-triage and ops-triage-agent above. See Skills for the format, and Writing good skills for what makes a description trigger reliably.

The tutorial that builds a skill from scratch deliberately doesn’t use this one — it walks you through authoring your own (status-update-style) so you’ve done it once yourself, rather than just reading someone else’s.