joshua iokua albano
Clide
CLI/IDE as a
Research Workspace
CLI/IDE as a
Research Workspace
CLI/IDE as a
Research Workspace
Download
Coming Soon
Release Notes
v0.1.8
About
The y of it all
For better or for worse I want my text editors to behave more like IDEs and my research and writing process to inherit CLI agent conventions—technical founder Stockholm syndrome or genuine design superiority, I’ll leave it up to you to decide. Regardless, I do think there are features, conventions, and practices, that could meaningfully improve researcher experience and workflow.
Notably this is something between a product, a passion project, and a means for me to explore different ideas around what I'm beginning to call researcher experience (RX)—as well as build something for friends much smarter than myself but just as overwhelmed with the hydra hydrant of information they must make sense of.
things i wanted
Version Control on Lines of Inquiry
Shoutout to my friend who said in a car ride, “I wish I could go back to an older state of my research if I ran into a dead end.” Despite my own terrible git hygiene, its approach to version control is more meaningful than the flat save states most document editors give you, and it could feasibly do exactly what my friend wanted: capture his research as it evolves—as the draft and citations grow—and let him "checkout" an earlier state of the workspace when he needs to. But I don't think spinning up a GitHub repo for your research is the right move. For one, line-by-line diffs are barely more meaningful than autosave, and arguably just add bloat. For another, if I, and I’m not alone, don’t keep my commits tidy and version history segmented, why should we expect others outside of software development to do the same. So you need something specific to the general research and git-like; something lighter than a commit, but with more meaningful provenance than a pile of timestamped autosaves. I think you can get there by focusing on a research’s inquiry. That is, the initial question or impulse (e.g. “Why is X?”, “What causes Y?”, etc.) that naturally evolves as the research it guides, and which guides it reflexively, likewise evolves. Giving my friend the ability to pursue lines of inquiry, snapshotting as he goes, changing his inquiry as needed, and allowing him to go back to an earlier state when he hits a dead end, all while creating a record of why some exploration ultimately didn’t pan out. Understanding what sources, comments, and citations undergirded each inquiry or snapshot state of his research at each change.
Version Control on Lines of Inquiry
Shoutout to my friend who said in a car ride, “I wish I could go back to an older state of my research if I ran into a dead end.” Despite my own terrible git hygiene, its approach to version control is more meaningful than the flat save states most document editors give you, and it could feasibly do exactly what my friend wanted: capture his research as it evolves—as the draft and citations grow—and let him "checkout" an earlier state of the workspace when he needs to. But I don't think spinning up a GitHub repo for your research is the right move. For one, line-by-line diffs are barely more meaningful than autosave, and arguably just add bloat. For another, if I, and I’m not alone, don’t keep my commits tidy and version history segmented, why should we expect others outside of software development to do the same. So you need something specific to the general research and git-like; something lighter than a commit, but with more meaningful provenance than a pile of timestamped autosaves. I think you can get there by focusing on a research’s inquiry. That is, the initial question or impulse (e.g. “Why is X?”, “What causes Y?”, etc.) that naturally evolves as the research it guides, and which guides it reflexively, likewise evolves. Giving my friend the ability to pursue lines of inquiry, snapshotting as he goes, changing his inquiry as needed, and allowing him to go back to an earlier state when he hits a dead end, all while creating a record of why some exploration ultimately didn’t pan out. Understanding what sources, comments, and citations undergirded each inquiry or snapshot state of his research at each change.
Version Control on Lines of Inquiry
Shoutout to my friend who said in a car ride, “I wish I could go back to an older state of my research if I ran into a dead end.” Despite my own terrible git hygiene, its approach to version control is more meaningful than the flat save states most document editors give you, and it could feasibly do exactly what my friend wanted: capture his research as it evolves—as the draft and citations grow—and let him "checkout" an earlier state of the workspace when he needs to. But I don't think spinning up a GitHub repo for your research is the right move. For one, line-by-line diffs are barely more meaningful than autosave, and arguably just add bloat. For another, if I, and I’m not alone, don’t keep my commits tidy and version history segmented, why should we expect others outside of software development to do the same. So you need something specific to the general research and git-like; something lighter than a commit, but with more meaningful provenance than a pile of timestamped autosaves. I think you can get there by focusing on a research’s inquiry. That is, the initial question or impulse (e.g. “Why is X?”, “What causes Y?”, etc.) that naturally evolves as the research it guides, and which guides it reflexively, likewise evolves. Giving my friend the ability to pursue lines of inquiry, snapshotting as he goes, changing his inquiry as needed, and allowing him to go back to an earlier state when he hits a dead end, all while creating a record of why some exploration ultimately didn’t pan out. Understanding what sources, comments, and citations undergirded each inquiry or snapshot state of his research at each change.
Malleable Knowledge Graph
For a research workspace’s state to be worth saving, it has to be more than the document at time of save, or in our case checkpoint and or inquiry change. Otherwise our previous approach just becomes artifact bloat. What we actually want to capture, as I hinted, is the research's knowledge graph: the comments/highlights made, the sources relied on, the unresolved open questions, etc. There’s an unfortunate graveyard of argument-mapping tools that tried to get writers and researchers to structure or tag their work as they worked; all failing because maintaining the map/graph just became extra work. So what we need is the lowest-effort way to build a knowledge graph that, ideally, already slots into common writing/researching workflows. Even this might be too large a lift, but I think a good first step is combining the comment/highlight/annotation features common to PDF readers and collaborative text editors with the entity-linking you see in tools like Claude Code or Cursor (i.e. “@SomeFile.txt”). Adding a highlight to a source you’re reviewing and commenting “Supports @MyResearch.md” establishes the edge between the source and document node, providing, at minimum, a more metadata-rich connection than a simple citation. This graph, instead of being actively maintained as a secondary research task, is “compiled” from usage and the structure naturally provided by wanting to quickly connect what you might be reading with what you’re working on. The result is a JIT knowledge graph, tied to the workspace state at each snapshot or inquiry change and walkable by an agent.
Malleable Knowledge Graph
For a research workspace’s state to be worth saving, it has to be more than the document at time of save, or in our case checkpoint and or inquiry change. Otherwise our previous approach just becomes artifact bloat. What we actually want to capture, as I hinted, is the research's knowledge graph: the comments/highlights made, the sources relied on, the unresolved open questions, etc. There’s an unfortunate graveyard of argument-mapping tools that tried to get writers and researchers to structure or tag their work as they worked; all failing because maintaining the map/graph just became extra work. So what we need is the lowest-effort way to build a knowledge graph that, ideally, already slots into common writing/researching workflows. Even this might be too large a lift, but I think a good first step is combining the comment/highlight/annotation features common to PDF readers and collaborative text editors with the entity-linking you see in tools like Claude Code or Cursor (i.e. “@SomeFile.txt”). Adding a highlight to a source you’re reviewing and commenting “Supports @MyResearch.md” establishes the edge between the source and document node, providing, at minimum, a more metadata-rich connection than a simple citation. This graph, instead of being actively maintained as a secondary research task, is “compiled” from usage and the structure naturally provided by wanting to quickly connect what you might be reading with what you’re working on. The result is a JIT knowledge graph, tied to the workspace state at each snapshot or inquiry change and walkable by an agent.
Malleable Knowledge Graph
For a research workspace’s state to be worth saving, it has to be more than the document at time of save, or in our case checkpoint and or inquiry change. Otherwise our previous approach just becomes artifact bloat. What we actually want to capture, as I hinted, is the research's knowledge graph: the comments/highlights made, the sources relied on, the unresolved open questions, etc. There’s an unfortunate graveyard of argument-mapping tools that tried to get writers and researchers to structure or tag their work as they worked; all failing because maintaining the map/graph just became extra work. So what we need is the lowest-effort way to build a knowledge graph that, ideally, already slots into common writing/researching workflows. Even this might be too large a lift, but I think a good first step is combining the comment/highlight/annotation features common to PDF readers and collaborative text editors with the entity-linking you see in tools like Claude Code or Cursor (i.e. “@SomeFile.txt”). Adding a highlight to a source you’re reviewing and commenting “Supports @MyResearch.md” establishes the edge between the source and document node, providing, at minimum, a more metadata-rich connection than a simple citation. This graph, instead of being actively maintained as a secondary research task, is “compiled” from usage and the structure naturally provided by wanting to quickly connect what you might be reading with what you’re working on. The result is a JIT knowledge graph, tied to the workspace state at each snapshot or inquiry change and walkable by an agent.
Inquiry as Baseline
For a research workspace’s state to be worth saving, it has to be more than the document at time of save, or in our case checkpoint and or inquiry change. Otherwise our previous approach just becomes artifact bloat. What we actually want to capture, as I hinted, is the research's knowledge graph: the comments/highlights made, the sources relied on, the unresolved open questions, etc. There’s an unfortunate graveyard of argument-mapping tools that tried to get writers and researchers to structure or tag their work as they worked; all failing because maintaining the map/graph just became extra work. So what we need is the lowest-effort way to build a knowledge graph that, ideally, already slots into common writing/researching workflows. Even this might be too large a lift, but I think a good first step is combining the comment/highlight/annotation features common to PDF readers and collaborative text editors with the entity-linking you see in tools like Claude Code or Cursor (i.e. “@SomeFile.txt”). Adding a highlight to a source you’re reviewing and commenting “Supports @MyResearch.md” establishes the edge between the source and document node, providing, at minimum, a more metadata-rich connection than a simple citation. This graph, instead of being actively maintained as a secondary research task, is “compiled” from usage and the structure naturally provided by wanting to quickly connect what you might be reading with what you’re working on. The result is a JIT knowledge graph, tied to the workspace state at each snapshot or inquiry change and walkable by an agent.
Inquiry as Baseline
For a research workspace’s state to be worth saving, it has to be more than the document at time of save, or in our case checkpoint and or inquiry change. Otherwise our previous approach just becomes artifact bloat. What we actually want to capture, as I hinted, is the research's knowledge graph: the comments/highlights made, the sources relied on, the unresolved open questions, etc. There’s an unfortunate graveyard of argument-mapping tools that tried to get writers and researchers to structure or tag their work as they worked; all failing because maintaining the map/graph just became extra work. So what we need is the lowest-effort way to build a knowledge graph that, ideally, already slots into common writing/researching workflows. Even this might be too large a lift, but I think a good first step is combining the comment/highlight/annotation features common to PDF readers and collaborative text editors with the entity-linking you see in tools like Claude Code or Cursor (i.e. “@SomeFile.txt”). Adding a highlight to a source you’re reviewing and commenting “Supports @MyResearch.md” establishes the edge between the source and document node, providing, at minimum, a more metadata-rich connection than a simple citation. This graph, instead of being actively maintained as a secondary research task, is “compiled” from usage and the structure naturally provided by wanting to quickly connect what you might be reading with what you’re working on. The result is a JIT knowledge graph, tied to the workspace state at each snapshot or inquiry change and walkable by an agent.
Inquiry as Baseline
For a research workspace’s state to be worth saving, it has to be more than the document at time of save, or in our case checkpoint and or inquiry change. Otherwise our previous approach just becomes artifact bloat. What we actually want to capture, as I hinted, is the research's knowledge graph: the comments/highlights made, the sources relied on, the unresolved open questions, etc. There’s an unfortunate graveyard of argument-mapping tools that tried to get writers and researchers to structure or tag their work as they worked; all failing because maintaining the map/graph just became extra work. So what we need is the lowest-effort way to build a knowledge graph that, ideally, already slots into common writing/researching workflows. Even this might be too large a lift, but I think a good first step is combining the comment/highlight/annotation features common to PDF readers and collaborative text editors with the entity-linking you see in tools like Claude Code or Cursor (i.e. “@SomeFile.txt”). Adding a highlight to a source you’re reviewing and commenting “Supports @MyResearch.md” establishes the edge between the source and document node, providing, at minimum, a more metadata-rich connection than a simple citation. This graph, instead of being actively maintained as a secondary research task, is “compiled” from usage and the structure naturally provided by wanting to quickly connect what you might be reading with what you’re working on. The result is a JIT knowledge graph, tied to the workspace state at each snapshot or inquiry change and walkable by an agent.
Agent Workspace Legibility
Half the joy I've had in building this is in taking the best agent practices I know from working with Claude Code and Codex in Cursor (e.g. directory CONTEXT.md files, skills, MCPs, etc.) and seeing how applicable these general approaches are in a much simpler, though less walkable, environment. If agents can already reliably walk code then I think exploring how we can meet them halfway is worthwhile. Part of what makes that feasible is the plug-and-play move these tools rely on. MCP works just as well pointed at a research workspace. You don't write a bespoke integration for each tool. You speak the protocol once, and anything that also speaks it can read and write the workspace. So I'm not trying to out-build the resources and services that already do their portion of research well (e.g. source citation, claim verifiers, etc.). I just want to give what they produce a workable destination instead of leaving it stranded in a chat window. Concretely, that means Clide is itself an MCP server. An agent, or one of those research tools, connects to it the same way it'd connect to anything else, and what it finds lands in the workspace as a Source rather than a message you have to copy back out by hand.
Agent Workspace Legibility
Half the joy I've had in building this is in taking the best agent practices I know from working with Claude Code and Codex in Cursor (e.g. directory CONTEXT.md files, skills, MCPs, etc.) and seeing how applicable these general approaches are in a much simpler, though less walkable, environment. If agents can already reliably walk code then I think exploring how we can meet them halfway is worthwhile. Part of what makes that feasible is the plug-and-play move these tools rely on. MCP works just as well pointed at a research workspace. You don't write a bespoke integration for each tool. You speak the protocol once, and anything that also speaks it can read and write the workspace. So I'm not trying to out-build the resources and services that already do their portion of research well (e.g. source citation, claim verifiers, etc.). I just want to give what they produce a workable destination instead of leaving it stranded in a chat window. Concretely, that means Clide is itself an MCP server. An agent, or one of those research tools, connects to it the same way it'd connect to anything else, and what it finds lands in the workspace as a Source rather than a message you have to copy back out by hand.
Agent Workspace Legibility
Half the joy I've had in building this is in taking the best agent practices I know from working with Claude Code and Codex in Cursor (e.g. directory CONTEXT.md files, skills, MCPs, etc.) and seeing how applicable these general approaches are in a much simpler, though less walkable, environment. If agents can already reliably walk code then I think exploring how we can meet them halfway is worthwhile. Part of what makes that feasible is the plug-and-play move these tools rely on. MCP works just as well pointed at a research workspace. You don't write a bespoke integration for each tool. You speak the protocol once, and anything that also speaks it can read and write the workspace. So I'm not trying to out-build the resources and services that already do their portion of research well (e.g. source citation, claim verifiers, etc.). I just want to give what they produce a workable destination instead of leaving it stranded in a chat window. Concretely, that means Clide is itself an MCP server. An agent, or one of those research tools, connects to it the same way it'd connect to anything else, and what it finds lands in the workspace as a Source rather than a message you have to copy back out by hand.
