git-in-track

Git-native, Markdown-first project management for teams — and for their AI agents.

Project site: https://digiogithub.github.io/git-in-track/ (source in pages/, deployed by pages.yml).

What is git-in-track

git-in-track is a project management tool with no central server and no database. Every artifact — epics, user stories, tasks, milestones, comments, boards, sprints, retrospectives and knowledge base pages — is a plain Markdown file with YAML front matter stored inside a git repository. If you can clone the repo, you have the whole backlog, its full history, and the ability to work offline.

Humans work through a web UI that feels like an Obsidian or Logseq vault crossed with a Kanban board: browse the knowledge base, edit stories in a rich Markdown editor, drag cards across columns. AI agents work on exactly the same files, either directly on disk or through a local MCP server, so an agent that picks up a story and a developer that reviews it are looking at the same bytes.

Sync is git and nothing else. Any host works — GitHub, GitLab, Gitea, Bitbucket or a bare repository on your own machine — because git-in-track only ever speaks standard git. There is no SaaS to sign up for, no export format to worry about, and no vendor that can take your backlog away.

Key features

• Plain files, no lock-in. Markdown + YAML front matter, readable and editable with any text editor.
• Git is the only sync mechanism. No server, no database, no accounts. Multi-user collaboration is just multiple people pushing to the same repos.
• Browser-only mode. Open local folders straight from a Chromium-based browser; parsing and indexing run in WebAssembly compiled from the shared Go core.
• Companion CLI. gintrack serve runs a local server that embeds the same web app, watches the file system for instant updates, and indexes natively.
• Team boards across projects. Kanban and Scrum boards live in a team repository and reference items in project repositories — never copies.
• Knowledge base included. Any docs folder becomes a rendered KB with GFM tables, task lists, footnotes, callouts, wikilinks and Mermaid diagrams.
• Agent-native. An MCP server exposes the backlog as compact, paginated tools designed for LLM agents.
• Specs and spec-driven development. spec items hold numbered requirement blocks (### ACME-SP-0003.R2 — …); // Implements: and // Verifies: markers in code tie them to code and tests, and gintrack spec impact (or the spec_impact MCP tool) tells an agent or a CI gate which requirements a diff affects and whether they still pass. See ADR-037, the format in docs/03 §21, the CLI in docs/07 §4.19–4.20, and the agent loop in AGENTS.md.
• One core, two runtimes. The same Go code powers the CLI and the browser WASM module, so behavior never drifts between them.

How it works

There are two kinds of repositories.

A project repository is any git repository you already have. You mark one folder as its documentation folder (for example docs/); that folder becomes the project knowledge base. Inside it, a .pmngr/ directory holds the project backlog: project.yaml, epics/, stories/, tasks/, milestones/ and comments/. A project's full backlog lives only in the project repository, next to the code it describes.

A team repository — one per team — holds team.yaml (members plus the list of project repositories), a team-wide knowledge/ folder, and a .pmngr/ directory with boards/, sprints/ and retros/. Boards aggregate work from every project by reference (ref: <projectKey>/<itemId>). If a project repo is not cloned locally, its cards are rendered as read-only remote references from the index snapshot committed under .pmngr/index/<projectKey>.json.

You can use git-in-track in browser-only mode (pick folders with the File System Access API; the shared Go core runs as WebAssembly in a Web Worker; git operations via isomorphic-git) or in companion mode, where the gintrack CLI serves the same web app locally, watches files with fsnotify and performs git operations natively. The web app detects the companion and upgrades itself automatically. Agents connect through gintrack mcp over stdio, or over streamable HTTP on the local server.

flowchart LR
    subgraph Local["Your machine"]
        WEB["Web app<br/>React 18 + Vite"]
        CLI["gintrack CLI<br/>serve / mcp"]
        WASM["Go core<br/>as WASM"]
        FS[("Working trees<br/>on disk")]
    end
    subgraph Repos["Git remotes (any host)"]
        TEAM["Team repo<br/>team.yaml, boards,<br/>sprints, retros"]
        P1["Project repo A<br/>docs/.pmngr/"]
        P2["Project repo B<br/>docs/.pmngr/"]
    end
    AGENT["AI agent"]

    WEB -->|File System Access| FS
    WEB --> WASM
    WEB <-->|REST + WebSocket| CLI
    CLI --> FS
    AGENT -->|MCP| CLI
    FS <-->|git fetch / push| TEAM
    FS <-->|git fetch / push| P1
    FS <-->|git fetch / push| P2
    TEAM -.->|ref: KEY/ITEM-ID| P1
    TEAM -.->|ref: KEY/ITEM-ID| P2

What an item looks like

docs/.pmngr/stories/ACME-US-0042-login-with-sso.md:

This is the beginning of the README. Read the rest at the original. Read the full README ↗