DEV Community: vem.dev

Mastering vem Tasks: Create, Prioritize, Implement, and Ship — A Complete Guide

vem.dev — Tue, 21 Apr 2026 16:22:48 +0000

🚀 vem is in early access — we're looking for our first users. If you try it and find it useful, we'd love to hear from you. Early access is completely free.

Everything in vem revolves around tasks. A task is more than a to-do item — it carries the metadata your AI agent needs to implement it correctly: priority, type, time estimate, validation steps, dependencies, and a targeted context block written specifically for the agent.

This is a complete guide to every task feature in vem.

Prerequisites — Install vem and Link a Project

You need the vem CLI installed, an authenticated account, and a repository linked to a vem cloud project. If you completed the Cycles or Memory tutorials you are already set up — jump to the next section.

npm install -g @vemdev/cli
vem login <your-api-key>   # key from vem.dev/keys
cd my-project && vem init && vem link
vem status                 # confirm everything is connected

The Task: vem's Atomic Unit of Work

Everything in vem revolves around tasks. A task is more than a to-do item — it carries the metadata your AI agent needs to implement it correctly:

Priority: low / medium / high / critical
Type: feature / bug / chore / spike / enabler
Estimate: hours (used in cycle capacity planning)
Validation steps: shell commands that must pass before the task is considered done
Dependencies: blocked-by and depends-on relationships between tasks
Impact score: RICE-based 0-100 score for data-driven prioritization

Tasks move through a clear lifecycle: todo → ready → in-progress → done (or blocked when something is in the way). At any point an agent can pick up a ready task, load its full context, and start working — without any setup instructions from you.

Create a Task with Rich Metadata

vem task add accepts a full set of flags on a single command. You can create a bare-bones task with just a title, or a fully-specified task that gives your AI agent everything it needs before it writes the first line of code.

The --validation flag is particularly powerful: it defines the shell commands that must pass before the task can be considered done. When you run vem cycle validate at the end of a sprint, vem re-runs these commands and flags any task whose validation steps now fail — catching regressions automatically.

vem task add "Implement JWT refresh token rotation" \
  --priority high \
  --type feature \
  --description "Replace static tokens with rotating refresh tokens" \
  --estimate-hours 4 \
  --validation "pnpm test:auth, pnpm lint" \
  --depends-on TASK-001

# Quick task (interactive mode when title is omitted)
vem task add

Task Lifecycle — Ready, Start, Block, Done

Tasks start in todo status. When a task is refined and ready to be picked up — requirements clear, dependencies met — mark it ready. This is the queue that agents and the web runner pull from.

vem task start sets the start timestamp used for cycle time measurement. vem task done marks it complete and records evidence. Use vem task block when a task is stuck, and vem task unblock when the blocker is resolved.

The lifecycle is designed so every state transition is intentional and auditable.

# Refine and mark ready to pick up
vem task ready TASK-002

# Start working (records start timestamp for cycle time)
vem task start TASK-002

# Mark done with evidence of completion
vem task done TASK-002 --evidence "Added retry with backoff in src/api/client.ts — tests pass"

# Mark blocked and explain why
vem task block TASK-002 --reason "Waiting for API key rotation spec"

# Unblock when resolved
vem task unblock TASK-002

Subtasks and Dependencies

Large tasks can be broken into subtasks using --parent. Subtasks inherit the parent's cycle assignment and appear grouped in vem task subtasks. This is useful for features that span multiple implementation areas but share a single acceptance criterion.

Dependencies between tasks are tracked with --depends-on (soft dependency — informational) and --blocked-by (hard block — the blocking task must complete first). These relationships feed into the cycle board and agent context so agents understand sequencing without you having to explain it.

# Break a task into subtasks
vem task add "Write unit tests for token rotation" --parent TASK-007 --order 1
vem task add "Update API docs for new token flow" --parent TASK-007 --order 2

# View the subtask tree
vem task subtasks --parent TASK-007

# Mark a dependency
vem task update TASK-008 --depends-on TASK-007
vem task update TASK-009 --blocked-by TASK-007

Per-Task Agent Context

Every task has a dedicated context block — a free-text note written by you (or a previous agent) that the AI agent reads before starting work. This is different from the project-level CONTEXT.md: it is task-specific, pointing the agent at the exact file, function, or edge case that matters for this particular task.

vem task context <id> --set replaces the context. --append adds to it. --clear removes it. When the MCP server sends a task to an agent, the task context is included in the payload alongside the task metadata — so your agent knows exactly where to look without any back-and-forth.

# Set targeted context for the AI agent
vem task context TASK-001 --set "Offline mode throws an unhandled rejection when
the API is unreachable. Fix in src/sync/push.ts — catch the network error and
write to .vem/queue/ instead. Test with: npm test -- --grep offline"

# Append additional context
vem task context TASK-001 --append "Related: the queue flush logic is in src/sync/flush.ts"

# View what the agent will see
vem task context TASK-001

Impact Scoring — Prioritize with Data

vem task score shows all tasks ranked by their impact score (0-100). Scores use a RICE-inspired model: tasks with no score show — and appear at the bottom. When you run vem task score <id> --set <score>, you can attach reasoning that is stored with the score and shown to agents during prioritization.

Impact scores feed directly into cycle planning — when you create a new cycle, vem can suggest which backlog tasks have the highest combined impact for the planned scope.

# View all tasks ranked by score
vem task score

# Score a specific task with reasoning
vem task score TASK-001 --set 92 \
  --reasoning "Critical path: all auth features blocked until offline mode is fixed"

# Score multiple tasks
vem task score TASK-005 --set 45 --reasoning "Nice to have — no active blockers"

Validation Steps — Built-In Quality Gates

The --validation flag on vem task add (or vem task update) stores a comma-separated list of shell commands that define what "done" means for that task. At the end of each sprint, vem cycle validate re-runs all validation steps for completed tasks and flags any that now fail.

This is how vem detects regressions: a feature implemented in sprint 1 may break when sprint 3 refactors the same module. Cycle validation catches it before it ships. The validation steps are also shown to agents during implementation so they know exactly how to verify their work.

# Set validation steps at creation
vem task add "Add rate limiting to API endpoints" \
  --validation "pnpm test:api, pnpm test:integration, pnpm build"

# Update validation steps on an existing task
vem task update TASK-004 --validation "pnpm test, pnpm lint, pnpm type-check"

# Run cycle validation at sprint end
vem cycle validate

Flow Metrics — Measure What Matters

vem task flow shows the flow metrics for a specific task or a project-wide summary. For a single task: lead time (created → done), cycle time (started → done), and time spent in each status. For the project: throughput, average cycle time, and current work-in-progress count.

These metrics do not require any extra setup — they are calculated automatically from the timestamps recorded by vem task start and vem task done. Over multiple sprints the data becomes a reliable baseline for estimating how long similar work takes and where tasks tend to get stuck.

# Flow metrics for a specific task
vem task flow TASK-003

# Project-wide summary (throughput, avg cycle time, WIP)
vem task flow

Agent-Powered Implementation

vem agent --task TASK-X launches your configured AI agent (Copilot, Claude, Gemini, Codex) with the task's full context pre-loaded: task description, per-task context, project CONTEXT.md, active cycle, and related decisions. The agent works in your local repository and can create branches, write code, run tests, and open PRs.

The --task flag scopes the agent to a single task. vem wraps the agent session to record which task was worked on, what commands were run, and what was completed — building the audit trail in vem task sessions.

Privacy: your AI provider keys (OpenAI, Anthropic, etc.) are stored in your local environment variables and never sent to the vem cloud. vem only orchestrates which task to run — the agent execution happens entirely on your machine.

# Run Copilot on a specific task
vem agent --task TASK-001

# Use a different agent
vem agent --task TASK-001 --agent claude

# Run without strict memory enforcement (not recommended)
vem agent --task TASK-001 --no-strict-memory

PR Iteration — Continue from an Existing Branch

When an agent opens a PR but the implementation needs refinement, vem task iterate picks up where it left off. It finds the latest run with an open PR for the task, checks out that branch, and launches the agent again with follow-up instructions — so the agent continues from the existing code instead of starting from scratch.

This is the difference between re-running an agent (which may diverge or duplicate work) and iterating on a PR (which builds on what already exists).

# Continue from the latest PR for a task
vem task iterate TASK-001 --prompt "The backoff is correct but the error message
needs to include the retry count. Also add a --max-retries flag."

# Iterate with a specific agent
vem task iterate TASK-001 --agent claude --prompt "Add the missing unit test for the edge case where retries > 3"

The Web Board — Visual Task Management

The vem web app at app.vem.dev provides a visual view of every task in your project. The Board tab shows all tasks with a real-time summary: total count, blocked count, high-priority count, and completed count for the active cycle.

Clicking a task opens the full task detail page with everything in one place: status and priority badges, the task context summary for agents, a Discussion thread, and the Run with agent panel. The agent panel lets you choose between running locally or in the cloud, select the agent, pick the branch, and add extra instructions — then hit Start run to dispatch the agent.

The Board tab — at-a-glance stats, agent activity, GitHub integration, and the full task list

Audit Trail — Task Sessions

vem task sessions <id> lists all agent sessions that touched a task: which agent ran, when it started and ended, what commands were executed, and whether the task was completed during that session. This gives you a full audit trail for every unit of work.

# List all sessions that worked on a task
vem task sessions TASK-001

Putting It All Together

A well-maintained task is more than a to-do item — it is a self-contained work package that any agent can pick up and execute correctly without additional instructions.

# 1. Create with rich metadata
vem task add "Implement rate limiting" --priority high --type feature \
  --estimate-hours 3 --validation "pnpm test:api, pnpm lint" \
  --depends-on TASK-001

# 2. Write targeted agent context
vem task context TASK-008 --set "Add rate limiting in src/api/middleware.ts.
Use sliding window algorithm. Limits: 100 req/min per API key, 10 req/min
for unauthenticated. Test: npm test -- --grep rate"

# 3. Score by impact
vem task score TASK-008 --set 78 --reasoning "Needed before public beta"

# 4. Mark ready and start
vem task ready TASK-008 && vem task start TASK-008

# 5. Run agent implementation
vem agent --task TASK-008 --agent claude

# 6. Check flow metrics
vem task flow TASK-008

# 7. Sync to cloud
vem push

Every task you create this way is a self-contained work package — any agent can pick it up, understand what to build, implement it, and verify it is done. That is the core promise of vem tasks.

vem is currently in early access. We're looking for our first users — developers who want their AI agents to work from structured, durable tasks rather than free-form prompts. Early access is completely free. No credit card, no trial timer.

If you found this useful, sign up at vem.dev and let us know what you're building. Your feedback will directly shape the product. 🙏

Your AI Agent Now Remembers Your Project: Persistent Memory with vem

vem.dev — Tue, 21 Apr 2026 07:50:46 +0000

🚀 vem is in early access — we're looking for our first users. If you try it and find it useful, we'd love to hear from you. Early access is completely free.

Every time you open a new chat with your AI coding assistant you spend the first few minutes re-explaining the same things: what the project does, which patterns you follow, what you were just working on, and why you made the architectural choices you did.

This is not a UX quirk — it is a structural gap. AI agents are stateless. vem solves this with a local memory layer that lives inside your repository.

Prerequisites — Install vem and Link a Project

You need the vem CLI installed, an authenticated account, and a repository linked to a vem cloud project. If you completed the Cycles tutorial you are already set up — skip to the next section.

# 1. Install the CLI globally
npm install -g @vemdev/cli

# 2. Authenticate with your API key from vem.dev/keys
vem login <your-api-key>

# 3. Initialise memory in your repo and link to a cloud project
cd my-project
vem init
vem link

# Confirm everything is connected
vem status

The Problem: AI Agents Forget Everything

This is not a UX quirk — it is a structural gap. AI agents are stateless. They have no memory between sessions. The work you do to orient them at the start of each session is pure overhead, and the accumulated reasoning from previous sessions is permanently lost.

vem solves this with a local memory layer that lives inside your repository. Everything your agents need to hit the ground running — project context, architectural decisions, sprint state — is stored durably in .vem/ and synced to the cloud so agents can query it instantly.

How vem Memory Works

vem's memory system is built around four durable artifacts, all stored in .vem/ inside your repository. They are gitignored by default (so secrets never leak) but backed up to the vem cloud for search indexing and team sharing.

CONTEXT.md — project overview and "need to know" facts
CURRENT_STATE.md — live progress summary updated after each work session
decisions/ — one ADR file per architectural decision
tasks/ — structured task backlog with cycle assignments

CONTEXT.md is your project's "North Star" — a human-readable summary of what the project is, who it is for, and the non-obvious things any new contributor (human or AI) needs to know. CURRENT_STATE.md captures where work stands right now: what just changed, what is in progress, and what is blocked.

The decisions/ directory holds Architectural Decision Records (ADRs) — one file per decision, recording what was chosen, why, and what was considered and rejected. Together these four artifacts give any AI agent a complete, structured picture of your project before it writes a single line of code.

Step 1 — Write Your First Project Context

Start by writing a concise project context. Open .vem/CONTEXT.md in any editor and describe your project in plain language: what it does, the main tech choices, and any gotchas a new developer would need to know on day one.

vem context show prints the current context so you can confirm what your agents will see. After editing, run vem push to sync it to the cloud immediately.

# Open the context file in your editor
$EDITOR .vem/CONTEXT.md

# Preview what agents see right now
vem context show

# Sync to the cloud after editing
vem push

Step 2 — Record an Architectural Decision

Every non-obvious choice deserves a decision record. vem decision add writes an ADR to .vem/decisions/ and immediately makes it searchable via the MCP server.

Include the context (why you faced this decision) and the decision (what you chose). Future agents — and future you — will understand not just what was chosen but why. This prevents the "why did we do it this way?" confusion that slows down every project after the first month.

vem decision add "Use Zod for input validation at CLI boundaries" \
  --context "Catching invalid user input early prevents confusing downstream errors." \
  --decision "All CLI inputs are validated with Zod schemas before any business logic runs."

Step 3 — See Exactly What Your Agent Sees

vem pack generates a structured JSON snapshot of your entire project memory — tasks, context, decisions, and sprint state — in a single block. This is the exact payload that the MCP server sends to your AI agent at the start of each session.

Running vem pack manually is the fastest way to audit your memory quality. If the output looks thin or outdated, that is what your agents are working with. A well-maintained pack is the difference between an agent that needs three rounds of clarification and one that writes correct code on the first attempt.

# Generate the full context pack
vem pack

# Pipe to a file to inspect offline
vem pack > /tmp/my-project-context.json

Step 4 — Ask Questions About Your Project

vem search performs semantic search across your project memory — tasks, decisions, context, and changelog entries. It is powered by the vem cloud vector index built from your most recent vem push.

This is especially useful for finding related decisions, locating tasks about a specific feature, or checking whether a topic has already been addressed before adding a new decision record.

# Search across all memory artifacts
vem search "error handling"

# Find decisions related to authentication
vem search "auth"

# Find tasks mentioning a specific library
vem search "retry logic"

Step 5 — Connect Any Agent via MCP

The vem MCP server is the bridge between your memory layer and any AI agent that supports the Model Context Protocol: Claude Desktop, Cursor, Copilot, and more. Once connected, your agent calls structured tools to read tasks, search memory, and record decisions — no copy-pasting context into the chat window.

Add the snippet below to your agent's MCP configuration file. Your vem API key is read automatically from ~/.vem/config.json — you never need to expose it in the config.

Privacy matters: vem uses a Bring Your Own Key model. Your AI provider keys (OpenAI, Anthropic, etc.) are stored only on your local machine and never sent to the vem cloud.

{
  "mcpServers": {
    "vem": {
      "command": "npx",
      "args": ["@vemdev/mcp-server"]
    }
  }
}

Tools available to your agent:

# Tools exposed by the vem MCP server:
# get_active_tasks()     — list current sprint tasks with status
# search_memory(query)   — semantic search across all memory artifacts
# read_decision(id)      — fetch a specific ADR by ID
# update_task(id, ...)   — mark progress and add evidence
# record_decision(...)   — write a new ADR from the agent session

Step 6 — The Web Memory Dashboard

The vem web app at app.vem.dev gives you a visual view of everything stored in your project memory. The Context tab shows your CONTEXT.md, current state, key decisions, and recent changelog entries all on one page.

The Memory tab hosts a chat interface you can use to ask questions about your project directly from the browser — the same semantic search your agents use, but in a conversational UI. It is particularly useful during onboarding or code review when you need to quickly orient a new contributor.

Key Decisions panel in the vem web app — all ADRs accessible to team members and agents

Step 7 — Implement Tasks Remotely with the vem Agent

vem does not just store context — it can act on it. The vem agent runner lets you trigger AI-powered task implementation from the web dashboard, delegating work to an agent running on your local dev machine or a cloud runner.

Your AI keys never leave your machine. The vem cloud only orchestrates which task to run and where — the actual agent execution and code changes happen locally. This is BYOK (Bring Your Own Key) by design.

# Start the vem runner — listens for tasks dispatched from the web
vem runner

# Or specify a particular AI agent
vem runner --agent claude

# The runner outputs a secure token you connect in the web Workspace tab

Step 8 — Track Agent Activity with Insights

vem insights shows a power score and command frequency breakdown for your project. It surfaces which workflow features you are using, which you are not, and how your agent activity patterns have evolved over time.

The power score is a simple metric (0–100) that rewards high-value behaviours: agent-driven implementation, decision recording, task-driven work, and memory finalisation.

# Show power score and command frequency
vem insights

Step 9 — Push Memory to the Cloud

vem push publishes a snapshot of your entire .vem/ memory to the vem cloud. The snapshot is marked pending until a matching Git push is detected — at that point it is verified using the git_hash + snapshot_hash pair and becomes permanently auditable.

Push after any significant session: after adding decisions, after completing tasks, after updating context. Your teammates and any agent connected via MCP will immediately see the updated memory on their next request.

# Publish current memory snapshot
vem push

# Check sync and connection status
vem status

Step 10 — Cycle Validation: Memory Stays Correct Over Time

Development never stops. New features can invalidate old decisions, refactors break assumptions captured in CONTEXT.md, and security issues can surface weeks after the original code was written. vem's cycle validation step is designed exactly for this.

When you close a sprint with vem cycle validate, vem checks each completed task's validation steps against the current codebase and flags items that need human review.

Run validation at the end of each cycle before you mark it done. It takes less than a minute and ensures your memory layer stays trustworthy — so agents in future cycles don't build on stale or incorrect foundations.

# Validate the active cycle before closing it
vem cycle validate

# Review specific task validation results
vem cycle validate --task TASK-003

# Close the cycle once validation passes
vem cycle close

The Full Memory Loop

Every AI session should leave the project in a better state than it found it. That means updated context, recorded decisions, completed tasks, and a fresh push to the cloud. With vem, this loop takes under two minutes and pays dividends on every session that follows.

# 1. Inspect what your agents currently see
vem pack

# 2. Record any decisions made this session
vem decision add "..." --context "..." --decision "..."

# 3. Update task progress
vem task done TASK-001 --evidence "Implemented in src/auth.ts, tests pass"

# 4. Refresh current state summary
vem context set current "Completed auth module. Next: add refresh token rotation."

# 5. Push to cloud and verify
vem push
vem status

Your agents start each session with full context. Your decisions are permanent and searchable. Your sprint state is always visible. And your memory is verified against your actual Git history — not just a file on disk.

vem is currently in early access. We're looking for our first users — developers and teams tired of re-explaining their project to AI agents every session. Early access is completely free. No credit card, no trial timer.

If you found this useful, sign up at vem.dev and let us know what you're building. Your feedback will directly shape the product. 🙏

Build Sprint-Driven AI Projects with vem: Cycles, Tasks, and Flow Metrics

vem.dev — Mon, 20 Apr 2026 19:36:03 +0000

🚀 vem is in early access — we're looking for our first users. If you try it and find it useful, we'd love to hear from you. Early access is completely free.

Your AI coding agent is smart, but it has no idea what you're working on this week. Every new session starts from scratch — no sprint goal, no priorities, no sense of what's blocked or nearly done. You spend the first five minutes re-explaining context instead of shipping.

vem fixes this with cycles. A cycle is a time-boxed, goal-driven container for tasks — exactly like a sprint. When a cycle is active, every agent that reads project context via vem automatically receives a "Current Sprint" block with the goal, open tasks, and progress percentage.

In this tutorial we'll build a complete sprint workflow from scratch.

Prerequisites — Install vem and Link a Project

Before you can create cycles and run agents you need three things: the vem CLI installed, your account authenticated, and your repository linked to a vem cloud project. The whole setup takes under two minutes.

Sign up for a free account at vem.dev, then grab your API key from the Keys page (vem.dev/keys). The key is the only secret you need — all AI credentials stay on your machine.

# 1. Install the CLI
npm install -g @vemdev/cli

# 2. Authenticate — paste your API key from vem.dev/keys
vem login <your-api-key>

# 3. Initialise vem memory in your repo (creates .vem/)
cd my-project
vem init

# 4. Link this repo to a vem cloud project
#    Run interactively — picks up your GitHub remote automatically
vem link

# 5. Confirm everything is connected
vem status

The Problem: AI Agents Have No Sprint Awareness

vem fixes this with cycles. A cycle is a time-boxed, goal-driven container for tasks — exactly like a sprint. When a cycle is active, every agent that reads project context via vem automatically receives a "Current Sprint" block with the goal, open tasks, and progress percentage. In this tutorial we'll build a complete sprint workflow from scratch.

Step 1 — Create Your First Cycle

Start by creating a cycle with a clear goal. The goal is the single sentence your AI agent will use to prioritise decisions inside this sprint.

# Create a draft cycle with a goal
vem cycle create "Sprint 1: Core Auth" --goal "Implement login, signup and session management"

# Start the sprint (moves it to active)
vem cycle start CYCLE-001

# Set as the active focus for all agents
vem cycle focus CYCLE-001

# Confirm it's live
vem cycle list

Step 2 — Populate the Sprint Backlog

With the cycle active, add tasks directly to it using the --cycle flag. Tasks inside a cycle inherit the sprint's goal and are surfaced to agents as in-scope work.

You can also assign tasks to a cycle from the web dashboard by dragging them from the backlog into the active cycle — useful when you already have a backlog built up.

vem task add "Implement JWT authentication" --cycle CYCLE-001
vem task add "Build signup form with validation" --cycle CYCLE-001
vem task add "Add password reset flow" --cycle CYCLE-001

# See only tasks in this cycle
vem task list --cycle CYCLE-001

Step 3 — The Web Dashboard

Every cycle and its tasks are reflected in real time on the vem web dashboard. The Cycles tab gives you a sprint-level view: goal, progress ring, task breakdown, and agent activity hours spent inside the cycle.

The Cycles tab — progress ring, task count, and agent hours per sprint

Step 4 — Cycle Detail and Task Board

Click into a cycle to see all its tasks, blocked items, and a timeline of agent activity. The board view groups tasks by status so you can see WIP at a glance.

The board also shows high-level metrics: total active tasks, blocked count, high-priority items, and cumulative agent usage (tool calls, turns, and minutes).

Cycle detail view — every task, every agent action, in one place

Step 5 — Give Your Agent Real-Time Sprint Context

When an AI agent connects via the vem MCP server, it calls get_active_tasks() and immediately receives the active cycle, its goal, and all tasks scoped to that sprint. No prompt engineering required.

// Agent calls:
get_active_tasks()

// vem returns:
{
  "cycle": {
    "id": "CYCLE-001",
    "title": "Sprint 1: Core Auth",
    "goal": "Implement login, signup and session management",
    "status": "active",
    "progress": 33
  },
  "tasks": [
    { "id": "TASK-001", "title": "Implement JWT authentication", "status": "active" },
    { "id": "TASK-002", "title": "Build signup form with validation", "status": "pending" },
    { "id": "TASK-003", "title": "Add password reset flow", "status": "pending" }
  ]
}

Add the MCP server to your agent's config:

{
  "mcpServers": {
    "vem": {
      "command": "npx",
      "args": ["-y", "@vemdev/mcp-server"]
    }
  }
}

Step 6 — Track Flow Metrics

As tasks move through the cycle, vem tracks throughput, WIP, and cycle time. Run vem task flow to see a live view of your team's delivery rate.

Flow metrics tell you whether you're moving fast or accumulating WIP debt — crucial for keeping AI-assisted sprints from drifting.

# Live flow metrics for the active cycle
vem task flow

# See which tasks are ready to be picked up next
vem task ready

Step 7 — Memory and Project Context

Beyond tasks, vem maintains a persistent memory layer: CONTEXT.md holds high-level project facts, CURRENT_STATE.md captures the latest progress, and decisions/ stores architectural records. Agents read this automatically — so they always know not just what to build, but why.

The Memory tab — context, decisions, and changelog all in one place

Step 8 — Close the Sprint and Sync

When the sprint is done, close the cycle to capture final state and push everything to the cloud. This creates a verified snapshot that other agents and team members can query.

# Close the sprint (prompts for retrospective note)
vem cycle close CYCLE-001

# Sync local memory to the cloud
vem push

# Check dashboard for verified snapshot
vem status

Implement Tasks Remotely with vem agent & vem runner

Once a cycle is set up you can trigger task implementation without ever leaving the browser. The vem runner is a background worker you start locally (or on a cloud VM) that polls the web dashboard for queued task runs and executes them inside a Docker sandbox using the AI agent of your choice.

Privacy first — Bring Your Own Key (BYOK). Your AI credentials (ANTHROPIC_API_KEY, OPENAI_API_KEY, GEMINI_API_KEY, or GITHUB_TOKEN) are read from your local environment and injected into the sandbox at runtime. They are never sent to vem's cloud — the vem platform only coordinates task routing, not AI execution.

# Set your AI key once (stays on your machine)
export ANTHROPIC_API_KEY=sk-ant-...

# Start the runner — polls the web dashboard every 10s
# Runs tasks in an isolated Docker sandbox by default
vem runner --agent claude --poll-interval 10

# Or run without Docker (no isolation)
vem runner --agent claude --unsafe

# vem agent wraps any AI CLI with sprint context + task tracking
# Supports: claude, codex, gemini, copilot, gh, cursor, code
vem agent claude --task TASK-001

# Auto-exit when the agent finishes (good for CI pipelines)
vem agent claude --task TASK-001 --auto-exit

Cycle Validation — Catch Regressions Before They Ship

Development never truly stops. New features can break existing behaviour, and fresh security vulnerabilities emerge as code evolves. vem's Cycle Validation tackles this with an AI agent that reviews every task in a cycle against a set of instructions you define.

Each cycle has a Validation panel where you describe what to check — missing error handling, unvalidated user inputs, hardcoded credentials, race conditions, or anything else relevant to your codebase. The agent runs against all tasks in the cycle and surfaces issues grouped by severity.

You choose when to run: manually on demand, on a daily schedule, or weekly — so every sprint close is automatically audited before the next one begins.

# Run vem agent on a specific task to validate it
# Use --auto-exit so the run completes and results are pushed
vem agent claude --task TASK-001 --auto-exit

# Or let vem runner pick up the validation job queued from the web
vem runner --agent claude

The Full Cycle, Closed Loop

Here's the complete workflow: create a goal-driven cycle → populate the backlog → activate → let agents work with full context via vem agent or vem runner → track flow → run cycle validation to catch regressions and security issues → close and sync.

Every step is reflected in the web dashboard and queryable via the MCP server.

# Install
npm install -g @vemdev/cli

# Init in your repo
vem init

# Create your first sprint
vem cycle create "Sprint 1" --goal "Ship the MVP login flow"
vem cycle start CYCLE-001
vem cycle focus CYCLE-001

Start your first cycle today with vem cycle create and see how much less time you spend explaining priorities to your AI assistant.

vem is currently in early access. We're looking for our first users — developers and teams who want to ship AI-assisted projects more intentionally. Early access is completely free. No credit card, no trial timer.

If you found this useful, Sign up for vem early access — It's free! and let us know what you're building. Your feedback will directly shape the product. 🙏