# [Feature Request] Complete Review Flow with Multi-Level Commenting

[rbcb-dev]

TL;DR

Agent Hive's current flow is Plan → Approve → Execute → Merge. This proposal adds optional review checkpoints and commenting capabilities throughout that flow:

• Comment on anything: plans, tasks, diffs, individual lines of code
• Blocker comments: flag issues that halt execution until resolved
• Diff review before merge: see what changed per-task before merging
• Works in VSCode and OpenCode: the two IDEs we actively support

The core Hive workflow stays the same. All new features are additive. You can use as much or as little as you want.

---

Background

This extends Issue #4 (Built-in Editor for Plan Review), which covers rich plan editing and inline comments. Here we expand commenting to cover the entire development flow and add structured diff review.

The gap: Hive gives you approval at the plan stage, but no visibility into what changed until after merge. Some teams want checkpoints without reintroducing the slow PR review cycle that Hive deliberately avoids.

---

What This Adds

Multi-level commenting with support for:

• Prompt refinement ("clarify this requirement")
• Plan sections ("reconsider this approach")
• Tasks ("split this into two tasks")
• Diffs ("this line has a bug")
• Individual lines of code

Blocker priority that halts execution:

• Normal comments: informational, no blocking
• Important comments: warning, continues execution
• Blocker comments: halts until resolved

Per-task diff review:

• View what changed in each task's worktree
• Comment on specific hunks or lines
• Approve or request changes before merge

Audit trail persistence:

• Comments stored in .hive/features/<name>/comments/
• Survives across sessions
• Machine-readable JSON with human-readable views

---

How It Works

┌──────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐    ┌──────────┐
│  PROMPT  │───►│   PLAN   │───►│ EXECUTE  │───►│  REVIEW  │───►│  MERGE   │
└──────────┘    └──────────┘    └──────────┘    └──────────┘    └──────────┘
     │               │               │               │               │
     ▼               ▼               ▼               ▼               ▼
  [OPTIONAL]     [REQUIRED]      [PER-TASK]     [OPTIONAL]      [PER-TASK]
  Refinement     Approval Gate    Blocker        Diff Review     Cleanup
  Comments       (existing)       Injection      Comments

Plan approval remains mandatory (that's Hive's core safety). Everything else is opt-in. If you don't add comments, nothing changes. If you don't review diffs, tasks merge as before.

---

Technical Approach

Comment Schema

Comments are stored as JSON files in the .hive/ directory:

interface HiveComment {
  id: string;
  parentId?: string;                  // for threading
  target: {
    type: 'prompt' | 'plan' | 'task' | 'diff' | 'file' | 'line';
    featureName: string;
    taskFolder?: string;              // "01-implement-feature"
    file?: string;                    // source file path
    line?: number;                    // single line
    lineRange?: { start: number; end: number };
    hunkIndex?: number;
  };
  body: string;                       // markdown
  author: 'user' | 'agent';
  priority: 'normal' | 'important' | 'blocker';
  status: 'open' | 'resolved' | 'wontfix';
  createdAt: string;
  updatedAt: string;
}

Comments live at .hive/features/<name>/comments/<id>.json. This keeps them version-controlled and inspectable outside the IDE.

How Tools Detect Changes

When an agent calls a Hive tool (like hiveExecStart or hiveExecComplete), the tool checks for relevant changes since the last call:

// Inside tool execution
const changes = detectChanges(feature, lastCheckpoint);

if (changes.blockers.length > 0) {
  return {
    result: "⚠️ BLOCKED",
    blockers: changes.blockers,
    suggestedAction: "review"
  };
}

// Normal execution continues...
return {
  result: "Task started successfully",
  newComments: changes.newComments  // agent sees these
};

The agent decides what to do with this information. We don't inject context or manipulate the conversation—we return change data in the normal tool response.

Diff Review

For viewing diffs, we use what already exists:

VSCode approach:

• vscode.diff(leftUri, rightUri, title) for side-by-side comparison
• Comment Controller API for inline threaded comments
• No custom WebviewPanel needed for basic diff viewing

Additional UI (tree view for navigation):

Feature: user-auth (3 tasks)
├── 01-setup-database         [MERGED]
├── 02-implement-auth-service [READY FOR REVIEW]
│   ├── src/auth.service.ts   +89 -5
│   ├── src/jwt.ts            +45 -0
│   └── tests/auth.spec.ts    +35 -0
└── 03-add-api-routes         [IN PROGRESS]

Clicking a file opens VSCode's native diff view. Comments use VSCode's Comment Controller.

VSCode + OpenCode Focus

We build for:

• VSCode (via vscode-hive extension): full diff view, Comment Controller, tree views
• OpenCode (via opencode-hive plugin): MCP tools, limited UI

Other IDEs (JetBrains, Cursor, CLI) could be supported later. We're not designing around them now.

---

Technical Implementation Details

This section covers the VSCode APIs and patterns we'll use. All approaches rely on native VSCode capabilities—no custom WebviewPanel editors required for core functionality.

Diff Viewer Implementation

VSCode provides the vscode.diff command for opening side-by-side comparisons. We use this with virtual URIs pointing to base and modified file contents.

Opening a single diff:

import * as vscode from 'vscode';

// Create URIs for base (left) and modified (right) versions
const baseUri = vscode.Uri.file('/path/to/base/file.ts');
const modifiedUri = vscode.Uri.file('/path/to/worktree/file.ts');

await vscode.commands.executeCommand(
  'vscode.diff',
  baseUri,
  modifiedUri,
  'auth.service.ts (base ↔ worktree)',
  { viewColumn: vscode.ViewColumn.One }
);

For reviewing multiple files at once, VSCode 1.86+ supports the multi-diff editor:

Multi-diff editor example

// Review all changed files in a task at once
const changes = [
  { uri: modifiedFile1, original: baseFile1, modified: modifiedFile1 },
  { uri: modifiedFile2, original: baseFile2, modified: modifiedFile2 },
  { uri: modifiedFile3, original: baseFile3, modified: modifiedFile3 }
];

await vscode.commands.executeCommand(
  'vscode.changes',
  'Review: 02-implement-auth',
  changes
);

In practice, we get the base and worktree paths from simple-git. The worktree lives at .hive/.worktrees/<feature>/<task>/, and the base branch is known from the plan metadata.

Comment Controller Integration

VSCode's Comment Controller API provides native threaded comments that work in both regular editors and diff views.

Creating the controller:

const controller = vscode.comments.createCommentController(
  'hive.review',      // unique ID
  'Hive Code Review'  // label in UI
);

// Register for disposal
context.subscriptions.push(controller);

Enabling "Add Comment" in gutters:

controller.commentingRangeProvider = {
  provideCommentingRanges(document: vscode.TextDocument) {
    // Allow comments on any line in supported files
    return {
      ranges: [new vscode.Range(0, 0, document.lineCount - 1, 0)],
      enableFileComments: true  // file-level comments too
    };
  }
};

Creating comment threads:

Full thread creation example

interface HiveVSCodeComment extends vscode.Comment {
  id: string;
  body: string | vscode.MarkdownString;
  author: { name: string; iconPath?: vscode.Uri };
  mode: vscode.CommentMode;
  contextValue?: string;  // 'blocker' | 'suggestion' | 'question'
  reactions?: vscode.CommentReaction[];
}

// Create thread at specific line
const thread = controller.createCommentThread(
  documentUri,
  new vscode.Range(42, 0, 42, 100),  // line 42
  [
    {
      id: 'comment-abc123',
      body: new vscode.MarkdownString('**Blocker**: This breaks backward compatibility'),
      author: { name: 'User' },
      mode: vscode.CommentMode.Preview
    }
  ]
);

// Configure thread behavior
thread.state = vscode.CommentThreadState.Unresolved;
thread.collapsibleState = vscode.CommentThreadCollapsibleState.Expanded;
thread.canReply = true;
thread.label = 'Blocking';  // shown in thread header

Comment actions via menus:

{
  "contributes": {
    "commands": [
      { "command": "hive.resolveComment", "title": "Resolve" },
      { "command": "hive.markBlocker", "title": "Mark as Blocker" }
    ],
    "menus": {
      "comments/commentThread/context": [
        { "command": "hive.resolveComment", "when": "commentController == hive.review" }
      ],
      "comments/comment/context": [
        { "command": "hive.markBlocker", "when": "commentController == hive.review" }
      ]
    }
  }
}

Comments work on both sides of a diff view. The left side (base) and right side (modified) are separate documents, so we track which side a comment targets via the URI.

Plan Editor with Comments

For plan review, two approaches are viable:

Option 1: Native markdown + Comment Controller

Open the plan as a regular markdown file. Comments attach to the source markdown using the Comment Controller. Simple, but comments only appear in the source view, not in the rendered preview.

const planUri = vscode.Uri.file('.hive/features/auth/plan.md');
await vscode.window.showTextDocument(planUri);
// Comment Controller handles the rest

Option 2: WebviewPanel for rich editing

For inline comments visible in rendered markdown, use a WebviewPanel with custom highlighting:

WebviewPanel implementation

const panel = vscode.window.createWebviewPanel(
  'hive.planEditor',
  'Plan Review: user-auth',
  vscode.ViewColumn.One,
  {
    enableScripts: true,
    retainContextWhenHidden: true
  }
);

panel.webview.html = `
<!DOCTYPE html>
<html>
<head>
  <script src="${markedJsUri}"></script>
  <style>
    .has-comment { background: #fff3cd; cursor: pointer; }
    .comment-marker { 
      display: inline-block;
      width: 16px;
      height: 16px;
      background: #ffc107;
      border-radius: 50%;
      margin-left: 4px;
      vertical-align: middle;
    }
  </style>
</head>
<body>
  <div id="rendered-content"></div>
  <script>
    const vscode = acquireVsCodeApi();
    
    window.addEventListener('message', event => {
      if (event.data.type === 'updateContent') {
        document.getElementById('rendered-content').innerHTML = 
          marked.parse(event.data.markdown);
        highlightCommentedSections(event.data.comments);
      }
    });
    
    function highlightCommentedSections(comments) {
      comments.forEach(c => {
        // Add visual markers for sections with comments
      });
    }
    
    document.addEventListener('click', e => {
      if (e.target.classList.contains('comment-marker')) {
        vscode.postMessage({ 
          command: 'showComment', 
          id: e.target.dataset.commentId 
        });
      }
    });
  </script>
</body>
</html>
`;

// Handle messages from webview
panel.webview.onDidReceiveMessage(message => {
  switch (message.command) {
    case 'addComment':
      createComment(message.sectionId, message.text);
      break;
    case 'showComment':
      focusCommentThread(message.id);
      break;
  }
});

We'll likely start with Option 1 (native markdown) for simplicity. Option 2 is available if users need inline comment visualization.

Copilot Chat Integration

VSCode supports custom chat participants that can integrate with Copilot. A @review participant would let users ask Copilot to analyze diffs directly in chat.

Register the participant in package.json:

{
  "contributes": {
    "chatParticipants": [{
      "id": "hive.review",
      "name": "review",
      "description": "Review Hive task changes",
      "commands": [
        { "name": "diff", "description": "Analyze diff for a task" },
        { "name": "comment", "description": "Add a review comment" },
        { "name": "approve", "description": "Approve task changes" }
      ]
    }]
  }
}

Implement the request handler:

Chat participant implementation

const participant = vscode.chat.createChatParticipant(
  'hive.review',
  async (request, context, stream, token) => {
    
    if (request.command === 'diff') {
      const task = parseTaskFromPrompt(request.prompt);
      const diffText = await getDiffForTask(task);
      
      // Stream the diff to Copilot for analysis
      const messages = [
        vscode.LanguageModelChatMessage.User(
          `Review this diff and identify potential issues:\n\n${diffText}`
        )
      ];
      
      const response = await request.model.sendRequest(messages, {}, token);
      
      for await (const fragment of response.text) {
        stream.markdown(fragment);
      }
      
      return { metadata: { command: 'diff', task } };
    }
    
    if (request.command === 'comment') {
      const { file, line, text } = parseCommentRequest(request.prompt);
      await addReviewComment(file, line, text);
      stream.markdown(`✓ Added comment at \`${file}:${line}\``);
      return { metadata: { command: 'comment' } };
    }
    
    if (request.command === 'approve') {
      const task = parseTaskFromPrompt(request.prompt);
      await approveTask(task);
      stream.markdown(`✓ Approved task: ${task}`);
      return { metadata: { command: 'approve', task } };
    }
  }
);

// Suggest follow-up actions based on context
participant.followupProvider = {
  provideFollowups(result, context, token) {
    if (result.metadata?.command === 'diff') {
      return [
        { prompt: 'Approve these changes', command: 'approve' },
        { prompt: 'Add a comment about this', command: 'comment' }
      ];
    }
    return [];
  }
};

context.subscriptions.push(participant);

This gives users a natural language interface for reviews: @review /diff 02-implement-auth analyzes the task's changes, then suggests follow-up actions.

Real Extension Patterns

Several existing extensions solve similar problems and provide proven patterns:

GitHub Pull Requests and Issues extension:

• Uses Comment Controller for PR review threads
• Maps local line numbers to GitHub's position format
• Uses review: URI scheme to distinguish diff sides
• Stores PR context in comment contextValue

GitLens:

• Uses TextEditorDecorationType for inline blame annotations
• Comment Controller for code discussions
• WebviewPanels for rich history visualization

These patterns inform our approach: use native VSCode APIs where possible, fall back to WebviewPanel only for truly custom UI requirements.

---

GitHub Copilot Terms of Service

This architecture operates within standard MCP tool behavior. Specifically:

We do NOT:

• Extend or manipulate Copilot sessions
• Inject context outside of tool responses
• Make programmatic API calls to Copilot
• Stream or push data to the LLM

We DO:

• Return data in normal tool responses (standard MCP behavior)
• Let the LLM decide how to interpret and act on that data
• Use documented VSCode APIs (Comment Controller, diff command, tree views)

GitHub officially supports MCP tools in Copilot. Their own documentation describes returning structured data from tools. We follow that pattern exactly.

Reference: GitHub Copilot MCP Integration

---

Implementation

Phase 1: Core Comment System

• Define HiveComment schema in @agent-hive/core
• Implement CommentService for CRUD operations
• Add comment storage to .hive/ structure
• Create hiveCommentAdd, hiveCommentResolve tools

Phase 2: Reactive Tool Checks

• Add change detection to existing tools
• Return blockers and newComments in tool responses
• Implement blocker resolution flow

Phase 3: Diff Review

• Integrate parse-diff for structured diff access
• Create VSCode tree view for file navigation
• Wire up Comment Controller for line-level comments
• Use native vscode.diff command

Phase 4: UI Polish

• Diff approval workflow
• Comment notification badges
• Resolution confirmation dialogs

---

Package Structure

We don't need 7 packages. Start with what exists:

@agent-hive/core      # Business logic, types, services (already hive-core)
vscode-hive           # VSCode extension (already exists)
opencode-hive         # OpenCode plugin (already exists)

Additional packages only if truly needed later.

---

Philosophy Alignment

Pillar	How This Extends It
Context Persists	Comments persist across sessions in .hive/
Plan → Approve → Execute	Additional optional gates, not replacements
Isolated Worktrees	Per-task diff review before merge
Sequential Tasks	Blockers can pause/resume execution
Tests Define Done	Diff review as optional verification layer

Everything is additive. The existing workflow keeps working unchanged.

---

Open Questions

1. Comment storage format: JSON files (proposed) vs inline YAML frontmatter in markdown?

2. Blocker UX: Should blocked tasks show a specific icon in the tree view? How do we surface blockers prominently?

3. Comment threading depth: Support unlimited nesting or cap at 2-3 levels?

4. Diff caching: Cache parsed diffs or regenerate on demand? Worktrees can have many files.

---

What We're Not Building

• JetBrains adapter (no current users asking for it)
• Cursor-specific integration (uses VSCode base, may work automatically)
• CLI diff viewer (terminal-based review is out of scope)
• Real-time collaboration (comments are async, not live)
• Integration with GitHub PR reviews (this is about pre-merge review)

---

Dependencies

Package	Purpose
simple-git	Git operations (already in use)
parse-diff	Structured diff parsing
zod	Schema validation

No new heavy dependencies.

---

Related

• Issue #4: Built-in Editor for Plan Review
• Agent Hive Philosophy

[tctinh]

Hi @rbcb-bedag, thanks for your great works.
I'm currently work on the feature proposal #4 while improve hive philosophy by enable more "human in the loop" into actual task execution, I think this design is good and aligning what hive trying to do,
I'm working on this, but the feature may not look exactly same like your proposal, your idea will be implement align more with the Hive style workflow

[tctinh]

About another IDE integration I'm thinking of a stdio MCP toolset + skills because we cannot inject internal tools into those software beside Claude Code.

[rbcb-dev]

Sound great !

fyi:
i've created for vscode copilot multiple custom agents with the idea of copilot orchestra:
https://github.com/ShepAlderson/copilot-orchestra

The idea is, to have one main chat (eg. the Conductor or your Hive), which delegates tasks to sub-agents.
The benefit is, that sub-agents in copilot have a new fresh context. they do their tasks (prompt refinement, research, implementation, review etc.) and then write context.
The Main Chat/Conductor then only sees the results and don't get bloated with all the intermediate context like errors, online research etc.

The Condcutor itself has onle the agent tool and all the hive tools, so he is really only for making desicions to which sub agent tasks are getting delegated.

And regarding your "human in the loop": i made it so, that at the beginning the user gives feedback to the plan.md via comments and the prompter agent then refines on this feedback.

Current limitation: Questions by the Planer are currently written as plan.md and i'm then creating comments on them.
After Prompt Refinement is done, then the plan.md gots replaced with the actual plan. so currently i'm mis-using the plan.md to be able to create comments.

It would be great to have additional hiveTools like:

• hiveQuestionCreate() - Create structured question
• hiveRefinementWrite() - Separate file with comment support
• hiveCommentRead() - Read comments on any file

Just as an idea.

Here is just an overview of the phases im currently using. I have 6 custom agents markdowns with all of them having seperate responsibilities and tools (or they DON'T have tools, so for example a review agent cannot start doing implementation).

If you want, i can send them somehow (but currently a little bit specific for our repo which uses Nx for mono repo)

┌──────────────────────────────────────────────────────────────────────────┐
│                     PHASE 0: PROMPT REFINEMENT                            │
│                     (User interaction: HIGH)                              │
│                                                                          │
│  User Request → Conductor → Prompter → plan.md (questions) → User        │
│                                 ↑                               │        │
│                                 └───────────────────────────────┘        │
│                              (iterate until ready)                        │
└──────────────────────────────────────────────────────────────────────────┘
                                    │
                                    ▼
┌──────────────────────────────────────────────────────────────────────────┐
│                     PHASE 1: PLAN CREATION                                │
│                     (User interaction: APPROVAL)                          │
│                                                                          │
│  Conductor → Planner → plan.md (tasks) → User Approval                    │
└──────────────────────────────────────────────────────────────────────────┘
                                    │
                          User Approves
                                    ▼
┌──────────────────────────────────────────────────────────────────────────┐
│                     PHASE 2: EXECUTION                                    │
│                     (User interaction: NONE - autonomous)                 │
│                                                                          │
│  FOR EACH TASK:                                                          │
│    Conductor → execStart → Implementation → (Review) → merge             │
│                                                                          │
│  Progress: "Task N/M complete"                                            │
└──────────────────────────────────────────────────────────────────────────┘
                                    │
                                    ▼
┌──────────────────────────────────────────────────────────────────────────┐
│                     PHASE 3: COMPLETION                                   │
│                                                                          │
│  Conductor → featureComplete → Final Report                               │
└──────────────────────────────────────────────────────────────────────────┘

[rbcb-dev]

P.S.
for mcp stdio could be maybe mcpc be used: https://github.com/apify/mcp-cli
this could be taken as a npm package dependency and then create two new VSCode LLM Tool.
One for executing a mcp which is defined in the mcp.json or an other custom config etc.
and one for listing all available mcp's.

Why additional VSCode Language Tool ?
then Copilot doesn't need to paste its cli command into terminal and parse the output, but can do it directly via this "proxy" language tool, which saves time, because (at least for me) sometimes pasting into terminal and parsing from it copilot takes a long time.
And then in the agent.md files it can be explicitly referenced as #tool:thenewtool/execute xyz which copilot better follows instead of solely a text in a markdown "do execute this command when you want to do xy"

[rbcb-dev]

Hey @tctinh

i see you are working on branch hive-mission-control on features like markdown preview etc. and are implementing similiar to seamless agent additional tools to allow user to be asked for feedback.

For Github Copilot this against there terms of service and people got even banned their account because when the LLM Agent can wait for user input you can extend the instructions and the llm session almost indefenitly by always giving extra instructions and can prompt the whole day with only 1 premium request. People reported in seamless agent, tasksync and other extensions on reddit that they got banned for "programmatically extending the session".

so ideally it would be great to have by default the waiting for the user to be disabled, so that LLM Agent can "post" all of this comment/questions. then session ends => users answers them and says "continue" to again start the session.

and for the users who are brave enough, they could maybe via some user-level settings.json etc. configure the extension that it should wait for the user.

Or even better : create two seperate tools for each such user interaction
one is only posting the questions.
the other is "reactive" and waits for user input via vscode extension etc.

just to have the possibility to not violate the TOS of copilot and getting banned.

[tctinh]

Hi @rbcb-bedag I'm currently on hold of gh copilot feature at the moment in favor of Opencode which I found would work better by giving us more control into the internal tooling system, If you haven't aware yet the GH Copilot final make Opencode integration official, because of that I'm currently all effort to make the Opencode main workflow for this plugin in favor of more robust subagent system and leverage built in Opencode tool like "question". Currently bringing the review and comment workflow right into the TUI as well. If you interested, try Opencode it's very good (mostly because model now train to work on SWE Terminal Bench where they can freely use terminal command to achieve goal)

[tctinh]

Also by using Opencode we can use great plugin like
https://github.com/alvinunreal/oh-my-opencode-slim
https://github.com/Opencode-DCP/opencode-dynamic-context-pruning
currently on planning tightly integration with these plugin as a development suite along with Hive

[rbcb-dev]

Hey @tctinh
I was now able to use my github copilot subscription with opencode + hive agent + dcp and it goes really well !

How is your flow AFTER the changes/commits get automatically merged from the worktrees/tasks to the branch, from where the session started ?
I'm still missing a way to let the LLM know, what changes were made wrong etc.
Would it be able to pick up this Issue here again to have some sort of comment feature on the plan and the commits like how it is done on Github with the Pull-Requests (but just locally with meta-data from the commits from each task/worktree etc.) ?

This is for me the last missing piece to have a full "ui" workflow without manually needing to do git diff compares etc. in vscode.

[tctinh]

Hey @tctinh I was now able to use my github copilot subscription with opencode + hive agent + dcp and it goes really well !

How is your flow AFTER the changes/commits get automatically merged from the worktrees/tasks to the branch, from where the session started ? I'm still missing a way to let the LLM know, what changes were made wrong etc. Would it be able to pick up this Issue here again to have some sort of comment feature on the plan and the commits like how it is done on Github with the Pull-Requests (but just locally with meta-data from the commits from each task/worktree etc.) ?

This is for me the last missing piece to have a full "ui" workflow without manually needing to do git diff compares etc. in vscode.

I'm currently using Gitlens to review what agent do in their worktrees, after agent done and it merge into the current branch from worktrees, it will create a commit of that task like this, you can check it via Gitlens, it already very well built for this matter so Hive doesn't come with the built in worktrees/commit checker. After that when you merge to main/dev branch you should squash to remove all the hive noise

[rbcb-dev]

thank you for your explanation !
need to test it out.

the idea of the diff integration would be, that it is more coupled to the hive agent flow => specific json documents can be created with exact line numbers where a comment was added by the user. then an additional hive tool could get this comments/feedbacks and exactly knows which function/variable is meant in which file in which folder and so on...

so it is also about having better context for the LLM without the need of always having to reference the files etc. in the chat terminal.

[rbcb-dev]

Hey @tctinh
Im currently working on the feature myself from time to time.
In this branch you can see some storybook image snapshots for impressions (or can start the storybook dev server for interactive way of looking into them). Pay attention that not all images are correctly rendered, because components that have a scroll feature are cut off.
https://github.com/rbcb-dev/agent-hive/tree/feature/ui-review/packages/vscode-hive/image_snapshots

I wanted to ask: can i make a suggestions to migrating the project setup to Nx https://nx.dev/ ?
This would be the perfect case for a monorepo with different modules/libraries (eg. core, vscode, opencode and now the ui components etc.) with correct order of executions and caching of the tasks.
There are also first party nx plugins for storybook, vitest, react.

Until now, i only had projects/experience with setups of nx + pnpm, but i guess it will also work with bun.
If you agree, i would like to make a new branch for migrating to Nx and creating PR and then afterwards would continue with my feature on this basis.

P.S.
@tctinh , @imarshallwidjaja because you are for now the contributors on this repo: could we maybe enable the "Discussion" feature in this Github repository, so that we don't need to create new issues for such topics ?

thx

[tctinh]

Hey @tctinh Im currently working on the feature myself from time to time. In this branch you can see some storybook image snapshots for impressions (or can start the storybook dev server for interactive way of looking into them). Pay attention that not all images are correctly rendered, because components that have a scroll feature are cut off. https://github.com/rbcb-dev/agent-hive/tree/feature/ui-review/packages/vscode-hive/image_snapshots

I wanted to ask: can i make a suggestions to migrating the project setup to Nx https://nx.dev/ ? This would be the perfect case for a monorepo with different modules/libraries (eg. core, vscode, opencode and now the ui components etc.) with correct order of executions and caching of the tasks. There are also first party nx plugins for storybook, vitest, react.

Until now, i only had projects/experience with setups of nx + pnpm, but i guess it will also work with bun. If you agree, i would like to make a new branch for migrating to Nx and creating PR and then afterwards would continue with my feature on this basis.

P.S. @tctinh , @imarshallwidjaja because you are for now the contributors on this repo: could we maybe enable the "Discussion" feature in this Github repository, so that we don't need to create new issues for such topics ?

thx

Hi @rbcb-dev, thanks for your work,
About the tool chain I think we should stick with Bun (pnpm also work as well) for now, as Nx it's entire platform not just a tool, which break our rule in simplicity also it require extra setup, another reason to stick with Bun, pnpm because it work with everyone, they just need install Bun or pnpm and then can start development right away while Nx would require extra setup and it's not totally free as well, but if you wanted to use Nx you can use that on your local development environment, just don't push Nx pipeline into main everything fine.
On the storybook matter, it's great idea which add more transparent and human in the loop more into our hive workflow, just make sure that align with our https://github.com/tctinh/agent-hive/blob/main/PHILOSOPHY.md, and this storybook feature should serve add another UI/UX layer for us to interact with Hive it shouldn't affect opencode agent toolset
Also I just enable the Discussion too|

P/S: If you need any help from me, I'll happy to help as well