Internal preview · v0.1.0 · not yet installable
factory-kit runs opted-in GitHub issues through your local Hermes agents, an independent review, your CI and a live preview. Then it asks you to approve one exact commit, and it merges only that commit.
9f2c4e1main @ 41d07aaCoding agents can draft a fix in minutes. Then you spend the rest of the hour working out what actually ran.
You re-run CI you already paid for, because the evidence never names a revision.
PRs arrive claiming success, and each one needs a full manual audit.
Give an agent the merge button and one bad run becomes a revert on main.
Label a GitHub issue factory-kit. It needs acceptance criteria, and nothing written in the issue can widen what the agents may do.
A Hermes worker implements the issue in an isolated git worktree. A separate reviewer session checks the diff against the criteria. One fix round is allowed.
factory-kit opens a PR for the reviewed commit, waits for your required checks on that exact head, publishes a preview of it and smoke-tests the URL.
You approve that commit. factory-kit rechecks head, base, checks and preview, squash-merges with an expected-head guard, and reports the merge SHA that GitHub recorded.
factory-kit is a thin layer over tools you already run. Hermes Kanban schedules the work, IDD skills do the engineering and GitHub stays the source of truth. factory-kit adds the checks between them.
A separate reviewer session records its verdict against the exact commit, and your CI has to pass on that same head.
factory-kit publishes that exact commit as a preview on GitHub Pages or Vercel and smoke-tests the URL before it asks you anything.
Your approval covers one head, one base and one preview for 60 minutes. A new push cancels it.
Durable state and GitHub reconciliation resume work after a crash without opening a second PR.
The request you approve names its head commit, the reviewer's verdict, the check runs and the preview URL. If any of them change, factory-kit asks you again.
factory-setup plan only reads your repository. apply writes the exact bytes you accepted, and nothing else.
An old Hermes, a signed-out model or an unprotected main branch each stop dispatch with a named code.
Autonomous merge, production deploys and package publishing are off, and the manifest has no key that turns them on.
One active issue, two implementation attempts and 60 worker minutes per issue, unless you change them within fixed bounds.
Uninstall deletes only the files factory-kit created and still owns. Your edits stay where they are.
Kanban workers
issue-resolver, issue-pr-review
checks, branch protection, Pages previews
alternative preview host
status and control
factory-kit 0.1.0 is an internal preview. Its v1.0 evidence gate is still open: a few live checks must pass before a release, and there is no public install yet.
This page is the first real project it shipped. Each section started as a GitHub issue and went through the full pipeline: implementation, independent review, CI, a preview and a human approval.
Browse the merged pull requestsNot yet. factory-kit is an internal preview while its v1.0 gate closes. Follow the build on GitHub to hear when that changes.
Hermes Kanban profile workers, with the model you pin for each role. The tested setup uses openai-codex/gpt-6-luna for both implementation and review.
No. Your required checks and branch protection decide. factory-kit reads them and refuses to dispatch when the main branch is unprotected.
No. Each merge needs a human approval for one specific commit, and approvals expire after 60 minutes.
State lives in SQLite. On restart, factory-kit resumes, parks or quarantines each task, and checks GitHub before it repeats any remote action.
In Telegram from an allowlisted account, or from the local operator CLI. The merges for this site were approved from the CLI.