ContextsBase replaces the ticket board. You write each business feature once in a Notion-style editor, organised in a file tree: what it does, its rules, its edge cases, its test cases. Claude Code, Cursor, or Copilot read it over MCP, build it, and keep an implementation record in sync with the code. Nobody is assigned anything.
acme-app
New feature
Accounts / F-3
Password reset
PublishedFunctionality
A signed-out user requests a reset link by email and sets a new password from it.
Business rules
Edge cases
An unknown email still shows the success message, so accounts cannot be enumerated.
Entities
UserResetToken
Test cases
Type / for a block
Implementation record
Edit any rule above and this record turns Outdated until the agent rebuilds.
A file tree, a spec editor, and the agent’s record beside it. The feature is the ticket, the spec, and the proof of done in one place.
Jira exists to hand work between humans: assignees, sprints, status columns. When the builder is an agent, none of that is needed. What it needs is the feature, written properly, once.
UserResetTokenT-7T-8
A ticket says what to do and leaves the rest to whoever picks it up. A feature states what must be true: functionality, business rules, edge cases, the entities it touches, and its test cases. An agent builds from that directly.
→ agent pulls next_iteration_item
No assignee, no sprint, no board to groom. You put features in the order you want them built and open the iteration. Agents pull the next one. Two agents never take the same feature.
✓ record_test_automation · T-7, T-8 passed
✓ record_feature_implementation · F-3
Nobody drags a card to Done. The agent records the implementation and the test results against the spec it read. Change the spec later and that record flips to Outdated on its own.
Jira tracks who does what by when. Agents do not need that. They need to know what to build, and to say when it is built.
| With Jira | A ticket | A ContextsBase feature |
|---|---|---|
| The unit of work | A ticket: title, description, comments, and links to wherever the real requirements live. | A feature (F-3): functionality, business rules, edge cases, the entities it touches, and Given/When/Then test cases. One document, complete enough to build from. |
| Who it is written for | A teammate who reads it, asks questions, and fills the gaps from experience. | An agent that builds exactly what is written. Nothing is left to be inferred, so nothing is guessed. |
| Getting work started | Assign it, add it to a sprint, move it to In Progress. | Order features into an iteration and open it. The agent calls next_iteration_item and gets the next one. No assignee, no sprint. |
| Tracking progress | Someone drags the card across columns and hopes it reflects reality. | The agent calls record_feature_implementation when it is built. Status comes from the record, not from a hand. |
| Acceptance | Acceptance criteria in a text field. A reviewer reads them, or does not. | Test cases are part of the feature. The agent turns them into Playwright tests and records each result with record_test_automation. |
| When requirements change | Edit the ticket, leave a comment, ping the assignee, reopen. | Edit the feature. Every implementation built from the old spec is marked Outdated automatically, and the agent rebuilds from the new one. |
| Where the spec lives | Jira for the task, Confluence for the doc, Slack for the decision. | One place. Served to every agent over MCP, so nothing is pasted into a chat window. |
You write and order features. The agent asks for the next one, builds it, and records it. That is the entire workflow.
Write the feature
YouOpen the editor, file it in the right folder, and write it: functionality, business rules, edge cases, Given/When/Then test cases. Publish it.
F-3 · PublishedOrder the iteration
YouPut features in the sequence you want them built. Open it to agents.
I-1 · 5 featuresPull the next item
AgentOne call returns the spec, the entities it touches, and its test cases. The claim is atomic.
next_iteration_itemBuild, test, record
AgentThe agent writes the code and Playwright tests, then records both against the spec it read.
record_feature_implementationContextsBase holds the features. The agent you already use builds them. Any MCP client connects with one config block and a scoped token.
{
"mcpServers": {
"contextsbase": {
"url": "https://app.contextsbase.com/api/v1/mcp",
"headers": { "Authorization": "Bearer mcp_live_…" }
}
}
}Free
$0
One real project, fed to your agent.
Premium
$5per month
Cancel any time.
It means the place where the work to be built is written, when the builder is an AI coding agent. In ContextsBase that place is the Features module. Instead of tickets assigned to people, you write business features: what the feature does, its rules, its edge cases, its entities, and its test cases. Agents such as Claude Code, Cursor, and GitHub Copilot read them over MCP and build them.
Yes, for software your agents build. There are no tickets, assignees, sprints, or status columns to maintain. You write a feature once and order it into an iteration; that is the whole planning step. The agent pulls it, builds it, and records the result. Teams that still use Jira for non-engineering work can keep it there, but the engineering backlog lives in ContextsBase.
A feature (F-1, F-2, and so on) is a page you write in a Notion-style editor, filed in a folder tree alongside your entities, test cases, and iterations. It holds what the feature does, the business rules it must obey, its edge cases, the entities it touches, and Given/When/Then test cases. It is a draft until you publish it. Agents only read published features, so nothing half-written reaches them.
You do not. Put features into an iteration in the order you want them built and open it to agents. Any connected agent calls next_iteration_item and receives the next unclaimed feature with its spec, entities, and test cases. Claims are atomic, so two agents never build the same feature.
Any Model Context Protocol (MCP) client, including Claude Code, Cursor, GitHub Copilot, and Windsurf. ContextsBase does not supply an agent. You connect the one you already use with one config block and a scoped token.
The agent calls record_test_automation with the Playwright result for each test case, then record_feature_implementation for the feature. The record sits beside the spec: Implemented, which agent built it, which tests passed, and a fingerprint of the exact spec it read. If you edit the feature later, that record is marked Outdated until the agent rebuilds, so the spec and the code never silently drift apart.
Yes. The Free plan includes one project, 100 features per project, three members, one MCP token, and unlimited open iterations. A Premium plan at $5 per month is coming soon.
One feature, one iteration, one line of config. Your agent is building from it in ten minutes.
Jira is a trademark of Atlassian. ContextsBase is an independent product and is not affiliated with or endorsed by Atlassian. Learn more about ContextsBase, the knowledge base for coding agents, or contact support.