v0.16.0: progress command

New

• ticketgraph progress (MCP: tickets.progress): a token-cheap answer to "how far through the backlog am I". Points-based headline with ticket counts alongside, a status line, and a 20-cell bar. Deferred tickets are excluded so a run that defers work can still reach 100%. Unsized tickets count 0 points and are reported as unsized N. When nothing is sized the percentage falls back to tickets and says so.
• --by epic|parent|type|tag appends one row per group, laggards first. Ungrouped tickets appear as (none). --by tag counts a ticket once per tag, so group totals can exceed the project total.
• --format json returns the lossless structure with no bar string; --format table renders the group rows as a table. --project all aggregates across projects.

v0.15.2: now on npm

ticketgraph is now on npm:

npm install -g ticketgraph

or run it without installing: npx ticketgraph list.

No functional changes to the CLI or MCP server in this version.

v0.15.1

This version was not published to npm. Install 0.15.2 or later:

npm install -g ticketgraph

No functional changes to the CLI or MCP server in this version.

v0.15.0

This version was not published to npm. Install 0.15.2 or later:

npm install -g ticketgraph

Changes

• The package name is now the unscoped ticketgraph, so the install command matches the binary name.
• README and docs/install.md lead with the npm install; clone-and-build is the "Install from source" path.

v0.14.0 — add_many accepts --project alongside --json

Fixed

ticketgraph add_many --project X --json '{"tickets":[...]}' now works.

Previously --json was only recognised as the first token and had to be the sole input, so combining it with --project failed with add_many requires --json, an error telling you to do what you had just done. Dropping --project to get past it made add_many resolve the project from the current directory instead: exit 0, a created=[...] line, and the tickets landing in a different project from the one intended. From the caller's side that looked like a batch create that printed success and created nothing.

--json is now recognised at any position and merged with ordinary flag parsing, so --project (and any other scalar flag) behaves the same way it does for add. Setting the same key through both channels is a usage error rather than a silent last-wins, and --json given twice or with no value is still rejected.

v0.13.1: fix force re-import of a parent ticket with children

Fix: a forced import_json that replaced a ticket which still had children failed with NOT NULL constraint failed: tickets.project_id. The composite (project_id, parent_id) FK is ON DELETE SET NULL, and SQLite nulls every column of the child key. insertBatch now detaches children before deleting each colliding ticket. Regression test added.

v0.13.0 — ticket capture skill (log & size, don't implement)

New: the ticket capture skill

Fixes a recurring behavioural failure: saying "new bug" / "new ticket" / "new task" means capture this work for later — but Claude would often start implementing instead.

• skills/ticket/SKILL.md — auto-triggers on "new bug/ticket/task" (and serves /ticket). Enforces a strict capture discipline: quick read-only investigation → classify (type/priority) → size with a Fibonacci effort → create via tickets.add → STOP. It never edits code; the work is only picked up on an explicit follow-up.
• commands/todo.md — a /todo alias that delegates to the same discipline.
• Tests — skills.test.ts guards the skill's frontmatter and its "don't implement" discipline so it can't be silently dropped; commands.test.ts now covers todo.

568 tests green.

v0.12.0 — effort sizing prompted at ticket creation

What changed

/outstanding (the list command) already renders an effort column, but it showed - for nearly every ticket because nothing prompted effort to be captured when a ticket was logged. Design spec §15 says "the author will not assign effort values. Claude will" — the tooling just never surfaced that at the point of use.

This release closes the capture gap (no display or schema changes):

• tickets.add / tickets.add_many — descriptions now instruct sizing at creation, and the effort field carries the Fibonacci scale rubric (1/2/3/5/8/13) inline, so it appears in MCP schemas and CLI --help.
• ticketgraph skill — added a "Size effort when you log a ticket" note to the writing section.

561 tests green.

v0.11.0 — installable plugin marketplace

Added

• .claude-plugin/marketplace.json — the repo now doubles as its own single-plugin marketplace, so the bundled skills install via Claude Code:

  /plugin marketplace add edwilde/ticketgraph
  /plugin install ticketgraph@ticketgraph
  

  (source: "./", no version — plugin.json stays the single source of truth.)

Changed

• Renamed the outstanding-tickets skill to outstanding so the automatic plugin namespace reads cleanly as /ticketgraph:outstanding rather than the redundant …:outstanding-tickets. Sets the terse-name convention for the planned wrapper family.
• Documented the marketplace install in README + docs/install.md.

Notes

• The marketplace install ships skills only. They drive the ticketgraph CLI, which depends on the native better-sqlite3 addon — a plugin clone does not build it, so the binary still needs a dev build (npm publish is the planned binary-distribution path, not yet done).

v0.10.0 — /outstanding-tickets skill + scope discipline

Added

• /outstanding-tickets skill — answers "what's outstanding" with a single token-cheap ticketgraph list --status outstanding call and stops. The first of a planned set of command-wrapper skills; dogfoods the project's token-efficiency pitch.

Changed

• ticketgraph skill — new "Common mistakes" entry: a status/list question is one list call. Don't pile on stats / blockers_of / version checks unless the user asks "why blocked", wants counts, or wants per-ticket detail.