Switch this server to another git worktree of the same repository, for the rest of this session: every later call reads and writes that checkout. Call it right after creating the worktree you will implement in, so initiative edits land in that branch's commit. With no path (or the original checkout's path), switch back — do that after merging, before removing the worktree. Returns the checkout now in use.

Mark a folder as a collection: adds brindley: 1 and the given details to its README.md front-matter, creating the folder and README if needed. Works on a folder that already holds numbered initiative files. The first collection in a repo also returns the agent-instructions snippet for AGENTS.md / CLAUDE.md.

Edit a collection README's details, including its status (active | done | abandoned).

The Brindley server's version (computed from git tags + Conventional Commits) and build commit.

Add or remove a collection's ignore: patterns — numbered files that are not initiatives (companion notes, reviews). .gitignore semantics, relative to the collection folder: # comments, ! re-includes, leading / anchors, trailing / = folder, no / = any depth. Use dry_run to preview which files a change would ignore. Ignored numbers are still never reused.

Every collection with its details, counts by initiative status, and number ready.

Every front-matter field an initiative (ticket/issue) can have in a collection, and the values each accepts: statuses and their aliases, types, tags, scoring dimensions (in ranking order, with any default and whether required), and the free-text fields — with the tool that sets each. Give a collection or an initiative ref; with neither, every collection.

List initiatives (a.k.a. tickets or issues) across the repo, or in one collection, optionally filtered.

Full detail of one initiative (ticket/issue), including its dependency report (each dependency classified satisfied / blocking / external / missing), dependants, open questions and acceptance criteria.

Initiatives (tickets/issues) that are designed with nothing blocking — what an agent can pick up now — in suggested order (prerequisites first).

Write a one-page progress report for people outside the team — a self-contained HTML file (default build/brindley-report.html) — from the collections and their git history: headline figures, work complete against scope over time, what was delivered, added and taken out this period, workstreams, and what needs attention. Returns the file's path and the figures. Changes no initiative.

Dependency graph as an adjacency list plus Mermaid: a collection's active work, one initiative's neighbourhood, or a tag (theme) across collections.

Unresolved open questions, grouped by initiative. Abandoned and superseded initiatives are left out — dropping the work settles them — unless asked for by ref.

The next unresolved blocking question in one initiative (the first labelled after after, if given), with its label (id) and the count remaining. Drives the design-review conversation.

Every tag in use plus declared-but-unused ones, with descriptions, counts by status, and the theme overview doc if one exists (a doc whose front-matter says theme: <tag>).

Every milestone (a doc with milestone: <slug> front-matter) and where it stands: reached, not reached or unspecified; done against counted members; what is still to do (initiatives and included milestones); unconfirmed external members; and when it was reached, from git history. Give milestone (a slug) for just one, with its members.

Is this initiative (ticket/issue) complete and ready to work on? Runs the preflight the implement and spike briefs start with: status, dependencies, blocking open questions, acceptance criteria (or ## Measures for a spike), validation errors. ready: false means stop and report, don't start.

Check initiatives and collection structure: missing or unknown statuses, status vs folder vs body-prose disagreements, files not in their collection's status folder, duplicate numbers, dangling references, cycles, broken links (with where a moved file now lives), stale READMEs. Returns errors and warnings with file and line.

Lint project docs for history phrasing, design debate and links into initiatives (docs must describe only what the code is). Defaults to docs changed vs HEAD.

Create a new initiative (ticket/issue). The number is coined automatically by scanning the working tree, other worktrees, branches and history. A folder path that isn't a collection yet is marked as one. A milestone this reaches, or stops being reached, is reported under milestones.

Edit an initiative's (ticket's/issue's) front-matter fields or H1, or replace a named body section — including on a done initiative, which is how settled work is refined (no status change needed). status records the status an initiative already has when its front-matter has none (no lifecycle checks); to change a recorded status, use set_status. Cannot change its number or filename. A milestone this reaches, or stops being reached, is reported under milestones.

Repair the validate findings that have one obvious fix, editing text in place (never renaming or moving a file): a broken link whose filename matches exactly one initiative in its collection, depends_on / related front-matter (turned into links under ## Dependencies / ## Related), and open questions without a label (given the labels they are reported with). Anything ambiguous is listed in unfixed. Dry run by default: returns each edit (file, line, before, after); pass dry_run: false to write. Padding is fixed by repad, numbers by renumber.

Move a collection to a new folder, rewriting every relative link into it from anywhere in the repo and out of it from inside. If its name comes from its folder (no name: in its README), the name changes too and "#" references by the old name, path or automatic alias are rewritten; explicit aliases are kept. Refuses a destination that exists or is inside another collection, and a new name another collection uses. dry_run: true returns the plan.

Give an initiative a new number — fixing a number collision after a merge. Renames its file and asset folder (keeping the slug, padded to the collection's width) and rewrites every link and "#" reference to it across the repo. to defaults to the next number, coined as create does. For one file of a duplicate-number pair, pass ref as its path. dry_run: true returns the plan without writing.

For a collection that declares folders: (status → folder), move every initiative to where its status belongs — its folder, or the top of the collection — with its asset folder, rewriting every link to them. Dry run by default: returns each move and link rewrite; pass dry_run: false to apply. Status changes keep things in step after that; tidy is for files already out of place.

Pad every initiative number in a collection to one width (01-, 001-) — the given width, or the width most of its files use — renaming the files and their asset folders and rewriting every link to them across the repo. Dry run by default: returns each rename and link rewrite; pass dry_run: false to apply. Refuses a width too small for the highest number.

Apply update-style changes to many initiatives (tickets/issues) in one call — e.g. recording statuses across an adopted folder. Each entry is a ref plus any of status, reason, type, owner, tags, status_note, docs, dimensions; status: "from-text" takes the status from the initiative's Status: line or ## Status section. Every entry is checked first: if any fails, nothing is written and every failure is returned. dry_run: true shows what each file would get. A milestone this reaches, or stops being reached, is reported under milestones.

Change an initiative's (ticket's/issue's) status, enforcing the lifecycle: designed needs no blocking open questions; in-progress needs ready; done goes through complete. Abandoning needs a reason; abandoned, superseded and deferred work gets a callout under its title saying so, which is removed when it is reopened. A milestone this reaches, or stops being reached, is reported under milestones.

Add an open question — one decision per question: pose several as separate questions (warns when the text looks like more than one). It is labelled with the next free label (returned as id); don't write one yourself. A blocking question moves a designed initiative back to draft. Use implementation=true for questions deliberately left to the implementer.

Split an open question that poses several decisions into one question per decision, in its place and order, in one write. Each part is text or { text, implementation?, answer? }: parts inherit the question's (implementation) marker unless they set their own, and a part with an answer is settled as it is written — recorded in record_in (default "Decisions"), or kept ticked with mode "tick", as resolve_question does. Parts are labelled under the question's label (Q3 → Q3.1, Q3.2), and Q3 stops existing. Returns the parts left open with their labels.

Resolve an open question, named by its label (id, e.g. "Q3") or match. Default mode "remove": delete it and record the decision under its label in record_in (default "Decisions", e.g. "Agreed direction"). Mode "tick": keep it as "- [x] Q3 … — answer".

Add or remove dependency links. Dependencies are the links under an initiative's ## Dependencies heading (blocking); ## Related links are non-blocking. Adds a bullet with a relative link (and optional why); removes the bullet(s) linking to the target — bullets only: a link inside a paragraph is left in place and reported with its line, to edit by hand. Refuses unknown initiatives and cycles.

Mark an initiative (ticket/issue) done — "close" it. docs_impact is required: the project doc paths updated in this change, or "none: ". Reports which initiatives became ready, and any milestone it reaches (milestones).

Rebuild the generated README blocks (tables + Mermaid). check=true only reports what is stale (for CI).

The brief for one of Brindley's workflows — the text of the prompt of the same name, for agents and skills that cannot fetch MCP prompts: design-review (work through an initiative's open questions with the user), implement (hand-off brief for implementing one initiative), spike (build and measure a spike) or triage (review the initiatives). ref is required except for triage, which takes an optional collection. Follow the brief it returns.