The problem with BACKLOG.md was never the format. It was the absence of a schema.

Every engineering team that has tried "backlog as a text file" eventually collides with the same wall: unstructured prose doesn't support the queries you actually need at 9am on sprint planning day. Show me all blocked items. Show me what's ranked below the fold. Tell me which PBIs are dependencies of the one we're about to close. A freeform Markdown file can answer those questions if the humans who wrote it were disciplined and consistent — which is to say, it can't answer them reliably. The file becomes a living document that two engineers read and draw two different conclusions from, and the team slides back to Jira.

pinto, a Rust-powered terminal Scrum board released this week and installable via cargo install pinto-cli (Rust 1.89 or later required), proposes a different answer. Not a richer format, but a typed spine on top of the format you already have. Each Product Backlog Item is a plain Markdown file with structured TOML frontmatter, stored under a .pinto/ directory that lives inside your repository. The backlog becomes a first-class Git artifact: diffable, branchable, greppable, and code-reviewable from the same terminal where you write and ship code.

The Traceability Tax That Convention Can't Collect

The canonical approach to linking commits to work items is to embed ticket IDs in commit messages: fix(AUTH-1234): handle token refresh race condition. This convention is enforced by pre-commit hooks in disciplined teams and by social pressure everywhere else. It breaks constantly — engineers forget, squash commits erase the ID, and anyone pushing a hot fix at 2am skips the ceremony. The result is a commit history with traceability when it's convenient and silence when it matters most.

Moving to a hosted backlog tool solves the human compliance problem by making the ticket system authoritative and the commit message secondary. But it introduces a different failure mode: the backlog now lives in a separate system from the code it describes. A PBI says "add dark mode toggle," the feature ships, the ticket closes, and three months later no one can reconstruct the constraints that drove the implementation without cross-referencing two systems with different search interfaces, different access controls, and different retention policies.

Teams already practicing docs-as-code or GitOps have internalized the deeper principle: infrastructure and documentation belong in the same repository as the code they describe because co-location makes the relationship structural rather than conventional. A deployment config in the repo is versioned with the service it deploys. A spec document in the repo is reviewable alongside the feature it specifies. pinto extends that logic one step further: if the work is defined in the repo and the implementation is in the repo, the ticket should be in the repo too.

How pinto Structures the Backlog

Running pinto init creates a .pinto/ directory at the repository root. Each PBI is a separate file — Markdown body, TOML frontmatter delimited by +++ markers — containing the structured metadata that the CLI reads and writes. Based on pinto's described schema, a PBI file carries fields including id, title, status, rank, labels, and timestamps like created_at and updated_at, followed by a freeform description in standard Markdown.

The CLI exposes the full Scrum lifecycle as first-class commands. pinto sprint manages sprint creation and lifecycle transitions. pinto dod handles the Definition of Done — a structured policy document inside .pinto/ that teams can version and review like any other artifact. pinto dep tracks inter-PBI dependencies, expressing a dependency relationship as a reference between two file IDs rather than a comment in a ticket thread. pinto link scan is the command that earns the most attention: it scans commit messages for PBI IDs and creates bidirectional links between commits and their associated PBIs, making traceability automatic rather than aspirational.

A Kanban board view is included for teams who want the visual sprint state without leaving the terminal. Zero external service dependencies — no hosted database, no account creation, no required network access. Git integration is opt-in; the tool works against any local directory, though forgoing Git eliminates most of the value proposition.

Schema Discipline Is the Differentiator

The gap between pinto and a sophisticated BACKLOG.md is not the CLI wrapper or the Scrum terminology. It is schema discipline, and the distinction is worth being precise about.

A Markdown file with headers and checkboxes is human-readable and machine-opaque. Parsing - [x] AUTH-1234 — closed — @jane reliably across 300 tickets requires a bespoke parser that breaks the moment any contributor deviates from the format — which they will, because the format is undocumented convention. TOML frontmatter with a defined schema turns the backlog into a queryable dataset. rank is a sortable integer. status is an enumerated value. labels is a typed array. Because every field has a known type and every file follows the same structure, you can write deterministic tooling against the backlog without a pinto-specific integration: grep for all items with status = "blocked", run git diff .pinto/ to audit sprint planning changes, or wire a CI job that fails if any PBI has been in-progress for more than fourteen days.

pinto link scan is this principle applied to traceability. Embedding a ticket ID in a commit message is a convention — fragile, human-dependent, lost in a squash. The commit-to-PBI link that pinto link scan creates is structural: it lives in the repository, versioned by Git, recoverable from git log. The traceability becomes a byproduct of the existing commit workflow rather than a discipline requiring active human compliance with ticket-number conventions. That is a meaningfully different guarantee.

Who This Actually Serves — And Who It Doesn't

The technical design is coherent. The organizational fit is narrow, and the honest evaluation requires naming the boundary explicitly.

For a four-person founding team where every member is comfortable in a terminal, deploys with GitOps, and has no non-technical backlog stakeholders, pinto is a genuine workflow improvement. Backlog changes ship in the same PR as the code that implements them. Sprint planning produces a merge commit with a reviewable diff. The team's full engineering context — code, backlog, deployment config, documentation — lives in one versioned artifact with a unified history.

The organizational failure mode is sharp: pinto is optimized for a team where every stakeholder who needs to interact with the backlog is a terminal user. The moment you add a product manager, a designer, or a QA lead who works in Confluence or Notion, the "single source of truth" fractures. You end up maintaining two backlogs — pinto for the engineers, a GUI tool for everyone else — which is strictly worse than converging on the shared tool from the start. For a 20-person team with a dedicated PM, pinto doesn't solve a workflow problem; it creates a synchronization burden.

The permission model is a subtler concern in larger organizations. Most Scrum implementations treat backlog prioritization as the product owner's prerogative. In a pinto workflow, anyone with repository write access can merge a commit that changes a PBI's rank, closes a sprint, or marks a Definition of Done criterion as satisfied. For a small team of trusted engineers this is probably acceptable. For an organization with explicit product ownership structures, it violates the process expectations already in place.

Production friction is real: concurrent sprint updates from engineers on separate feature branches will generate merge conflicts in PBI files when those branches are merged. Status fields are particularly collision-prone during sprint reviews, when multiple PBIs transition to done simultaneously. The .pinto/ directory commits into main repo history, meaning git shortlog statistics will include backlog churn — noise for teams that rely on commit graphs for release notes generation or compliance audit trails. Sprint velocity reporting and burndown charts require custom scripting against the TOML frontmatter; that is build cost that should be estimated before the team commits to the tool.

Schema migration is the long-tail risk. If pinto changes its TOML frontmatter structure in a future release, migrating potentially hundreds of Markdown files across every unmerged branch falls to the team. There is no migration runner — just files on disk. The tool is early-stage enough that schema stability is not yet a guarantee, and the cost of a breaking schema change scales with the size and age of the backlog.

The non-obvious adoption path is not team Scrum at all. The most underserved use case pinto addresses is solo open-source maintainers who want to give contributors a structured way to claim and track work without requiring them to create accounts on an external project management service. Today, open-source contribution coordination happens through GitHub Issues with varying levels of discipline: a contributor comments "I'll take this," the maintainer replies "go ahead," and there is no machine-readable record of assignment, priority, or acceptance criteria. A .pinto/ directory committed to a public repository gives contributors a structured backlog they can read without authenticating to anything, fork without losing access, and contribute to through the same PR workflow they use for code. pinto link scan makes the relationship between a contributor's commits and the PBI they are addressing automatic. The local-first, no-account design is most valuable not for a corporate team with an existing identity provider, but for a public repository where contributor friction is the enemy of contribution.

The Decision Framework

Use pinto when: Your entire team — including anyone who creates, prioritizes, or closes tickets — works in a terminal. You are practicing docs-as-code or GitOps and want the backlog co-located with the source it describes. You are a solo open-source maintainer who wants structured backlog visibility without requiring contributors to create external accounts. Your team is three to eight engineers with no dedicated PM.

Do not use pinto when: Any non-technical stakeholder needs to interact with the backlog. You're on a monorepo serving multiple products or teams — the single .pinto/ directory has no multi-board or workspace isolation primitive, and it becomes a cross-team coordination problem at scale. You rely on push notifications or assignment interrupts for async distributed handoffs; pinto has no notification model.

Alternatives to evaluate first:

GitHub Projects is the closest zero-cost alternative for teams already on GitHub. It lacks Scrum sprint primitives but solves the stakeholder accessibility problem in the opposite direction — non-technical collaborators can participate without any terminal exposure, and native issue-to-PR linking provides traceability without a separate CLI.

Linear is the right call when you want Scrum structure plus stakeholder visibility plus API integrations, at $8–16 per seat. That seat cost buys an external service dependency, but the dependency is what makes cross-functional collaboration tractable. For teams with a dedicated PM or cross-functional sprint reviews, Linear's tradeoff is almost certainly correct.

Verdict

pinto is a well-scoped tool that solves a real problem for a specific audience and does not pretend to be otherwise. The typed TOML frontmatter is the correct primitive for enabling deterministic tooling against a backlog. pinto link scan is a structural solution to a problem the industry has been treating as a cultural one for two decades. The Rust implementation means the binary is fast and self-contained, with no runtime dependencies beyond the filesystem.

Most teams evaluating pinto will benefit more from GitHub Projects or Linear — not because pinto is poorly built, but because most teams have at least one non-terminal stakeholder, and one is enough to break the model. For the team that fits the profile — terminal-native, GitOps-oriented, no non-technical backlog stakeholders — pinto eliminates a category of context-switching that currently costs real time and real traceability. For solo open-source maintainers, it may be the most practical new contributor coordination tool released this year.

Install it with cargo install pinto-cli, commit the .pinto/ directory, and put a backlog change and a code change in the same PR. Either the workflow fits immediately or it reveals exactly where the friction lives.

Sources & Editorial Disclosure

This article was researched and written with AI assistance (Claude by Anthropic) as part of StackRadar's automated editorial pipeline. Content was synthesised from the following public developer community sources: GitHub Trending · Dev.to.

All technical claims, version numbers, benchmarks, and project details should be independently verified against official documentation or the original sources listed above. StackRadar analyses and synthesises publicly available information and does not claim original authorship of the underlying events, projects, or research described. Mention of any project, product, or organisation does not constitute an endorsement by StackRadar. This content is provided for informational purposes only — 2026-07-15.