vibe-graph

name	vibe-graph
description	Design a workflow via 3-stage Vibe Graphing pipeline
user_invocable	true

/vibe-graph — Design Workflow via Vibe Graphing

Convert a natural language intent into an executable workflow stored as real graph nodes and edges in MinnsDB. Uses a 3-stage compilation pipeline (Role Assignment → Structure Design → Semantic Completion).

Claude does all reasoning. The CLI provides graph context. The server stores the result.

Usage

When the user invokes /vibe-graph <intent>:

Step 0: Gather Context

Query the graph for relevant prior knowledge:

minns vibe-graph "<intent>" --json

This returns:

• graph_context — NLQ answer, resolved entities, related memories and strategies
• proven_strategies — strategies that have worked for similar tasks
• existing_workflows — workflows that may be reusable or adaptable

Use this context to inform your design decisions in the stages below.

Stage 1: Role Assignment

You (Claude) reason about this — do NOT delegate to the CLI.

Based on the intent and graph context, determine the roles/agents needed:

1. Decompose the intent into distinct concerns
2. Assign a role to each concern (e.g., code, review, test, research, architect, ops)
3. Consider which roles can work in parallel vs. sequentially

Present the roles to the user in a table:

Role	Responsibility	Why
architect	Design the API surface	Ensures consistency with existing patterns
code	Implement the changes	Core implementation work
test	Write and run tests	Verify correctness
review	Review the final changes	Quality gate

Wait for user approval before proceeding. They may add, remove, or modify roles.

Stage 2: Structure Design

You (Claude) reason about this — do NOT delegate to the CLI.

Design the workflow graph:

1. Create a step for each role, with a clear task description
2. Define depends_on relationships (what must complete before this step starts)
3. Define inputs and outputs (data flow between steps)
4. Maximize parallelism — only add dependencies where truly needed
5. Incorporate proven strategies from the graph context

Present the structure as a dependency graph:

[architect] ──→ [code] ──→ [review]
                  │
                  └──→ [test] ──→ [review]

With a table of steps:

Step ID	Role	Task	Depends On	Inputs	Outputs
design	architect	Design API surface matching existing patterns	—	intent	api_spec
implement	code	Implement the API changes	design	api_spec	code_changes
test	test	Write integration tests for new endpoints	implement	code_changes	test_results
review	review	Review implementation and tests	implement, test	code_changes, test_results	approval

Wait for user approval before proceeding. They may restructure dependencies or modify tasks.

Stage 3: Semantic Completion & Save

After approval, build the complete workflow JSON and save it to MinnsDB:

cat <<'WORKFLOW_JSON' | minns workflow create --file - --group_id "$MINNS_GROUP_ID"
{
  "name": "<descriptive-name>",
  "intent": "<original intent>",
  "description": "<detailed description of what this workflow accomplishes>",
  "steps": [
    {
      "id": "design",
      "role": "architect",
      "task": "Design API surface matching existing patterns in the codebase",
      "depends_on": [],
      "inputs": ["intent"],
      "outputs": ["api_spec"],
      "metadata": {}
    },
    {
      "id": "implement",
      "role": "code",
      "task": "Implement the API changes based on the approved design",
      "depends_on": ["design"],
      "inputs": ["api_spec"],
      "outputs": ["code_changes"],
      "metadata": {}
    }
  ],
  "metadata": {}
}
WORKFLOW_JSON

The server decomposes this into:

• A root Concept node (workflow:<name>, type Strategy)
• A Concept node per step (with role, task, inputs, outputs as properties)
• workflow:member_of edges from each step → root
• workflow:depends_on edges between steps (carrying data flow info)
• A StateMachine per step for execution tracking (pending → ready → running → completed | failed)

Present the result: workflow ID, node count, edge count, step-to-node-ID mapping.

After Saving

Offer the user options:

1. Execute now — invoke /workflow-run <workflow_id>
2. Execute later — just save for future use
3. Modify — adjust and re-save (uses minns workflow update)

Design Principles

• Maximize parallelism: Independent steps should not depend on each other
• Reuse proven strategies: If the graph context contains strategies that worked before, incorporate them
• Keep steps atomic: Each step should have one clear deliverable
• Data flows matter: Be explicit about what each step produces and consumes
• Claude reasons, CLI stores: Never ask the CLI to do reasoning — that's your job

Examples

/vibe-graph Review the PR changes and write comprehensive tests
/vibe-graph Investigate the performance regression in the API
/vibe-graph Refactor the authentication module to use OAuth2
/vibe-graph Add a new REST endpoint for user preferences with full test coverage