[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-82307":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":10,"language":11,"languages":10,"totalLinesOfCode":10,"stars":12,"forks":13,"watchers":14,"openIssues":15,"contributorsCount":16,"subscribersCount":16,"size":16,"stars1d":16,"stars7d":16,"stars30d":17,"stars90d":16,"forks30d":16,"starsTrendScore":16,"compositeScore":18,"rankGlobal":10,"rankLanguage":10,"license":19,"archived":20,"fork":20,"defaultBranch":21,"hasWiki":20,"hasPages":20,"topics":22,"createdAt":10,"pushedAt":10,"updatedAt":23,"readmeContent":24,"aiSummary":25,"trendingCount":16,"starSnapshotCount":16,"syncStatus":17,"lastSyncTime":26,"discoverSource":27},82307,"torque","runtorque\u002Ftorque","runtorque","Torque is a single-user product development powerhouse","https:\u002F\u002Fruntorque.com",null,"Python",31,3,29,156,0,2,1.81,"Other",false,"main",[],"2026-06-12 02:04:25","# Torque\n\n[![License](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002Flicense-MIT%20%28except%20ee%2F%29-blue.svg)](LICENSE)\n[![Version](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002Fversion-1.1.0-green.svg)](VERSION)\n[![Docs](https:\u002F\u002Fimg.shields.io\u002Fbadge\u002Fdocs-mkdocs-blue.svg)](docs\u002Findex.md)\n\nTorque is a local agent-orchestration workspace built on top of **Claude\nCode** and **Codex**. Chat with an orchestrator agent, run coding agents in\nisolated git worktrees, dispatch work from a kanban board, and watch tasks\nship — from a native desktop window or your browser. Because Torque is a\nharness over the CLIs you already use, all the work runs through your\nexisting Claude and Codex subscription plans.\n\n![Torque workspace showing the agent grid, the chat with the orchestrator, the task board, and a live agent session.](docs\u002Fimages\u002Foverview.png)\n\n## Why Torque\n\nCoding agents are powerful but messy in practice. Each one wants its own\nsession, its own branch, its own context window, and its own terminal history.\nSpinning up three at once can quickly turn into three terminals, three\nworktrees, three half-remembered prompts, and a lot of \"where was I?\" friction.\n\nTorque is a harness on top of **Claude Code** and **Codex**: it drives the\nCLIs you already run, so every agent uses your existing subscription plans — no\nextra API keys or per-token billing. I built it because the AI companies would\nrather lock me into *their* harnesses and *their* idea of how I should work.\nTorque is how I found to get the full value out of the subscriptions I already\npay for, on my own terms, without conforming to a vendor's prescribed workflow.\n\n## How it works\n\nTorque is a hierarchy of agents, each minding its own role. **Workers** write\nthe code. **Engineers** sit above them: they orchestrate tasks across their\nworkers and merge the results, serializing changes so conflicts never happen in\nthe first place. That orchestration keeps engineers busy and their context\nprecious — too busy to also plan at a high level. So that job falls to the\n**architect**, which does the high-level planning and is usually the role you\nwant to talk to. It interfaces with the engineers and shields their context\nfrom human interruption; because it is typically less loaded than the\nengineers, it is the natural entrypoint to the whole system — though you can\nstill drop down and talk to an engineer directly when you need to.\n\nYou drive everything from the **chat** with the architect. This matters because\nthe underlying Claude Code or Codex session is busy almost constantly —\nfielding messages from other agents and digests from the system — so a message\ntyped straight at it would just get buried in its context. Instead, the chat\nworks both ways: your messages go in through the harness — the normal Claude\nCode or Codex input channel — while the architect replies back through an MCP\ntool call, and it keeps working in between. You read its replies and decide what\nto do next on your own time, without ever stalling the agent or polluting its\nworking context. Meanwhile the **kanban board** shows\nwhat every agent is doing at all times — every task, who owns it, and where it\nsits in the pipeline.\n\n## What you get:\n\n- A **chat-first workspace** where you talk to an **architect** that plans the\n  work and runs the engineers and workers for you — backed by Claude Code and\n  Codex on your own subscription plans.\n- **Groups** that act like separate projects — each one fully isolated from the\n  others — so you can run Torque across all your projects from a single native\n  desktop window or browser tab.\n- **Automatic git worktrees** per agent, with checkpointing, diff tracking,\n  and engineer-driven merges back to your base branch.\n- A built-in **kanban board** with lanes, drag-and-drop, derived subtasks,\n  and human-review gates.\n- **One-click task dispatch**: pick a task, pick an action, and Torque spawns\n  an agent in a fresh worktree with the rendered prompt already sent.\n- An optional embedded **engineer agent** that orchestrates dispatch, review,\n  and merge across an entire group without you babysitting each worker.\n- Reusable action templates with Jinja-rendered prompts and pipeline\n  transitions.\n- A `torque` CLI for scripting from the command line.\n\n## Core Ideas\n\n### Torque builds Torque\n\nTorque is built with Torque. Nearly all of its code is written by agents\ndispatched from the board and merged through the engineer — the same loop the\nproduct exposes to you. The agents produce code so fast that, as a deliberate\nexperiment in trusting the orchestration loop, **none of the code Torque has\nwritten for itself has been manually inspected line-by-line.** Review, testing,\nand merge gates are themselves run by agents. It is an honest, sometimes\nuncomfortable, demonstration of what the harness can do — and a live stress\ntest of the guardrails it ships with.\n\n### Agents only see what they're allowed to\n\nAn agent can only perform the actions its role allows — and it can only *see*\nthose actions in the first place. There is no hidden menu of capabilities an\nagent could reach for and be denied; anything outside its scope simply never\nappears, and a call to a tool it isn't scoped for is refused at the server, not\nmerely hidden in the UI. Two pieces of plumbing enforce and observe that:\n\n**Scoped MCP tools via env-var injection.** When Torque spawns an agent it\nwrites a per-agent `.mcp.json` (or `.codex\u002Fconfig.toml`) with the\n`TORQUE_CELL_ID` env var baked in. Every MCP request the agent makes carries\nthat cell id as an `X-Torque-Cell-Id` header, and the daemon uses it to\n**filter the tool list before it leaves the server** — and to scope which of\nthose tools the agent may actually call. A worker only sees the `torque_*`\nreporting tools. An engineer additionally sees `engineer_*` tools scoped to its\nown group — it physically cannot enumerate another group's journal. An architect\ngets `architect_*` tools further scoped per actor. There is no override flag;\nscope is the contract. → [MCP scoping](docs\u002Fteam\u002Fmcp-scoping.md)\n\n**Hooks for live work tracking.** For Claude Code and Codex workers, Torque\ninstalls `SessionStart`, `PreToolUse`, `PostToolUse`, and `Stop` hooks that\nPOST to a local `\u002Fevents` endpoint. Every tool call, every progress report,\nevery session boundary streams back into the daemon in real time. That feed\ndrives the activity badges on agent cells, the engineer's event digest, the\nworklog, and the auto-checkpoint triggers on the worktree. You see what each\nagent is doing without attaching to its terminal.\n\n### Actions, transitions, and pipelines\n\nYou don't have to micromanage how a task flows — you predefine it. Each task is\ndispatched with an **action**, and an action declares the **transitions** it is\nallowed to take. Together those transitions form a directed acyclic graph: a\ntask can go out for implementation, move to review, bounce back to\nimplementation for fixes, or branch off to a fix step — all on its own. Because\nthe action already encodes the legal moves, a worker can derive the next step\nautonomously, without the engineer stepping in to route it.\n\nTransitions also decide *who* does the next step: some hand the work to a fresh\nagent (a clean reviewer that didn't write the code), while others keep it on the\nsame agent that already has the context. And every action's prompt is a\n**template** — it renders against the `torque` context namespace, so the same\naction produces a different prompt depending on the agent's role, its worktree\nstate, and the task at hand. Define the graph once; Torque drives tasks through\nit. → [Actions](docs\u002Ftasks\u002Factions.md), [Pipelines](docs\u002Ftasks\u002Fpipelines.md)\n\n| The transition graph | The action's prompt template |\n|:---:|:---:|\n| ![A DAG view: research → implement → review, with review bouncing back to implement for fixes.](docs\u002Fimages\u002Factions-dag.png) | ![The action editor with a Jinja prompt template rendered against the torque context.](docs\u002Fimages\u002Factions-editor.png) |\n\n### The board is an objective view of the work\n\nThe kanban board is where work lives, and it can sync with external task\nproviders — today that means **GitHub**, with others like **Linear** planned.\nMost tasks are meant to be created by talking to the architect, which fleshes\nthem out before assigning and dispatching. You can also add a card directly on\nthe board, but a raw card is just a title and a note — hand it to the architect\nso it can fill in the details, attach the right action, assign an engineer, and\ndispatch the work. → [The board](docs\u002Ftasks\u002Fboard.md)\n\n![The Torque board: a Backlog of active and queued cards, In Progress work in flight, and a Done lane of completed tasks.](docs\u002Fimages\u002Fboard-full.png)\n\n### Events, context, and communication\n\nAgents don't work in isolation — they talk to each other. Workers report to\ntheir engineer, engineers message the architect, architects can message other\narchitects, and the architect messages you. All of that crosstalk is visible: a\ndedicated panel renders the live conversation between agents, so you can watch\nthe orchestration happen instead of guessing at it. A separate panel surfaces\nevery **MCP tool call** an agent makes, so you can see exactly what each agent\nis doing — which tool, with which arguments — as it happens.\n\nUnderneath the chatter, agents keep a written record. Workers, engineers, and\nespecially the engineers and the architect **journal** their work as they go,\nbuilding a durable trail of what was done and why. They also carry a shared\n**context** they use to pass findings to one another and to remember what they\nhave learned — so a discovery made by one agent doesn't have to be rediscovered\nby the next, and long-running engineers and architects retain their bearings\nacross many tasks.\n\n| Agent messages & digests | Every MCP tool call | The work journal |\n|:---:|:---:|:---:|\n| ![The events inbox showing messages and queued digests between agents.](docs\u002Fimages\u002Fevents-inbox.png) | ![A separate panel listing each MCP tool call an agent makes.](docs\u002Fimages\u002Fevents-mcp.png) | ![An agent's journal: a durable, timestamped trail of what it did and why.](docs\u002Fimages\u002Fjournal.png) |\n\nThe payoff is that Torque tends to run smoother the longer you use it. As\njournals fill in and context accumulates, the agents get better at managing\ntheir own workflows, at coordinating with one another, and at solving problems\nthey have seen before. The system isn't static — it compounds, turning each\nsolved problem into a head start on the next one.\n\n## Quickstart\n\n### Native desktop app (recommended)\n\nThe desktop app gives you the full Torque workspace in a dedicated native\nwindow — no browser tab required — and it is the easiest way to get started.\n\n```bash\ngit clone git@github.com:runtorque\u002Ftorque.git\ncd torque\nmake deps\nmake tauri-dev\n```\n\n`make deps` creates or repairs Torque's owned runtime venv at\n`~\u002F.torque\u002Fruntime\u002Fvenv`. `make tauri-dev` builds and launches the native\ndesktop window on its own profile and port (defaults: `desktop` profile, port\n`18933`), so it does not collide with other standalone profiles.\n\n### Standalone browser mode\n\nFrom the cloned repo, after `make deploy` has been run once:\n\n```bash\nmake standalone\nmake open\n```\n\nStandalone mode launches the daemon and opens Torque in your default browser.\nIt is useful when you want a wider workspace or are running on a remote \u002F\nshared machine.\n\nFor more install variants and runtime modes, see\n[Getting Started](docs\u002Ffoundations\u002Fgetting-started.md) and\n[Operations](docs\u002Foperate\u002Foperations.md).\n\n## Documentation\n\n- [Getting Started](docs\u002Ffoundations\u002Fgetting-started.md) — install and create\n  your first group, agent, and terminal.\n- [Core concepts](docs\u002Ffoundations\u002Fcore-concepts.md) — vocabulary and mental\n  model.\n- [The team](docs\u002Fteam\u002Fteam-model.md) — Workers, Engineers, Architects, and how\n  MCP tools are scoped per role.\n- [Tasks and threads](docs\u002Ftasks\u002Fthreads.md) — derivation as the unit of\n  progress.\n- [Actions](docs\u002Ftasks\u002Factions.md), [Templates](docs\u002Ftasks\u002Ftemplates.md), and\n  [Pipelines](docs\u002Ftasks\u002Fpipelines.md) — reusable prompts that compose into\n  multi-step workflows.\n- [Workflow guide](docs\u002Foperate\u002Fworkflow-guide.md) — the day-to-day operating\n  loop.\n- [CLI reference](docs\u002Freference\u002Fcli.md) — `torque` command reference.\n- [Troubleshooting](docs\u002Freference\u002Ftroubleshooting.md) — symptom-first\n  recovery.\n\n[Full documentation map →](docs\u002Findex.md)\n\n## Contributing\n\nIssues and pull requests welcome. See [CONTRIBUTING.md](CONTRIBUTING.md) for\ndevelopment setup, test commands, and PR expectations. Bug reports and feature\nrequests use the templates in [`.github\u002F`](.github\u002F).\n\n## Status\n\nTorque is single-user, local-first, and currently macOS-focused. The native\ndesktop app and the standalone browser mode are the recommended entry points.\nLinux and Windows are follow-up targets: the daemon itself is portable, but\nthe desktop shell, packaging, and operator workflows are still macOS-first.\n\nThe project is on version `1.1.0`. See [Roadmap](docs\u002Froadmap.md) for what's\nnext.\n\n## Disclaimer\n\nTorque is under active development and has not been tested outside its author's\nown development environment. Expect rough edges and bugs. Treat it as\nexperimental and keep backups of anything you point it at.\n\n## License\n\nMIT for the community code, except for `ee\u002F` — see [LICENSE](LICENSE).\nThe `ee\u002F` directory is proprietary enterprise code under a separate\nall-rights-reserved license; see [ee\u002FLICENSE](ee\u002FLICENSE).\n","Torque是一款面向个人用户的开发工具，旨在通过集成Claude Code和Codex来提高编码效率。其核心功能包括通过聊天与编排代理进行交互、在隔离的Git工作树中运行编码代理、从看板分派任务，并在一个原生桌面窗口或浏览器中监控任务进度。技术上，Torque构建于用户已有的CLI之上，确保所有操作均使用现有的订阅计划执行，无需额外的API密钥或按令牌计费。适合希望在不改变现有工作流程的情况下，利用AI辅助提升软件开发生产力的开发者使用。","2026-06-11 04:08:21","CREATED_QUERY"]