harness

I built Harness to keep my coding workflow consistent across projects. It packages the skills and review workflows I use every day, plus Factory, a durable path from a work item to a reviewed pull request.

Factory handles triage, planning, implementation, and review one step at a time. It records each result, pauses when I need to make a decision, and only publishes the exact commit that passed review. It never merges the pull request.

Check the code on GitHub

How it fits together

• Factory. The full path from a work item to a reviewed pull request. It starts from a Linear issue or a local item, routes the work through planning or straight to implementation, runs reviews, and can publish the exact commit that passed. Each run handles at most one pending step and exits.
• Reviews. change-review and plan-review also run on their own. They use separate reviewer roles and leave structured findings and artifacts in the target repo.
• Skills. Reusable building blocks in the Agent Skills format for planning, diagnosis, handoffs, reviews, and other repeatable work. Some include their own scripts, like the sessions CLI for searching past work.
• Providers and runner. Cursor and Codex sit behind the same workflows. The CLI handles repo settings and runs the work. Standalone reviews write to .harness/runs/; Factory keeps its state and evidence in a separate durable store.

How I use it

For a small change, I run change-review before I open or merge a pull request. It runs implementation and code-quality reviewers against the same diff. I fix what matters and run it again.

For larger work, I start with a Linear issue. Factory carries the same work item through triage, planning, implementation, and review. If a review needs changes, it stops and asks me to revise the work or review the same candidate again. Once the candidate passes, I tell Factory to publish the pull request. I still merge it myself.