jsdotnet

by Job Schepers

The host-neutral delivery engine: 16 flow-* staged procedures, five of them one per devbook folder, 3 shared phases, and the pull-request lane, sequenced by the flow-runner agent through a closed set of extension points — spec, implement, verify, app.start, qa.run and deliver as services, session.start, flow.start, data.prepare, docs.update and flow.end as chores — with human gates a repository adds but never removes, and a run surface resolved from the live tool list so none is a normal outcome. Bindings, extensions, policy, and gates are declared per repository in .devbook/config.json.

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

A headless run surface: where a run becomes recorded rather than watched. An MCP server implementing two surface capability groups — lifecycle (open_dashboard, start_run, record_prompt, set_run_context, update_stage, finish_run, list_runs, get_run) and export (export_report) — keeping stage status, output, gate decisions, QA scenarios and the handoff marker on disk so a resumed session picks the run up where it stopped, and writing the run's Markdown report at the end. No page, no port, nothing rendered: the right surface for scheduled and unattended runs. Declares no dependency and names no engine.

by Job Schepers

A run surface: the live dashboard a run is watched in. An MCP server implementing all three surface capability groups — lifecycle (open_dashboard, start_run, record_prompt, set_run_context, update_stage, finish_run, list_runs, get_run), render (render_diagram, render_markdown), and export (export_report) — with a run timeline carrying stage output, QA scenarios and their evidence, a Mermaid diagram viewer and a Markdown document viewer, and hook-captured tool and token telemetry. Rendered inline as an MCP App where the host supports it, served on 127.0.0.1 where it does not. Declares no dependency and names no engine.

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.

by Job Schepers

The fan-out lane: a backlog turned into parallel work across sessions and worktrees — the one thing a flow may never do. fleet-issue-sweep triages a repository's open issues for relevance and for collision with work in flight, proposes the stale ones for closure, and dispatches up to five independent worker sessions, one issue and one worktree each, then waits them out and writes the brief. fleet-resolve-issue is what each worker runs: one issue to a pull request when the change proves itself, or to a parked worktree with a handoff brief when a human has to look. fleet-morning-brief re-reads a past sweep from its manifest and worker result files. An L1 extension over delivery: it owns no flow and holds no gate, and trades Personal Validation for a pull request nobody merges unread.