Second tagged release of the BuildDown skills plugin. Five new skills, and a knowledge graph the suite can consult.
Knowledge graph
The suite gained a knowledge graph — a searchable record of past issues, pull requests, decisions, and the learnings previous planning and landing sessions produced. Three new skills manage it:
- bd-kg-create — builds a project's knowledge-graph repository from the base template, the first step before a graph can be bound or refreshed.
- bd-kg-refresh — re-runs the ingest and redeploys, since the redeploy is the refresh: there is no live reload.
- bd-kg-search — queries the graph directly through hybrid search, the fast way to ask what already exists without running a full planning or landing session.
Eleven of the thirteen skills now open with reconnaissance against the graph, so a session starts by finding what has already been decided rather than re-deriving it. The two that don't are the ones where it would make no sense: project setup runs before a graph is bound, and the diagnostics skill queries the orchestrator directly. Recon is advisory throughout — any failure produces one line and the session continues.
An orchestrator's OAuth-protected /mcp endpoint is the source of truth, with a local server available as an optional fallback during transition. Every query announces which target served it, on one line, every time, so the operator never has to wonder which graph answered. Capabilities only the orchestrator serves never fall back silently — they say so and skip. A project with no graph bound is unaffected: KG-aware steps inside other skills skip silently, while a skill invoked specifically for the graph says so and stops.
Recon also reports the graph's own age stamp, and when the graph is more than a day old it names what it is blind to — issues changed and pull requests merged since — rather than answering as if current.
New skills
- bd-high-plan — plans a capability at high altitude: a small set of simple, separately testable steps, decided one question at a time and captured as a single planning parent before any detailed decomposition.
- bd-system-questions — asks the orchestrator direct questions about the system. Why a ticket isn't running, whether a pipeline is stuck, overall health, the project list, the runner mode.
Planning rebuilt on a shared core
bd-build-up and bd-mega-build-up were rebuilt on shared foundations rather than maintaining parallel copies. The decomposition rubric, issue body template, tracker adapters, pipeline awareness, overlap scanning and writing rules now live in one place both skills cite, so a correction lands once instead of twice and the two cannot drift apart by omission. Adding support for a new tracker is now one file.
Landing and verification
An agent comment is now treated as a dispatch rather than prose. A readiness gate holds it until the pull request has registered and no run is active on its current head, restarts if the head moves while waiting, and posts once. If the agent replies that it has no record of the pull request, that is recognised as a registration race and the same instruction is reposted rather than the fix being dropped.
bd-smoke-jumper got stricter about evidence. A claim about version-control semantics now requires a live throwaway-repo fixture rather than a green unit suite, which asserts issued commands rather than git behaviour. A pull request whose deliverable is an artifact has that artifact actually built and run, and a data-serving artifact must be shown to serve rather than merely to boot.
Installation
install.sh now installs for Codex as well as Claude Code — --codex covers both the Codex App and the Codex CLI — at user or project scope, by symlink or copy. This is the direct install path; the plugin marketplace remains the other route.
Upgrading
Stable-channel installs receive this once the marketplace catalog is repointed to this tag. Installs pinned to the development ref track that branch and already have it.