Jekt FAQ

Answers to common questions about what Jekt™ is, how to try it, and what adoption involves.

Understanding Jekt

What is Jekt, and what do you mean by "context architecture"?

Jekt is a specification for preserving and organizing a project's working knowledge in a way both humans and AI tools can use while remaining vendor agnostic. It defines working context in the project's repository itself as ordinary files under a .jekt/ directory: tickets, plans, design documents, minutes, comments, summaries, and related material.

In practical terms, "context architecture" means a structured way to keep project context. Jekt does this with plain, durable artifacts that people and AI assistants can read and update directly. Project tracking follows from preserving that useful context: Jekt treats context as a continuous spectrum, from project planning through tickets and commits down to LLM chats.

Conventional task or bug trackers start with work items in a database and leave much of the surrounding reasoning in comments, if anywhere. Jekt fits into the workflow: Jekt-enabled tools not only help write and manage tickets, but also interact with the ongoing work and AI chat to continually produce semantically rich, durable artifacts. Rather than adding AI to an external ticket tracker, Jekt brings the tickets and other context to the AI by storing them in the project itself so that context remains accessible to AI tools.

For a fuller orientation, read the Jekt Primer.

Is it really just files?

Yes. A Jekt repository is a .jekt/ directory containing Markdown, YAML, and plain-text list files. There is no separate database, server, proprietary format, or generated index that must be kept in sync.

The file system is the database: a directory listing is a listing, a text search is a query, and a Git diff is the history. The files your editor shows you are the files your AI assistant reads. If every Jekt-specific tool disappeared, the data would still be usable by hand.

See the Jekt Primer and Jekt Design Principles for the design behind that choice.

Isn't Jekt just an AI memory or retrieval system?

No. A retrieval or RAG system breaks text into chunks and retrieves by similarity. Jekt stores work in artifacts that are meaningful in their own right: a ticket, a plan, a design, a minutes entry, a summary. The boundary comes from the structure of the work, not from a text-splitting algorithm.

Jekt provides structured working context. A Jekt repository is not a RAG corpus.

Do I have to use AI to use Jekt?

No. Because the artifacts are plain files, you can create and edit them by hand in any editor.

However Jekt is designed to work especially well with an AI assistant. The assistant reads the same files you read and writes the same files you write. Its changes are ordinary file edits you can review, for example through Git.

To get started quickly, use the reference prompts, or write your own tooling against the same files.

Adopting Jekt

Is Jekt ready to rely on?

Jekt is new and developing quickly. The current specification, pages, and reference prompts already work well enough that they are being used in the development of Jekt itself.

Keep in mind that Jekt adds knowledge persistence to your work, and Jekt is continually improving. Try it for yourself. The produced context artifacts are yours to keep, whether you decide to continue using Jekt.

Can Jekt replace my issue tracker?

For many teams and workflows, yes. Jekt is meant to replace issue trackers by managing tickets, releases, and workflow in the repository itself.

For the conceptual differences between Jekt, issue trackers, documentation systems, and AI memory systems, see the Jekt Primer. Feature-by-feature comparison with tools such as Jira, GitHub Issues, and GitLab will be shown on the Comparison page.

What does Jekt cost?

Jekt itself is an interoperability specification for arranging project context as files. Jekt itself costs nothing; any costs depend on the tool you use with it.

If you use Jekt by hand, there is nothing to buy: the artifacts are just files you edit. The reference prompts are free to use; the AI assistant or LLM you use with them may charge for its own usage, as with any prompt. The context artifacts produced by the prompts are yours to keep.

GlobalMentor, Inc., the company stewarding the Jekt specification, intends to launch a VS Code extension and other tools. The extension is expected to be free for basic use, potentially with charges for additional features; details are forthcoming.

No Jekt server or account is required. The data produced in the Jekt layout is yours to keep and use with any interoperable tool.

Who is behind Jekt? Is it open? Can I build my own tools on it?

Jekt is an open specification intended for industry interoperability, independent of any particular tool. It is stewarded by GlobalMentor, Inc., and you own your content.

The specification and documents are published under Creative Commons Attribution 4.0 (CC BY 4.0). The reference prompts are published under the Apache License 2.0. Independent tools built on the format are expected and encouraged.

GlobalMentor was founded to offer international educational technology. It took part in producing OEBPS, which became the EPUB specification for electronic book publishing, and has participated as a member of the Open eBook Forum, the World Wide Web Consortium (W3C), and the Unicode Consortium. That background in open interoperability specifications gives it relevant experience for stewarding Jekt.

For Jekt stewardship and legal details, see About. For more about the company, see About GlobalMentor, Inc..

Does using Jekt send my data anywhere?

Jekt itself is not a service and does not transmit your data. Your content is local files that you own.

The reference prompts use the network primarily when an operation needs ticket-number coordination against your own Git remote, so two people do not claim the same number. That coordination is used when project initialization creates the coordination branch on the remote and when ticket creation claims a number. Prompts may also initiate network actions that you request as part of your workflow, such as pushing a branch to your remote repository or, in the future, opening a pull request. In general, though, the reference prompts request no additional network access, and they provide feedback before important actions.

Beyond Jekt itself, whether anything leaves your machine depends on the AI tool you choose. For example, GitHub Copilot communicates with its own LLM service; that is a property of the tool, not of the Jekt format. LLM agents are non-deterministic in general, so your AI tool should have appropriate guardrails whether or not you use the Jekt reference prompts.

Getting Started

Do I have to learn a large command set?

No. In normal use, you ask the Jekt command in plain language through /jekt: describe what you want, and it responds.

When a dedicated operation fits better, /jekt points you to the specific command, such as /jekt-plan-create. Read-only questions are answered directly; producing or changing artifacts is routed to the dedicated commands.

What do I need to start?

For the reference prompts available at launch, use GitHub Copilot in VS Code with Git installed and accessible in the project environment. Install the prompts from Reference Prompts.

Git matters because Jekt is Git-native. Git carries the context with the code, supplies history and attribution, supports the tickets/{ticket-id} branch workflow, enables ordinary commits, and provides optional remote coordination to avoid duplicate ticket numbers on a team.

Jekt is not Git-dependent at the data-model level. If Git is unavailable, the .jekt/ files remain ordinary Markdown, YAML, and list files that can be browsed and edited by hand. Git-backed capabilities such as history, attribution, branch-based work, commits, and remote ticket-number coordination are simply unavailable in that mode.

In principle, you are not limited to GitHub Copilot and VS Code. Because Jekt is just files, other tools can interoperate. The forthcoming VS Code extension is intended to become the preferred interface later.

How do I see my tickets?

Ask /jekt in plain language. For example, you can ask it to show open tickets assigned to you for a release, ordered by priority.

Underneath that convenience, tickets are just files under .jekt/tickets/. You or any tool can browse and search them directly with ordinary editor and file tools.

How do I finish or close a ticket?

At launch there is not yet a dedicated command to finish or close a ticket. For now, use the Jekt prompts to perform the closing sequence explicitly:

Ask /jekt to resolve the ticket, setting jekt/status to resolved and choosing the appropriate jekt/resolution from the conversation.
Run /jekt-minutes-update to update the minutes one final time.
Run /jekt-ticket-summarize to produce the ticket summary.
Stage the files with Git, then run /jekt-commit.
File a pull request or merge the branch according to your normal workflow.

Additional reference prompts are expected to handle more of this process, and the forthcoming VS Code extension is expected to add more automation and coordination.

Why doesn't the assistant record minutes automatically?

Today, recording significant events in minutes relies on the user explicitly invoking a prompt: you ask, and the assistant curates the entries. It works this way because the launch reference prompts run inside your existing editor and assistant environment, so you can start using Jekt right away. In that setting, capture is something you invoke rather than something that happens automatically as work proceeds.

Eventually capture is expected to become more automatic: the tooling would record the right artifacts as the work proceeds, the way a capable assistant would. Making capture more automatic is an active direction of development and will be pursued in new tools such as the upcoming VS Code extension.

Working as a Team

What stops two people from creating tickets with the same number?

Jekt coordinates ticket numbers using Git. With coordination enabled, a tool claims a candidate number by atomically creating a small Git reference for that ticket ID on the shared remote, under refs/jekt/ticket-claims/. If another contributor has already claimed the number, the push is rejected and the tool retries with the next one.

Coordination is signaled by an orphan branch named jekt on the origin remote. The claim references are not branches and do not clutter ordinary branch listings.

When no remote or coordination is available, numbering falls back to local allocation and the tool reports that the number is uncoordinated.

How do teammates see work that's still on an unmerged branch?

This is an acknowledged open area. Because a ticket's files live on its working branch, teammates do not see those files until that branch merges.

The interim practice is to create tickets in a dedicated ticket-writing session, or at the start of a sprint, and merge them into the main branch before the sprint so the team shares them.

Fuller cross-team visibility patterns are still being worked out.