[ V·I·P·E·R ] — PHASED DEVELOPMENT WORKFLOW
VIPER

Phased workflow for Claude Code. Combats context rot.

Five canonical phases. One addressable artifact per phase. Deterministic validation. Zero slop.

$npm install -g @viper-ai/cli && viper init
MIT · ships CLI + MCP server + 5 Claude Code skills + 3 subagents
~/projects/viper-demo — zsh80×24
01The Flow

Five phases. One artifact each. Fresh context between.

Each phase writes a single canonical document under .viper/NNN-<slug>/. The next phase starts in a fresh context, reading only what came before. The validator enforces frontmatter, section skeletons, and task DAGs on every write.

V01 · opt
Vision
Fan out 4–8 ideators in parallel. Converge with the user on one direction.
vision.md
I02
Investigate
Truth-find the codebase. Fan out investigators. Build shared vocabulary.
investigation.md
P03
Plan
Feature → Story → Task tree with agent slots and a DAG-validated dependency map.
plan.md
E04
Execute
One executor per agent slot. JSONL events project into a live execution log.
execution.md
R05
Review
Guided demo walkthrough with [PAUSE] markers. Re-internalize what shipped.
review.md
flow: vision.md → investigation.md → plan.md → execution.md → review.md
gate: skill refuses to run unless upstream status == complete
state: draft → in-progress → complete
02Core Principles

What VIPER optimizes for.

#01

Maximize Ownership

The human stays the author at every phase. The agent does legwork — fan-out, reads, validation. The human owns every decision branch.

#02

Compressed Truth

One canonical artifact per phase. Re-orientable from a fresh context. No grep-the-diff archaeology for the reviewer.

#03

Zero-Slop Target

Deterministic validators reject structural drift on write. Frontmatter, sections, task DAGs — caught before they spread.

#04

Attention Maximizing

Each phase starts in fresh context. /clear between phases. The guided review forces re-internalization before ship.

03CLI Reference

viper(1)

Two bins land on your $PATH: viper (the CLI) and viper-mcp (the stdio server Claude Code spawns via .mcp.json).

viper init
[--targets claude-code,cursor,…] [--with-hooks] [--strict-hooks] [--force] [--non-interactive]
Install harness artifacts into the current project. Default (no --targets) is Claude Code only; multi-tool writes .viperrc.json for uninstall.
$ viper init --with-hooks
  ✓ .claude/skills/viper-1-vision
  ✓ .claude/skills/viper-2-investigate
  ✓ .claude/skills/viper-3-plan
  ✓ .claude/skills/viper-4-execute
  ✓ .claude/skills/viper-5-review
  ✓ .claude/agents/viper-{ideator,investigator,executor}
  ✓ .mcp.json (merged)
  ✓ .viper/ initialized
viper new
[slug] [--phases vision,plan,…] [--author email]
Atomically scaffold .viper/NNN-<slug>/ with the selected phase files. Numbering is deterministic.
$ viper new add-streaming
  ✓ .viper/001-add-streaming/
      investigation.md  (draft)
      plan.md           (draft)
      execution.md      (draft)
      review.md         (draft)
viper list
[--json] [--status draft|in-progress|complete]
List ideas with their current-phase status. TUI table in a terminal, JSON in pipes.
$ viper list
  001  add-streaming   I:complete  P:in-progress
  002  refactor-auth   V:complete  I:draft
viper status
<idea> [--json] [--phase vision|…]
Detailed per-phase view: status, task progress, error/warning counts, deviation + note counts.
$ viper status 001
  add-streaming
  V  ━━━━━━━━━━  complete
  I  ━━━━━━━━━━  complete
  P  ━━━━━━━░░░  in-progress  18/24 tasks
viper validate
[path] [--json] [--strict]
Run the validator engine. File, idea dir, or whole tree. Catches structural drift before it spreads.
$ viper validate
  OK     .viper/001-add-streaming/vision.md
  ERROR  plan.md:23  TASK_DAG_CYCLE  T1.2.3 → T1.2.5 → T1.2.3
  WARN   plan.md:7   SECTION_EMPTY   "Acceptance Criteria"
viper migrate
[--dry-run] [--json]
Walk every phase doc and run schema migrations. v1 is current; framework wired for future versions.
$ viper migrate --dry-run
  OK     12 files at schema v1 (no-op)
viper uninstall
[--no-keep-docs]
Remove skills, agents, MCP entry, and PostToolUse hook. Preserves unrelated .mcp.json servers.
$ viper uninstall
  ✓ removed .claude/skills/viper-*
  ✓ removed .claude/agents/viper-*
  ✓ unmerged .mcp.json
  ⏵ kept .viper/ (use --no-keep-docs to remove)
04MCP Tools

12 stdio tools. Thin adapters over the same core lib the CLI uses.

viper_ping
Capability probe. Returns { ok, version, cwd }.
viper_validate
Validate a phase file, idea dir, or the whole tree.
viper_list_ideas
List ideas with per-phase status.
viper_get_phase
Read a phase doc; returns parsed frontmatter, sections, tasks, issues.
viper_create_idea
Atomically create a new idea scaffold from templates.
viper_set_status
Set viper.status on a phase doc; refresh updated.
viper_advance_phase
Verify from.status == complete; create to.md from template if missing.
viper_ensure_phase
Create a phase doc from template if missing.
viper_search_tasks
Cross-idea task search by query, agent, idea, depends, status.
viper_record_event
Append task_start / task_done / deviation / note to per-agent JSONL.
viper_merge_execution
Project per-agent JSONL events into canonical execution.md. Idempotent.
viper_detect_spec_tools
Detect OpenSpec / SpecKit / GSD in the current project.
Skills probe viper_ping at boot and shell out to viper <subcommand> if the MCP server isn't reachable. Graceful degradation.
05Integrations

Four agent tools in v1. Same VHF, native paths each.

Claude Codeshipping
Default `viper init`. Skills, subagents, merged `.mcp.json`, optional PostToolUse hook. Semver-safe parity with pre-harness installs.
Cursorshipping
`viper init --targets cursor` (or wizard). `.cursor/skills/`, agents, MCP, hooks.json v1. Shared `.agents/skills/` when installed with Claude.
OpenCodeshipping
`.opencode/skills/`, agents, and `opencode.json` MCP block via `opencodeTransformer`.
Pishipping
Partial — skills under `.pi/skills/` and VIPER block in `AGENTS.md`. Subagents and MCP require extensions or another target.
Codex CLIplanned
TOML subagents and `config.toml` MCP — on the investigation matrix, not in v1 transformers.
Copilot / Junieplanned
Documented in the VHF support matrix; transformers not shipped in this release.
06VIPER Harness Format

VHF — one canonical schema, many agent tools.

VIPER phase artifacts (`.viper/<idea>/*.md`) stay tool-agnostic. Harness artifacts are different: they are the repo-local files that teach an agent how to run VIPER — skills, subagents, hooks, MCP entries, and related config. VIPER Harness Format (VHF) is the open schema and TypeScript library that describes those artifacts in a single canonical shape, then transforms them into each product's native paths (Claude Code, Cursor, OpenCode, Pi).
PURPOSE
  • Interchange — validate and generate harness config without hand-copying paths per tool.
  • Transform — pure functions map VHF to .claude/, .cursor/, .opencode/, .pi/, etc., with merge policies for JSON (MCP, hooks).
  • Extend — third-party bundles can ship VHF-shaped artifacts and reuse the same validators and transformers the CLI uses.
ARTIFACT KINDS
KIND
STANDARD
SCHEMA
DESCRIPTION
skill
agentskills.io
SkillFrontmatterSchema, parseSkillMarkdown()
Directory per skill with `SKILL.md`; required `name` and `description` in YAML frontmatter.
subagent
VHF
SubagentFrontmatterSchema, parseSubagentMarkdown()
Markdown file with YAML frontmatter (`name`, `description`) and a non-empty system-prompt body.
hook
VHF
VhfHookSchema, ClaudeHookBundleSchema
Canonical events (`postToolUse`, `preToolUse`, `sessionStart`) with command or prompt handlers; Claude bundle shape also validated.
mcp
VHF
VhfMcpSchema, McpServerEntrySchema
Root key `mcpServers` with at least one stdio or remote server entry (`command` or `url`).
rule
VHF (planned emit)
Defined in catalog; no parser shipped in v1
Project rules with optional `globs` / `alwaysApply` — schema reserved for future transformers.
instruction
VHF (planned emit)
Defined in catalog; no parser shipped in v1
Repo-wide guidance; often merged into `AGENTS.md` / `CLAUDE.md` at transform time.
command
VHF (planned emit)
Defined in catalog; no parser shipped in v1
Slash-invoked workflows; VIPER phase flows use skills, not commands.
plugin
VHF (planned emit)
Defined in catalog; no parser shipped in v1
Bundle manifest referencing other artifacts for marketplace distribution.
All parsers and Zod schemas export from @viper-ai/harness (src/schema/). Skills are the only kind aligned to an external standard; the rest are VHF-first until the ecosystem converges. Core types: HarnessArtifact, HarnessArtifactKind, AgentToolId, TransformContext, TargetWrite, TransformFn.
V1 TRANSFORMERS
claude-code
claudeCodeTransformer
Default `viper init`; parity with legacy install paths.
cursor
cursorTransformer
`.cursor/skills/`, agents, MCP, hooks v1; compat `.agents/skills/` when paired with Claude.
opencode
opencodeTransformer
`.opencode/` tree and `opencode.json` `mcp` block.
pi
piTransformer
Skills + `AGENTS.md` merge only; subagents and MCP documented as gaps.
SDK / PACKAGE
npm install @viper-ai/harness
Package: @viper-ai/harness
Published from `libs/harness/` via `npm run publish`. VIPER template markdown ships inside `@viper-ai/cli` and `@viper-ai/mcp`, not as a separate npm package.
loadViperBundle() (monorepo / viper CLI)
Loads the VIPER template tree as `HarnessArtifact[]` from `@viper-ai/core` — not part of the published harness API.
getTransformerForTarget(id)
Resolve the transformer for `claude-code` | `cursor` | `opencode` | `pi`.
availableTransformers()
List target IDs registered in this package release.
applyTargetWrites(root, writes, force)
Apply `TargetWrite[]` with merge policies (`mcp-viper`, `mcp-opencode`, hook merges, `agents-md-viper`).
parseSkillMarkdown / parseSubagentMarkdown
Validate markdown artifacts before transform or publish.
ViperRcSchema
Zod schema for `.viperrc.json` install manifest (multi-target uninstall).
VALIDATE A SKILL.MD (NO FILESYSTEM WRITES)
import { readFile } from 'node:fs/promises';
import { parseSkillMarkdown } from '@viper-ai/harness';

const raw = await readFile('artifacts/skills/my-skill/SKILL.md', 'utf8');
const result = parseSkillMarkdown(raw, { path: 'my-skill/SKILL.md' });

if (!result.ok) {
  console.error(result.errors.join('\n'));
  process.exit(1);
}

console.log(result.data?.frontmatter.name, '— OK');
TRANSFORM THE VIPER BUNDLE FOR CURSOR
import {
  getTransformerForTarget,
  applyTargetWrites,
  type HarnessArtifact,
} from '@viper-ai/harness';

const root = process.cwd();
const artifacts: HarnessArtifact[] = [/* your VHF artifacts */];
const target = 'cursor';

const transform = getTransformerForTarget(target);
const writes = transform(artifacts, { root, target, force: false });

await applyTargetWrites(root, writes, false);
console.log(`Wrote ${writes.length} paths under ${root}`);
End users typically run viper init --targets claude-code,cursor instead of calling the SDK directly. The CLI uses the same harness pipeline; .viperrc.json records what was installed for manifest-driven viper uninstall.
07FAQ

Common questions.

Q.01Why phases instead of one long agentic loop?
Long loops leak context and confidence. Phases force a fresh start with only the prior artifact as input, so the agent (and the human) stay oriented. The artifact itself is the compression — there is one canonical document per phase, no scrollback archaeology.
Q.02How is this different from OpenSpec or SpecKit?
VIPER sits above spec tooling. Vision and Investigate are pre-spec; Plan detects OpenSpec / SpecKit / GSD and hands off when present. If you already have a spec workflow, VIPER frames it; if you don't, VIPER fills the gap with its own Feature → Story → Task tree.
Q.03Does it lock me into Claude Code?
No. Phase docs are plain markdown. Harness config uses VHF (`@viper-ai/harness`) and ships transformers for Claude Code, Cursor, OpenCode, and Pi — opt in with `viper init --targets`. Default init remains Claude-only for backwards compatibility.
Q.04Can multiple agents actually work in parallel?
Yes. Plan emits a DAG-validated Parallel Execution Map with agent slots. Execute spawns one executor per slot. Each writes JSONL events to its own file; the orchestrator merges them into execution.md idempotently. No file-level contention.
Q.05What does the validator catch?
Frontmatter schema drift, missing or empty sections, task ID duplicates, task DAG cycles, broken upstream references, phase-vs-directory mismatches. Runs on every write via PostToolUse hook (advisory by default, strict on opt-in).
Q.06Is it production ready?
Pre-release. CLI, MCP server, VHF library (`@viper-ai/harness`), four agent-tool transformers, and the init wizard are functional. npm publish for the harness package and broader tool matrix are ongoing — see GitHub for status.
Q.07Why a Review skill and review.md?
Review with Narrative. Large reviews — even human-authored ones — are tedious and routinely skipped, so ownership leaks out the moment the PR opens. The Review skill produces a guided demo walkthrough with [PAUSE] markers; the creator re-internalizes what shipped before shipping it. Other team members can re-run the skill on a completed review and get the same narrated tour, gaining real understanding instead of grep-the-diff archaeology.
Q.08Who built it?
Syncrea GmbH — a Swiss software studio. VIPER is open source under MIT, developed in the open at github.com/syncrea/viper-ai.
$ install

One command. Phased flow on every change.

Requires Node 20+ and a project Claude Code can see. Run it in a fresh repo, type /viper, and start an idea.

$npm install -g @viper-ai/cli && viper init