TaskShell Bridges AI Coding Agents

TaskShell is a Show HN project from an independent product designer who built an agent-first productivity bridge for all your agents. It is a task layer meant to help AI coding agents keep track of todos across projects, after the author moved through Cursor, Codex, Claude Code, Kilo Code, and opencode in daily work. The problem is not code generation; it is remembering the right work item, status, and handoff when several agents touch the same repo. The useful takeaway for Cursor, Anysphere's AI code editor, is simple: keep agent task state outside the chat, then use cursor rules to make that state reviewable.

An agent-first task bridge is a shared work queue designed so coding agents can read, update, and hand off work without treating a chat transcript as the source of truth.

Understand the small thing TaskShell is trying to remove

TaskShell is interesting because it points at a boring failure mode. The author was not missing another model. They were missing continuity: which project has which open todo, what an agent already tried, and what should happen next.

That is why developers on Hacker News cared. A separate todo app can hold the work, but the agent usually cannot update it unless you manually paste context back and forth. A chat can hold the work too, but only until you switch tools, start a new session, or ask a different agent to continue.

The trick in TaskShell is framing the todo layer as something agents participate in, not just something humans maintain after the fact. That is a small shift, but it matches how AI coding work now feels: one human, several agents, many half-finished branches.

The trap is pretending this replaces an issue tracker. It does not need to. The useful shape is more modest: a short-lived task bridge for active agent work, with your real repo, tickets, and pull requests still acting as durable records.

Make the task state visible to Cursor

Cursor users should read TaskShell as a reminder to separate three kinds of context. Tasks say what is happening now. Cursor rules say how work must happen in this repo. Skills and subagents say what capability should be used for a kind of work.

For example, imagine a billing repo with a task called add retry handling for webhook delivery. The task can say the current branch, last test command, and next step. A nested rule can say never rewrite ledger rows, always add migration tests, and ask before touching payment provider fixtures.

This is where the Cursor subagents and skills topic becomes practical rather than abstract. A cursor subagent can be great at test repair or API migration, but it still needs a clean handoff note. A cursor skill can package a workflow, but it should not become the only place where live task state exists.

The trap is hiding status in the longest-lived chat. Chats are convenient while they are fresh and terrible once they become archaeology. If a future agent has to replay a conversation to learn whether tests passed, the workflow is already leaking.

Keep repo truth in rules, not in the task list

A task bridge should carry active state, not policy. Cursor rules and AGENTS.md-style repo instructions are better homes for architecture boundaries, command conventions, and safety checks because they live with the code and can be reviewed in the same branch.

A good split looks like this. TaskShell can hold finish auth callback cleanup and note that unit tests pass but the Playwright check is still failing. A local rule can hold do not change the session cookie format without updating mobile clients.

That split matters when you use Cursor custom agents or cursor custom subagents. The agent can pick up the work item, but the repository still gets to say what is allowed. The task is a handoff note. The rule is a boundary.

The trap is letting the external task layer become a second, informal spec. If the task says one thing and the repo rule says another, the agent should stop. The safest answer is usually boring: ask, update the durable rule if needed, then continue.

Try it safely on one repo slice

The right first test is not your busiest repo. Pick one active branch with a small, observable task: fix a flaky test, add one validation rule, or finish a simple UI state. As of August 2026, treat TaskShell as a project to evaluate, not as a replacement for your issue tracker or pull request process.

Use a Cursor rule like this to keep the experiment tidy:

---
description: Use when an agent reads or updates external task state for this repo
globs:
  - **/*
alwaysApply: false
---

When using an external task bridge:
- Read the task before editing files.
- Write back a short status after tests or before handoff.
- Do not store secrets, customer data, or credentials in task notes.
- Link the task to the branch or PR.
- If the task conflicts with AGENTS.md or a local rule, stop and ask.

Then run a small checklist:

• Create one non-sensitive task with a clear done condition.
• Use one branch and one agent session first.
• Keep credentials, customer data, and private logs out of the task note.
• Ask the agent to summarize what it changed before it updates task state.
• Review the diff in Cursor before accepting any status as true.
• Close or archive stale tasks quickly so future agents do not inherit ghosts.

If the product exposes deeper integrations later, such as an MCP server, make the first connection read-only. A task bridge earns write access only after you trust the shape of its records and the agent behavior around conflicts.

Know when TaskShell is a fit

TaskShell is most compelling when you regularly switch between agents or projects and lose track of the small work between commits. It is less compelling when one developer uses one agent on one repo and already keeps disciplined issues.

The limitation is simple. TaskShell can reduce bookkeeping, but it cannot decide what is correct for your codebase. Cursor review, tests, rules, and human judgment still carry that load.

Common questions

• Should I use TaskShell if Cursor already has rules?

  Yes, if your pain is task continuity rather than repo instruction. Cursor rules tell the agent how to behave in a codebase; TaskShell-style task state tells the agent what work is active. Keep rules durable and reviewable, and keep task notes short, temporary, and tied to branches or PRs.

• Is TaskShell the same as Cursor skills or subagents?

  No. Cursor skills package reusable workflows and reference material, while subagents or custom agents specialize the worker doing the job. TaskShell sits beside those pieces as a task bridge. A good setup can use all three: skill for method, subagent for role, task for handoff.

• What is the main risk with an agent-first task bridge?

  The main risk is stale or over-trusted task state. An agent may update a task after a failed command, miss a conflict, or carry forward an assumption from another tool. Keep the first experiment small, require a test command in the status, and review code changes in Cursor before believing the note.

• When is this overkill?

  It is overkill when your current workflow has no handoff problem. If one agent, one repo, and one issue tracker already give you clear next steps, adding another surface may slow you down. The signal to try it is repeated friction: lost todos, duplicated agent work, or unclear status after context switches.

Best ways to use this research

• Best for: developers who use multiple AI coding agents and want a cleaner handoff layer than chat history.
• Best first artifact: a small Cursor rule that says how external task state may be read, updated, and reviewed.
• Best comparison angle: TaskShell vs chat memory vs issue trackers. The question is not which is smartest; it is which one should own live agent status.
• Best Cursor next step: package the working pieces once they prove useful. If you want the glue to become installable instead of copied between repos, see Create a Cursor Plugin You Can Install.

Further reading

• Cursor — Agent
• Cursor — Rules
• I built an agent-first productivity bridge for all your agents — source

Next step

Pick one active branch and write down the task handoff you wish your next agent would read. If that note belongs outside chat, TaskShell is worth a small, careful test.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.