{"slug": "pinto-a-git-native-scrum-backlog-and-kanban-board-for-your-terminal", "title": "pinto: A Git-Native Scrum Backlog and Kanban Board for Your Terminal", "summary": "A developer released pinto, a Git-native Scrum backlog and Kanban board that runs entirely in the terminal. The tool stores backlog items as plain Markdown files with TOML frontmatter, enabling teams to track changes with git diff, merge via pull requests, and work without a server or hosted database. pinto supports Scrum artifacts like Product Backlog Items, Sprints, and Kanban, and is built as a Rust binary available from crates.io.", "body_md": "[pinto](https://github.com/moriturus/pinto) lets teams manage Scrum backlogs as plain text.\n\nEvery backlog change can be inspected with `git diff`\n\n, carried across a branch, merged, and reviewed in a pull request—just like source code. The backlog follows the same lifecycle as the product it describes.\n\npinto is local-first: no server, account, or hosted database is required. It works with AI agents, but never depends on them. And unlike a generic CLI to-do list, its core model is Scrum: Product Backlog Items (PBIs), Sprints, Kanban, and the metrics teams use to inspect and adapt.\n\nJira, Asana, and Notion are capable products. But as more features accumulate, the process can start serving the tool instead of the other way around:\n\nScrum is meant to be a **lightweight framework for rapid inspection and adaptation**. When maintaining the board becomes work in its own right, the tooling has lost sight of that goal.\n\nThe name *pinto* comes from the Japanese word *ピント**“focus.”* That is also the design intent: keep the team's attention on the Product Backlog, the Sprint, and the work flowing across the board.\n\npinto deliberately stays small. It starts quickly, keeps dependencies and vocabulary limited, stores durable data as readable files, and excludes project-suite features such as Gantt charts and CRM.\n\nRunning `pinto init`\n\ncreates a `.pinto/`\n\ndirectory beside your code. Each PBI is a Markdown file with TOML frontmatter. Here is a real item from pinto's own backlog:\n\n```\n+++\nid = \"P-2\"\ntitle = \"Investigate and fix Windows CI while retaining Windows support\"\nstatus = \"done\"\nrank = \"j\"\nlabels = [\"ci\", \"windows\"]\ncreated = \"2026-07-15T06:24:58.731847Z\"\nupdated = \"2026-07-15T09:34:50.653786Z\"\n+++\n\n# Summary\n\nInvestigate, verify, and fix the current Windows CI failure while\nkeeping Windows as a supported target.\n\n# Acceptance Criteria\n\n- [x] The root cause is documented.\n- [x] The Windows build and tests pass on windows-latest.\n```\n\nBecause the backlog is made of ordinary files, your existing engineering workflow applies to it:\n\n`git diff`\n\n.`git log`\n\nand process data with tools such as `grep`\n\n.pinto can also link commits to PBIs (`pinto link add`\n\n/ `pinto link scan`\n\n), keep a shared Definition of Done (`pinto dod`\n\n), and record dependencies (`pinto dep`\n\n). None of that requires a separate service.\n\n“Git-native” does not mean Git is mandatory. The default file backend works without it. It means the data format can participate naturally in a Git workflow whenever the project does.\n\nInstall the native Rust binary from crates.io:\n\n```\ncargo install pinto-cli\n```\n\nBuilding from source requires Rust 1.89 or later; the commands are available in the [repository README](https://github.com/moriturus/pinto#installation).\n\nConsider a team building a login flow. The examples below use actual pinto output.\n\nInitialize the board and add a handful of PBIs:\n\n```\npinto init\npinto add \"Design the login form\" --points 3 --label ui --label auth\npinto add \"Implement the login API\" --points 5 --label api --label auth\npinto add \"Write onboarding docs\" --points 2 --label docs\npinto add \"Fix the session timeout bug\" --points 1 --label bug --label auth\npinto add \"Refactor the storage layer\" --points 8 --label refactor\npinto list\nT-1  todo  Design the login form  (3)  [ui, auth]\nT-2  todo  Implement the login API  (5)  [api, auth]\nT-3  todo  Write onboarding docs  (2)  [docs]\nT-4  todo  Fix the session timeout bug  (1)  [bug, auth]\nT-5  todo  Refactor the storage layer  (8)  [refactor]\n```\n\nEach line keeps the essential context visible without opening a detail page. Rank controls Product Backlog order, so changing priority is as direct as `pinto reorder T-4 --top`\n\n.\n\nNow pull the three highest-ranked items into a two-week Sprint:\n\n```\npinto sprint new S-1 \"Sprint 1\" --goal \"Ship the login flow\" \\\n  --start 2026-07-13 --end 2026-07-27\npinto sprint add S-1 --status todo --limit 3   # Add the top three ranked PBIs\npinto sprint start S-1\nCreated sprint S-1 Sprint 1\nAssigned T-1 to sprint S-1\nAssigned T-2 to sprint S-1\nAssigned T-3 to sprint S-1\nStarted sprint S-1\n```\n\nThe `move`\n\ncommand takes the destination last, like Unix `mv`\n\n; `mv`\n\nis also an alias.\n\n```\npinto move T-1 in-progress\npinto move T-2 in-progress\npinto move T-1 done\npinto board\ntodo (3)\n  T-3  Write onboarding docs\n  T-4  Fix the session timeout bug\n  T-5  Refactor the storage layer\n\nin-progress (1)\n  T-2  Implement the login API\n\nreview (0)\n  (empty)\n\ndone (1)\n  T-1  Design the login form\n```\n\nTeams can define WIP limits in `.pinto/config.toml`\n\n. For a more interactive workflow, `pinto kanban`\n\nopens a terminal UI where you can move cards, edit them in `$EDITOR`\n\n, and manage dependencies and parent-child relationships.\n\nDuring the Sprint, `pinto sprint burndown S-1`\n\nrenders progress directly in the terminal:\n\n```\nS-1 Sprint 1 - burndown (points)\nPeriod 2026-07-13 → 2026-07-27 · total 10\n█ remaining  ┆ ideal\n2026-07-13 │███████████████████████████████████████████████████████████████┆│ 10\n2026-07-15 │████████████████████████████████████████████░░░░░░░░░░░┆░░░░░░░░│  7\n2026-07-17 │████████████████████████████████████████████░░┆░░░░░░░░░░░░░░░░░│  7\n...\n2026-07-27 │┆███████████████████████████████████████████░░░░░░░░░░░░░░░░░░░░│  7\n```\n\nThe same Scrum model can estimate capacity before the team commits to the Sprint:\n\n```\npinto sprint capacity S-1 --daily-hours 8 --holidays 1 --deduction-factor 0.2\n```\n\nOnce the remaining PBIs are done, close the Sprint and inspect velocity, cycle time, and lead time:\n\n```\npinto move T-2 T-3 done\npinto sprint close S-1\npinto sprint velocity\npinto cycletime --sprint S-1\nClosed sprint S-1\nVelocity (last 5 sprints)\nS-1  10 points  completed: 3  unestimated: 0  incomplete: 0\nAverage: 10.0 points\n\nCycle/Lead time - 3 completed\n  cycle (start → done)    n=3 mean 4s median 0s min 0s max 14s\n  lead  (created → done)  n=3 mean 36s median 41s min 26s max 41s\n```\n\nThis board was created in under a minute, which is why the timing values are measured in seconds. A real project reveals the distribution across days and builds a useful velocity trend over successive Sprints.\n\nThe point is not the number of commands. It is that backlog refinement, Sprint execution, and inspection all happen without leaving the repository or the terminal.\n\nMost read-only commands support `--json`\n\n. For writes, pinto provides `pinto automate`\n\n, a deliberately narrow boundary for agent-driven changes.\n\n`automate`\n\naccepts a structured JSON plan made of argument arrays. Three properties make that boundary reviewable:\n\n`--dry-run`\n\nexecutes the plan against an `--json`\n\nreports every command as `valid`\n\n, `succeeded`\n\n, `failed`\n\n, or `skipped`\n\n, together with created and updated item IDs.Imagine asking a coding agent:\n\nRead the backlog and propose a pinto plan for a two-week Sprint starting next week. Show me a dry run before applying anything.\n\nThe agent first reads the current backlog:\n\n```\npinto list --status todo --json\n```\n\nIt then writes a plain, human-reviewable `plan.json`\n\n:\n\n```\n{\n  \"commands\": [\n    [\"sprint\", \"new\", \"S-2\", \"Sprint 2\",\n     \"--goal\", \"Harden auth\", \"--start\", \"2026-07-28\", \"--end\", \"2026-08-11\"],\n    [\"sprint\", \"add\", \"S-2\", \"T-4\"],\n    [\"sprint\", \"add\", \"S-2\", \"T-5\"],\n    [\"sprint\", \"start\", \"S-2\"]\n  ]\n}\n```\n\nBefore applying it, the agent validates the plan:\n\n```\npinto automate --plan plan.json --dry-run --json\n{\n  \"status\": \"dry_run\",\n  \"dry_run\": true,\n  \"commands\": [\n    {\n      \"index\": 1,\n      \"command\": \"sprint new\",\n      \"status\": \"valid\",\n      \"created_ids\": [],\n      \"updated_ids\": [],\n      \"error\": null\n    },\n    {\n      \"index\": 2,\n      \"command\": \"sprint add\",\n      \"status\": \"valid\",\n      \"created_ids\": [],\n      \"updated_ids\": [\"T-4\"],\n      \"error\": null\n    },\n    {\n      \"index\": 3,\n      \"command\": \"sprint add\",\n      \"status\": \"valid\",\n      \"created_ids\": [],\n      \"updated_ids\": [\"T-5\"],\n      \"error\": null\n    },\n    {\n      \"index\": 4,\n      \"command\": \"sprint start\",\n      \"status\": \"valid\",\n      \"created_ids\": [],\n      \"updated_ids\": [],\n      \"error\": null\n    }\n  ]\n}\n```\n\nA human reviews `plan.json`\n\nor the dry-run result and removes `--dry-run`\n\nonly when the proposal is sound. **The agent's suggestion and its application to the board are separated by a reviewable artifact.** That artifact can even travel with a pull request.\n\nThe same mechanism works for incident triage. An agent can turn a postmortem into a reviewable set of follow-up PBIs:\n\n```\n{\n  \"commands\": [\n    [\"add\", \"Add retry to the session refresh job\",\n     \"--points\", \"2\", \"--label\", \"bug\", \"--label\", \"auth\"],\n    [\"add\", \"Alert on refresh failure rate\",\n     \"--points\", \"3\", \"--label\", \"ops\",\n     \"--body\", \"Threshold and runbook link are in the postmortem.\"],\n    [\"add\", \"Document the session lifecycle\",\n     \"--points\", \"1\", \"--label\", \"docs\"]\n  ]\n}\n```\n\nBecause `add`\n\nsupports `--body`\n\nand `--template`\n\n, the plan can create useful PBIs without opening an editor. Long or multiline plans can be passed as files or through standard input (`--plan -`\n\n), while the team retains the same validation boundary.\n\nPlain files are the default. Two other backends are available when a project needs different persistence:\n\n```\npinto migrate --to git\n```\n\nThe **Git backend** creates one commit per complete write operation. It uses a temporary index to isolate existing working-tree changes, so uncommitted code does not leak into a board commit. For agent-driven edits, that produces a precise, operation-by-operation audit trail.\n\nAn optional **SQLite backend** is available behind a Cargo feature flag for teams that prefer a single-file database.\n\nIf this sounds familiar, take a look at [Backlog.md](https://github.com/MrLesk/Backlog.md). It is an excellent Markdown-native project manager with a terminal board, a local web UI, search across tasks and project knowledge, and agent workflows through CLI instructions or MCP.\n\npinto learned from that approach but deliberately chose a narrower scope:\n\n| Area | Backlog.md | pinto |\n|---|---|---|\n| Primary focus | Tasks, specs, docs, and decisions | Product Backlog, Sprints, and Kanban |\n| Persistent data | Markdown files | Markdown with TOML frontmatter |\n| Scrum reporting | Not the core model | Capacity, burndown, velocity, cycle/lead time |\n| Interactive UI | Terminal board and local web UI | CLI and terminal TUI |\n| Agent workflow | CLI instructions or optional MCP | Validated JSON plans with isolated dry-run |\n| Runtime | TypeScript/Bun | Native Rust binary |\n\nThis is a difference in purpose, not a claim of superiority. Choose *Backlog.md* when you want a broad workspace for tasks, specifications, documents, decisions, and agents. Choose `pinto`\n\nwhen the job is to run Scrum with the smallest practical tool.\n\npinto exists to keep the backlog close to the work: local, readable, reviewable, and governed by the same engineering habits as the code.\n\nClarity, Simplicity, and Humanity.\n\nWith or without AI.\n\nIf that is how you want to practice Scrum, [give pinto a try](https://github.com/moriturus/pinto). Issues and pull requests are welcome.", "url": "https://wpnews.pro/news/pinto-a-git-native-scrum-backlog-and-kanban-board-for-your-terminal", "canonical_source": "https://dev.to/moriturus/pinto-a-git-native-scrum-backlog-and-kanban-board-for-your-terminal-509", "published_at": "2026-07-15 18:35:18+00:00", "updated_at": "2026-07-15 18:39:08.138040+00:00", "lang": "en", "topics": ["developer-tools"], "entities": ["pinto", "moriturus", "Jira", "Asana", "Notion", "Rust"], "alternates": {"html": "https://wpnews.pro/news/pinto-a-git-native-scrum-backlog-and-kanban-board-for-your-terminal", "markdown": "https://wpnews.pro/news/pinto-a-git-native-scrum-backlog-and-kanban-board-for-your-terminal.md", "text": "https://wpnews.pro/news/pinto-a-git-native-scrum-backlog-and-kanban-board-for-your-terminal.txt", "jsonld": "https://wpnews.pro/news/pinto-a-git-native-scrum-backlog-and-kanban-board-for-your-terminal.jsonld"}}