arthur-debert

Drive a PR to ready-for-human-merge in any repo managed by `arthur-debert/release`. The loop is state-machine-driven: `release-core pr status` reports one lifecycle state plus the single next action; do that action, re-read, repeat — open as a draft, request…

Escalate infrastructure friction (workflow failures, ruleset misbehaviors, broken policy templates, helper-script bugs) from a consumer repo to the `arthur-debert/release` repo. Files a GitHub issue at release with auto-collected reproduction context (repo,…

Measure whether automated PR reviews (Copilot / Gemini / CodeRabbit) actually earn their cost on a given repo, so review policy is set by evidence instead of gut. Runs a repo-agnostic pipeline over the repo's own merged-PR history: a cheap mechanical tier…

Drive and diagnose release→consumer fleet changes from inside arthur-debert/release: shipping a fix to the fleet (verify → canary run → cut — the cut refuses without green canary statuses on HEAD, auto-advances the major; consumers pull it), migrating/seeding…

Reliable, fast E2E tests for Electron desktop apps with Playwright. Prescribes one shared `window.__e2e` runtime contract and `E2E_*` env vars so every electron project's tests look the same. Use when: (1) Setting up or fixing E2E tests in an Electron app (2)…

Bring a GitHub repo up to the shared arthur-debert/* + lex-fmt/* release-loop setup: main-branch protection ruleset (PR required, linear history, required checks), per-stack policy files (CODEOWNERS, dependabot.yml, copilot-instructions.md,…

Bootstrap sibling lex-fmt repos into /tmp/lex-fmt/ for multi-repo agent tasks. Use when: (1) the task explicitly names a sibling lex-fmt repo by name (`comms`, `vscode`, `lexed`, `nvim`, `tree-sitter-lex`, `zed-lex`, `mkdocs-lex`) and the rooted repo is…

Drain the release fleet inbox: process the consumer-filed issues that arthur-debert/release accumulates from the escalation loop. Pull the prioritized cluster digest with `release-inbox`, decide what to fix now by recurrence + blast radius, drive each fix…

Implement one shipit task as a role-scoped implementer. Use when an agent is spawned to build a standalone issue or epic workstream: make the code/test change in its Tree, verify it, open a draft PR with context, run the PR engine once, then stop before…

Shepherd one shipit draft PR through review-addressing rounds. Use when an agent is assigned to a PR after it is open: read current review threads, address findings in severity order, fix or reply, resolve threads, verify, push the round, and park without…

Coordinate shipit's delegated dev cycle. Use when the top-level agent is orchestrating a standalone issue, epic, workstream set, or PR lifecycle: gather context, brief implementers and shepherds, drive the PR engine, wait, flip ready, and stop at the human…

Grilling session that challenges your plan against the existing domain model, sharpens terminology, and updates documentation (CONTEXT.md, ADRs) inline as decisions crystallise. Use when user wants to stress-test a plan against their project's language and…

Primer for writing correct Lex documents. Use when: (1) Writing or generating .lex content (2) Understanding Lex syntax (it is NOT Markdown) (3) Reviewing whether a .lex file is syntactically correct (4) Converting content to Lex format

Plan a new feature or epic from loose ideas through to issues. Drives ideation → overview checkpoint → Spec → ADRs → docs PR (Leg A), then epic decomposition → issues (Leg B). Use at the START of a feature/epic, before any code. NOT for single fixes — the…

Show the dev-cycle story of the current session — the flow view of spawn/review/planning milestones from shipit's durable log. Use when the user asks what happened this session, wants a session status, or asks about an epic's progress.

Turn the current conversation context into an authoritative feature Spec and write it to docs/spec/. Use when user wants to create the first planning artifact from ideation or a blessed overview, before the architectural grill (`/grill-me-with-docs`).

Split oversized source and test files into cohesive modules without changing behavior. Use when the user invokes /loc-refactor, asks for a periodic file split, wants rustloc-guided modularization, or needs large files made easier for humans and agents to…

Structure a project's documentation — README, architecture docs, component docs, specs — as why/what/how roles scaled to the project's actual size. Use when writing or reorganizing a README or doc set, when deciding whether a document should be split or…

Write descriptions, not meta-analysis. Use whenever producing prose a human or another agent will read later — design docs, specs and ADRs, PR descriptions and review replies, rustdoc and docstrings, GitHub issue comments, commit messages, plans, and status…

Replace vague mechanical-metaphor jargon — gate, leg, pin, load-bearing, wire up, plumb through, surface — with the concrete actor, mechanism, and consequence. Use this whenever writing prose that persists or reaches humans (commit messages, PR titles and…

Decide whether a feature's interface should land as its own workstream ahead of the implementation, and how to build one when it does. Use when slicing a spec into an epic and workstreams; whenever a decomposition introduces a new data model, schema, API, or…

Remove session sediment from anything persisted under source control — code comments, docstrings, prose docs, scripts, config — without changing executable behavior. Use when persisted text contains development history, provenance, dates, duplicated…

Explains the padz hybrid store architecture—files are truth, JSON metadata is a rebuildable cache. Covers self-healing reconciliation (orphans, zombies, staleness), the Backend+Store split for testability, and how to use MemBackend for unit tests. Use when…

Explains the Display Identifier system in padz—a dual-identifier approach that provides stable, user-friendly IDs (1, 2, p1, d1) while internally using UUIDs. Use when working on pad listing, selection, or any CLI command that references pads by ID. Critical…

Guide for customizing padz CLI output using templates and stylesheets. Use when working on padz rendering, modifying how pads are displayed, changing colors/styles, editing Jinja templates, or working with the outstanding crate integration. Covers the…

Guide for customizing padz CLI output: templates, styles, and rendering. Use when working on: (1) Modifying templates in crates/padz/src/cli/templates/, (2) Adding or changing styles in styles/default.yaml, (3) Debugging output with --output flag, (4) Adding…

Use padz to record, retrieve, and hand off notes and tasks across agent sessions. Trigger when: (1) the user asks to "save this as a note", "remember this for later", "turn this into a task / todo list"; (2) the agent needs to persist context across a…

Build, modify, review, or debug Rust CLI applications that use the Standout framework. Use for Standout handlers and state, app and command wiring, MiniJinja templates and CSS themes, output modes, testing with TestHarness, hooks, input chains, piping,…

Write or review documentation for the Standout Rust CLI framework. Use when authoring Standout guides or topics, choosing guide versus topic placement, maintaining canonical examples and the shared `tdoo` domain, or checking documentation structure,…

Author and sync dodot templates and secrets — render config that varies per host/OS, inject secret values or encrypt whole files, and reverse-merge deployed-side edits back to source. Use when the user wants a dotfile to vary between machines, references…

Manage dotfiles with dodot — deploy packs, check what's live, add or adopt config files, undo deployments. Use when the user wants to deploy/update their dotfiles, run dodot up/down/status, add a file to a pack, adopt an existing config file into dodot, check…

Quick, copyable path for adopting Clapfig 0.23 in a Rust CLI project. Use when: (1) Adding layered configuration (defaults, config file, env vars, CLI flags) to a clap-based Rust app (2) Wiring the `config gen|list|get|set|unset|schema` command family (3)…

shipit's verified knowledge of pixi — the provisioning/run substrate shipit is a thin layer over. Covers what pixi persists, its identifiers, its (near-absent) extension surface, and how shipit's spawn/Tree/eval machinery wires through it. Use when working…