Changelog

Everything we’ve shipped, newest first.

  1. Command line

    Spare Parts CLI0.2.0

    Engineering context joins the Spare Parts CLI, with Spec Kit commands, shared .sp workspaces, huddles, and project synchronization.

    sp ec

    sp ec install adds engineering-context commands to a repository for the coding agents already in use there. It can detect one agent, target one by name, or install commands for every supported agent:

    sp ec install
    sp ec install --agent claude
    sp ec install --all
    sp ec install --dir path/to/repo

    The installed workflow follows Spec Kit's specification, planning, task, and implementation structure while keeping /huddle as the cross-repository coordination command.

    One .sp workspace

    Generated context now lives under .sp/, replacing the earlier .blitz/ layout. Each repository keeps its own specs and command state. When installation targets a directory containing several repositories, the workspace root also gets a shared constitution and huddle store without receiving a pooled repository scaffold.

    The installer carries over the existing ignore behavior: generated .sp state and templates are ignored, while .sp/memory/constitution.md remains trackable. Existing blanket .sp/ ignore rules are preserved and reported rather than silently rewritten.

    Huddles and GitHub Projects

    A workspace can use a GitHub Project as its huddle store. Configuration and manual synchronization are available from the command line:

    sp ec project configure https://github.com/orgs/example/projects/1 --dir ..
    sp ec project status --dir ..
    sp ec project sync ../.sp/huddles/001-example/huddle.md --dry-run
    sp ec project sync ../.sp/huddles/001-example/huddle.md

    /huddle prefers installed GitHub MCP tools that can manage Projects and falls back to gh project through the CLI. Every synchronized draft item carries a stable huddle-path marker, so another sync updates the same item instead of creating a duplicate. The Markdown document remains authoritative if remote synchronization is unavailable.

    Guided setup

    Two commands make integration requirements visible before a huddle needs them:

    sp ec doctor
    sp ec project setup

    They report the configured huddle store, GitHub CLI authentication, and visible Linear MCP or API configuration. Missing capabilities include the next command or configuration step needed to enable them. GitHub Projects is fully synchronized in this release; Linear setup and detection establish the path for its work-management integration.

    Install

    brew upgrade sparepartslabs/tap/spareparts-cli
    pip install --upgrade spareparts-cli

    See the Spare Parts CLI documentation for installation options and the complete sp ec workflow.

    Spare Parts CLI docs
  2. Command line

    Spare Parts CLI0.1.0

    The first release. The sp command line, with sp lgtm as its first module, on PyPI and the Homebrew tap.

    sp is the Spare Parts command line. Modules are imported lazily, so the module named on the command line is the only one loaded: running one never pays for another's imports, and one with a broken dependency cannot take the rest of the command line down with it.

    sp lgtm

    Generates a few multiple-choice questions about a range of commits and asks them in your terminal, before the code leaves your machine.

    sp lgtm                       # what this branch adds since it left main
    sp lgtm main...feature/x      # someone else's branch, before you merge it
    sp lgtm --staged              # what is staged
    sp lgtm --dry-run             # what it would ask about, no model call

    Press ? on any question to print the hunk it came from. Wrong answers are never a failure: you are told which files to look at again, and it re-asks as many times as you like.

    It reads .github/lgtm.yml, the same file the GitHub Action reads, so a repository is configured once. Fields that only mean something to the Action are accepted and ignored.

    As a git hook

    sp lgtm install                       # pre-push, advisory
    sp lgtm install --hook pre-commit     # earlier, and once per commit
    sp lgtm install --blocking            # wrong answers stop the push

    pre-push is the default, and advisory is the default. A hook that costs a minute and can stop you is one you delete within a week. Even with --blocking, only a wrong answer blocks: could-not-ask, meaning no API key, a vendor outage, or nothing quizzable, never costs you a push.

    The hook quizzes exactly what you are about to push, reading the ref range git puts on stdin, and falls back to what the branch adds since it left the default branch when the remote has never seen it. It skips itself silently where there is no terminal, such as a rebase, a GUI client, or CI. sp lgtm install honours core.hooksPath and refuses to overwrite a hook it did not write.

    Vendors

    No vendor is the assumed one. On pip each SDK is an extra, so you install the client for the vendor you actually call and nothing else.

    Vendor Extra Key Default model
    anthropic [anthropic] ANTHROPIC_API_KEY claude-opus-5
    openai [openai] OPENAI_API_KEY gpt-5.5
    gemini [gemini] GEMINI_API_KEY or GOOGLE_API_KEY gemini-pro-latest

    Name no vendor and sp uses whichever key is set. The defaults were chosen by listing each vendor's models against a live key rather than from memory.

    Split the proposer and the verifier across two vendors if you have the keys for it. A model asked to find fault with its own reasoning mostly does not, so this is the strongest arrangement available, and it costs one extra vendor's tokens and almost no extra wall clock:

    sp lgtm --provider anthropic --verifier openai

    Install

    brew install sparepartslabs/tap/spareparts-cli
    pip install "spareparts-cli[anthropic]"     # or [openai], [gemini], [all]

    The Homebrew formula carries all three vendors and brings its own Python rather than touching the one you develop against. Dependencies are otherwise thin on purpose: everything the terminal rendering needs is in the standard library.

    Exit codes

    Code Meaning
    0 Confirmed
    1 Not confirmed, meaning wrong answers or you quit
    2 Could not ask, meaning no API key, git failed, or nothing quizzable

    Treat only 1 as a failure. A tool that cannot run must not block a commit.

    Spare Parts CLI docs
  3. GitHub Action

    LGTM1.0.1

    The Marketplace listing is now named Spare Parts LGTM.

    Fixed

    • The action published as LGTM, a name generic enough to be hard to find and easy to mistake for someone else's. It is Spare Parts LGTM now.

    Listing metadata only, with no change to behaviour, inputs or outputs. Workflows pinned to sparepartslabs/spareparts-lgtm@v1 already point at it.

    LGTM docs
  4. GitHub Action

    LGTM1.0.0

    The first release. LGTM runs as a GitHub Action anyone can install, on any of three model vendors.

    LGTM asks the reviewer two or three questions about the pull request they just approved, generated from the diff and reported as a check run. It has no opinion on whether the change is good, only on whether anyone read it.

    The shape it ships in

    Two workflow files and two secrets. There is no server to run, no database to provision, and no checkout: the diff and the configuration are both read through the API. Quiz state lives in the comment and the check run, configuration in .github/lgtm.yml.

    The install is split in half on purpose. lgtm-collect.yml listens for pull_request_review with permissions: {} and does nothing but write the event to an artifact, because that event carries no secrets on a pull request from a fork. lgtm.yml is the privileged half and picks the relayed event up through workflow_run, treating the artifact as untrusted.

    Questions

    Three stages run on the diff, after a file screen that makes the common skip cost nothing.

    • Propose. One call writes candidates about what the change does: what a new guard prevents, which edit touches existing rows, what an error path now returns.
    • Verify. An independent call that never saw the proposer's reasoning is told to refute each candidate. It survives only if that call agrees the answer is right and that someone who skipped the diff could not guess it.
    • Ground. The cited file and hunk are checked against the parsed diff in code, and the options are checked for structural tells.

    Everything is conservative in one direction. A quiz with no survivors is not posted and the check concludes neutral. The answer key is never published: the comment carries a keyed hash per correct option, so an edited quiz is reissued rather than graded.

    Asking a question back

    Mention @lgtm at the start of a line to get background questions answered, with web search where a source helps. Questions that ask LGTM to read the pull request for you are declined, and you get a pointer at which file answers it instead. Write access only, rate limited per asker per pull request, and answerQuestions: false turns it off.

    Vendors

    Anthropic, OpenAI and Gemini, behind one provider seam, and any of the three can run the web search. Each repository supplies its own model key, so adoption costs the adopter.

    Enforcing

    Off by default. enforce: true in .github/lgtm.yml holds a merge until the quiz is answered. LGTM can never mark a review as failed, and unlimited attempts are the point rather than a concession.

    LGTM docs