Help us improve
Share bugs, ideas, or general feedback.
From backlogd
Query backlogd's local agent-execution + memory graph (.backlogd/graph/) — read-only. Records what only the loop knows (dispatch outcomes, latency, rework events) plus a low-signal aside of which files past problems touched. Use when a backlogd agent wants prior context before acting (problem-history / module-history / find-similar) or when a maintainer wants framework-effectiveness metrics (graph.py report). Local JSON only, no Linear/MCP — safe inside the developer's solve-only boundary. Pairs with references/graph-schema.md (nodes/edges/IDs) and references/graph-queries.md (copy-paste recipes).
npx claudepluginhub nicolai-bernsen/backlogd --plugin backlogdHow this skill is triggered — by the user, by Claude, or both
Slash command
/backlogd:graph-navigationThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
backlogd keeps a small **knowledge graph** of its own work. Its **primary signal** is the
Creates p5.js generative art with seeded randomness, noise fields, and interactive parameter exploration. Use for algorithmic art, flow fields, or particle systems.
Share bugs, ideas, or general feedback.
backlogd keeps a small knowledge graph of its own work. Its primary signal is the
agent-execution dimension — what only the scrum loop knows: when a unit was dispatched,
the recorded outcome (solved / partial / blocked — the coarse graph bucket the
orchestrator folds the developer's richer STATUS onto; see skills/solve/capture.md),
how long it took, when the PR opened, how long the whole run took, and how often a problem
was sent back for rework.
That's the data the maintainer asks framework-effectiveness questions of: "where do we
rework, where do we block, how fast does the loop close?"
Alongside the agent-execution edges, the graph also retains a small low-signal aside:
which files ("modules") past problems touched, so an agent can ask "have we been here
before, and what did it touch?" before acting. The file dimension duplicates git log
and is no longer emitted on new runs, but historical edges remain readable and
prior_work still surfaces them when present.
This skill is read-only navigation. It answers questions from the local store; it
never writes it. (Writing is the scrum-master's job — see skills/solve/dispatch.md,
skills/solve/handoff.md, and commands/review.md for the orchestrator hooks.)
Read this file first; reach for a reference when you act:
references/graph-schema.md— what the nodes and edges are: thekind:backend:native_idID convention, every edge type, the on-disk store layout, and the edge object shape. Read it when you're unsure what a node id or edge means.references/graph-queries.md— the exact, copy-paste query recipes (a tinyload_edges()loader + the lookups). Copy from here when you actually run a query.
linear skill. When you need work-item facts (status,
parent/child, blockers, comments) → use Linear via the MCP. When you need "how often
do we rework? how fast does the loop close?" → run graph.py report. When you need
"what's been solved near this code?" → use the lookups below.backlogd:developer can use it within its solve-only boundary.Scrum-master (/backlogd:solve) — during the loop:
dispatch_started / dispatch_completed / pr_opened /
run_completed / rework) are wired in the skill prose; you don't query those — they
feed graph.py report.Developer (backlogd:developer) — while solving, within the solve-only boundary:
Maintainer / product owner — measuring the framework:
python scripts/graph.py report prints a markdown table: rework rate, partial rate,
p50/p90 dispatch→PR latency, blocker frequency by area:* label.All three read every session file under .backlogd/graph/ and filter the edges. Full,
runnable versions (with the loader) live in
references/graph-queries.md — the sketches below show the
shape. Each treats both legacy solves edges and new dispatch_completed edges as
evidence that a session worked on a problem.
Sessions that solved the problem → the modules those sessions touches.
problem = "problem:linear:NB-241"
solve_like = {"solves", "dispatch_completed"}
sessions = {e["src"] for e in edges if e["type"] in solve_like and e["tgt"] == problem}
files = sorted({e["tgt"] for e in edges if e["type"] == "touches" and e["src"] in sessions})
Sessions that touches the file → the problems those sessions solved.
module = "module:scripts/graph.py"
solve_like = {"solves", "dispatch_completed"}
sessions = {e["src"] for e in edges if e["type"] == "touches" and e["tgt"] == module}
problems = sorted({e["tgt"] for e in edges if e["type"] in solve_like and e["src"] in sessions})
Build each problem's touch-set (the union of files its sessions touched), then rank other problems by overlap with the target's set (shared count / Jaccard). See the reference for the full ranking recipe.
Note. The three lookups above rely on
touchesedges, which are no longer emitted on new runs. They keep working against historical data; on a fresh graph they'll return nothing. The primary signal of the graph is now the agent-execution edges — query them viagraph.py reportor the recipes inreferences/graph-queries.md.
.backlogd/graph/. If you think an edge is
missing, that's a gap in the orchestrator's emission step (see skills/solve/), not
something to patch here.NB-N a lookup returns and reading it in Linear separately — keep the graph
query itself offline.problem:linear:NB-N, module:<path>, session:<id>) — see references/graph-schema.md.