Skip to content

OROTOV workflow skills

Guide coding agents through engineering work and keep claims distinct from proof.

OROTOV skills guide discovery, planning, implementation, and debugging. A workspace-scoped MCP key gives the tool access to one workspace; connectors and independent checks provide evidence beyond an actor claim.

Read the docs

  • 01 - Guided

    Each skill has a defined task

    The published workflow names required inputs, outputs, and checks at each step. People can review the same process an agent follows.

  • 02 - Scoped

    Each key reaches one workspace

    A skill reaches OROTOV through a workspace key that grants nothing outside that workspace. Installing it does not widen what an actor can see.

  • 03 - Observed

    Claims stay claims

    A skill can report what it did as Claimed evidence. A connector or independent system must supply stronger evidence.

Five published workflow skills

From discovery to debugging

The public pack contains five skills. Handoff is a way to pass work between contributors, not a separate published skill.

Deliveryorotov-build

orotov-build

Implements one issue with a failing test first, then requests separate specification and quality reviews.

Trigger
/orotov-build
Writes
Code, tests, commits
Approval
Two reviews, then commit

Procedure

  1. Read the issue context

    Spec, acceptance criteria, test requirements and the story behind them, fetched from the workspace rather than guessed.

    Requiresissue context fetched

  2. Claim the issue

    The issue moves to In Progress before work starts, so two actors cannot pick up the same thing.

    Blocksissue claimed

  3. Red, then green

    A failing test first, then the implementation that makes it pass. The test is the specification made executable.

    Blocksa failing test precedes implementation

  4. Two isolated reviews

    A fresh spec reviewer and a fresh quality reviewer each read the code from disk. Neither sees the other conversation.

    Blocksboth reviews approved

  5. Link the commit

    The commit is linked to the issue, which is what lets a connector observe the work later.

    Requirescommit linked to the issue

Shape of the procedure

orotov-buildPublished
name: orotov-build
trigger: /orotov-build <id>
steps:
  - id: context
    requires: issue.context
  - id: claim
    blocks_on: issue.claimed_elsewhere
  - id: tdd
    blocks_on: test.not_failing_first
  - id: review
    blocks_on: review.rejected
  - id: link
    requires: commit.linked

Guardrails

  • Cannot move an issue to Done without a passing test and a linked commit.
  • Reviewers run in isolation, so no reviewer inherits the implementer reasoning.
  • Everything it records is Claimed evidence until a connector observes it.

Illustrative command example

orotov-build example
/orotov-build 41

implement -> write failing test -> make it pass
spec review      approved
quality review   approved
commit linked | all tests green

Issue #41 -> Done

  1. orotov-discover

    Clarifies the problem, acceptance criteria, constraints, and dependencies before the team plans implementation.

    run by scope

  2. orotov-scope

    Turns reviewed requirements into board stories and issues. A person approves the scope before build work begins.

    /orotov-scope "…"

  3. orotov-plan

    Orders implementation tasks by dependency and records acceptance criteria and a test plan for each task.

    run by scope

  4. orotov-build

    Implements one issue with a failing test first, then requests separate specification and quality reviews.

    /orotov-build <id>

  5. orotov-debug

    Reproduces a bug, records each finding on the board, and links the proposed fix to the investigation.

    /orotov-debug "…"

Install and connect

How skills and evidence work together

Skills guide an actor through work. Connectors observe configured external systems. Installing a skill does not prove that work is complete or grant access outside its workspace.

  1. Install the workflow package

    Install the workflow package supported by your coding tool. The verified skills directories are: Claude Code, Cursor, Codex CLI, Gemini CLI, Opencode.

  2. Create a workspace key

    Create the key in the workspace the tool will use. Copy it when it is shown once, then store it in the tool configuration.

  3. Connect through MCP

    Use the connector command to set https://api.orotov.com/mcp as the MCP endpoint. The key remains limited to its workspace.

  4. Guide the work with skills

    Use the published skills for discovery, scoping, planning, implementation, and debugging. Record decisions and issue status so another contributor can continue.

  5. Observe reality independently

    Configured connectors can observe repository events. Independent checks can verify supported outcomes; the person or agent doing the work cannot promote its own claim.

A workspace key is a credential. Keep it out of public logs, issue text, shared shell history, and screenshots. Hosted access at https://api.orotov.com/mcp is private-pilot; production controls are not yet independently verified.

Published versions

Published packages

The npm connector is stable. The Python CLI is a release candidate and requires prerelease installation.

Stable package

@orotov/connect 0.1.0

Creates an MCP configuration for supported coding tools and installs skills for Claude Code, Cursor, Codex CLI, Gemini CLI, Opencode.

hosted MCP command
npx @orotov/connect <API_KEY> --url https://api.orotov.com/mcp
Release candidate

orotov-cli 0.1.0rc1

Runs the local OROTOV stack. This package is still a Python release candidate.

Python prerelease install
pip install --pre orotov-cli
  • Skills guide how an agent discovers, scopes, plans, builds, debugs, and hands off work.
  • MCP transports scoped tools through the mcp__orotov__* namespace.
  • CLI operates the local stack at http://localhost:8000.
  • Connectors record Observed evidence for supported source events. Independent systems can verify supported outcomes.

Why use a published skill?

A skill gives a coding agent a repeatable workflow.

A published skill states its inputs, expected outputs, and checks. The workspace key limits which project the tool can access. The skill can report work, but it cannot verify its own result.

  • Different instructions in each sessionA published workflow with named inputs and outputs
  • An agent reporting its own work as provenActor claims capped at Claimed evidence
  • A key that reaches every workspaceA key that resolves to exactly one workspace
  • Evidence collected after a status changeA board rule checks required evidence before Done

Evidence boundary

What each actor is allowed to write

  • SkillScopes the work into stories and issues on the boardClaimed
  • SkillImplements one issue and records the work it performedClaimed
  • ActorLinks the commit that carries the changeClaimed
  • ConnectorObserves the pushed commit through a signed deliveryObserved
  • ConnectorObserves the check run and its outcomeObserved
  • ReconcilerCompares the terminal state against the evidence its lane requiresVerified

The service keeps human and agent evidence at Claimed. A connector or independent system must confirm the result before it reaches a higher level.

Start with scoped access

Create a workspace before connecting a coding tool.

The workspace issues the key once. You can revoke it without changing access for another workspace.

Read the security summary