devbook plugins

by Job Schepers

The unattended lane, stacked on delivery: the eleven schedule-* skills that run with nobody watching, plus install, plus the catalog of triggers that fires them. Nine schedulable entry points that pick their own input and run a flow or a review — bug fix, merge review, package update, performance review, review, security review, week starter, weekly cost analysis, and what's new — and six trigger definitions naming a target, a cadence, the plugins that target needs, and the prompt for a cloud session that starts with nothing but the repository. delivery-schedule:install creates or updates them through whatever scheduler the live session exposes and records the selection under components.schedule; schedule-status reads their runs and logs; schedule-run fires one now. One capability, two host names: Routines in Claude Code, Automations in the GitHub Copilot app. Depends on delivery and names devbook: a trigger whose target is not enabled is reported and skipped, never scheduled.

by Job Schepers

The devbook convention: .arc42, .domain, .tech, .design, and .ai folders of addressed Markdown chapters, each carrying a parseable meta block with status ladders, a shared approved rung, runnable test-case links, an opaque ext namespace a layered plugin keeps its own state in, and annotation fences that keep a review note in the chapter beside the passage it is about, compiled into derived _meta indexes and a reference-graph canvas. Ships bidirectional to-spec-<kind> and from-spec-<kind> converters between chapters and code, a versioned contract with runnable migrations, and enforcement tooling. Ships the shape and the check, never a flow: the delivery engine carries a chapter change and reads these rules from the repository.

by Job Schepers

Review, comment, and hand-off workflows over devbook chapters. Requests a review and hands a chapter to a named reviewer, reviews one against its folder's rules and its evidence, records each finding as a devbook annotation fence beside the passage it is about, runs the approval decision that writes devbook's own approved rung, and sweeps the adopted folders for what is awaiting whom and which approvals have gone stale. An L1 extension: the state it remembers is three ext.devbook-collaboration keys in the chapter's own meta block, so it adds no field to devbook's schema and needs no devbook release of its own. Ships devbook-collaboration:install, which puts its one rule in the repository so both hosts apply it on a matching read.

by Job Schepers

Owns a repository's .devbook/config.json and explains the stack that reads it. `setup` writes the engine-owned keys — bindings, extensions, policy, gates — before anything is installed, then hands every component its own install skill; `update` moves the whole configured stack forward in one run, fanning out to every adopted component’s own install skill and skipping what this machine has not installed or this checkout has not enabled, migrations included; `guide` answers a question about this marketplace from what is on disk — what devbook, the delivery engine, the bridges, the surfaces, and the fan-out lane are and how they fit, which version of each plugin is installed against the newest published, and which are enabled; `adoption` reports where the .ai adoption record no longer matches what is installed and hands the write to flow-ai. All four are backed by a read-only report that names the file behind every fact. Declares no dependency, devbook included: it is named for the folder it writes into, not for a plugin it needs, and one it names but cannot find is reported as not installed.