@hecer/yoke 1.9.0 → 1.11.0

package/docs/launch-copy-2026-08-21.md

@@ -0,0 +1,193 @@
+# Yoke launch copy
+
+## 1. Show HN
+
+### Title
+
+Show HN: Yoke – gated coding-agent loops for Claude, Codex, and Gemini
+
+### URL
+
+https://github.com/HECer/yoke
+
+### First comment
+
+I built Yoke after seeing coding agents report that a task was finished when the repository told a different story: tests had not run, the working tree contained unrelated changes, or a later iteration had broken earlier work.
+
+Yoke is an MIT-licensed TypeScript CLI for running coding-agent work as a sequence of verifiable stories. It supports Claude Code, Codex CLI, and Gemini CLI.
+
+The runner, rather than the agent, decides whether a story passed. It checks the configured verification command's exit code, requires review approval, and confirms that the commit landed. Stories run in isolated Git worktrees. For visual acceptance criteria, a run can require Playwright screenshots or video as evidence.
+
+Yoke also generates native project instructions for each supported agent from one versioned skill canon. That part is Markdown. The state transitions, worktree lifecycle, process supervision, gates, and run state are executable TypeScript.
+
+The closest comparison I know is WorkOS Case. Both projects treat the harness as the reliability boundary. Case is focused on turning GitHub or Linear issues into reviewed pull requests. Yoke includes greenfield and retrofit setup, PRD-to-story execution, and portable project configuration across three coding agents.
+
+You can try it without an account:
+
+    npm install -g @hecer/yoke
+    yoke new my-app
+
+I am looking for two kinds of feedback:
+
+1. Which gate would you remove because it adds more process than safety?
+2. What failure from a real autonomous run would Yoke still miss?
+
+I am the maintainer and will be around to answer questions.
+
+## 2. DEV Community (`#showdev`)
+
+### Title
+
+I moved coding-agent verification out of the prompt
+
+### Tags
+
+`showdev`, `ai`, `opensource`, `typescript`
+
+### Article
+
+A coding agent can agree to run the tests and still fail to run them. It can also run the wrong command, overlook a dirty working tree, or declare success before the result is committed.
+
+Adding another sentence to the prompt does not change who controls the completion decision. The same model doing the work still decides whether it followed the instruction.
+
+I built Yoke to put that decision in a TypeScript runner.
+
+Yoke executes work as a sequence of stories. For each story, the runner creates an isolated Git worktree, starts a fresh agent session, runs the configured verification command, requests a separate review, and checks that the resulting commit landed. A story is not marked as passed because the agent says it is done.
+
+For user-interface work, the acceptance criteria can require Playwright screenshots or video. The evidence belongs to the story instead of living in a chat transcript.
+
+Yoke supports Claude Code, Codex CLI, and Gemini CLI. A versioned canon generates the native instructions each agent expects, so a project can keep one methodology without pretending that all three tools use identical configuration formats.
+
+Some of Yoke is Markdown. The skills, policies, and project context should be readable and editable. The enforcement layer is code: process supervision, worktree isolation, persisted run state, verification exit codes, review gates, and commit checks.
+
+The closest existing project is WorkOS Case. Case uses a deterministic TypeScript pipeline to turn issues into reviewed pull requests with evidence. Yoke covers a somewhat different workflow: creating or retrofitting a project, converting a PRD into ordered stories, and running those stories across Claude, Codex, or Gemini. The projects share more philosophy than I realized when I first described Yoke, and I now call that out directly.
+
+Yoke is MIT-licensed and does not require an account.
+
+    npm install -g @hecer/yoke
+    yoke new my-app
+
+Repository: https://github.com/HECer/yoke
+
+I would value examples of failures that prompts and skills do not handle reliably. I am also interested in the opposite feedback: which Yoke gate feels unnecessary in normal development?
+
+Disclosure: I used AI assistance while drafting and editing this article. The product description and technical claims were checked against the repository by the maintainer.
+
+## 3. DevHunt
+
+### Name
+
+Yoke
+
+### Tagline
+
+Run coding agents with tests, review, and commit gates outside the model.
+
+### Short description
+
+Yoke is an MIT-licensed TypeScript CLI for autonomous coding loops with Claude Code, Codex CLI, and Gemini CLI. It runs stories in isolated Git worktrees and only records a pass after the configured verification command succeeds, review approves the change, and the commit lands. Visual stories can require Playwright screenshot or video evidence.
+
+### Maker comment
+
+I built Yoke because instructions such as “run the tests before finishing” leave the completion decision with the same agent doing the work. Yoke moves that decision into an executable runner.
+
+I would like feedback from developers who already run agents unattended: which gate earns its cost, and what would prevent you from using Yoke on an existing repository?
+
+Source: https://github.com/HECer/yoke
+
+## 4. Uneed
+
+### Title
+
+Yoke
+
+### Tagline
+
+A safety-gated coding harness for Claude, Codex, and Gemini.
+
+### Description
+
+Yoke runs autonomous coding work as verifiable stories. Each story gets an isolated Git worktree and must pass the project's real verification command, an independent review, and a commit check. User-interface stories can also require Playwright screenshots or video.
+
+The CLI can create a new project or retrofit an existing one. It generates native instructions for Claude Code, Codex CLI, and Gemini CLI from one versioned canon.
+
+Yoke is open source under the MIT license and requires no account.
+
+### Launch comment
+
+I am the maintainer. I am looking for concrete failure cases from people who use coding agents for long or unattended runs. If Yoke would not catch one of yours, please tell me what happened.
+
+https://github.com/HECer/yoke
+
+## 5. Product Hunt
+
+### Name
+
+Yoke
+
+### Tagline
+
+Mechanical safety gates for autonomous coding agents
+
+### Description
+
+Run Claude Code, Codex CLI, or Gemini CLI through isolated worktrees, real test commands, independent review, commit checks, and optional visual evidence. Open source and local-first.
+
+### First maker comment
+
+Hi Product Hunt,
+
+I built Yoke for developers who let coding agents work through more than one task at a time.
+
+The failure I wanted to address was straightforward: an agent could say that tests passed without giving the repository a reliable completion boundary. Yoke makes the runner responsible for that boundary. A story passes only after the configured verification command exits successfully, review approves the change, and the commit lands.
+
+Yoke supports Claude Code, Codex CLI, and Gemini CLI. It can bootstrap a new project or retrofit an existing repository, and it keeps stories isolated in Git worktrees.
+
+The project is MIT-licensed, runs locally, and requires no account:
+
+https://github.com/HECer/yoke
+
+I would appreciate feedback from anyone already running coding agents unattended. What evidence do you need before trusting the result?
+
+## 6. Peerlist Launchpad
+
+### Project summary
+
+Yoke is an open-source TypeScript CLI for running Claude Code, Codex CLI, and Gemini CLI with completion gates outside the model.
+
+It breaks a PRD into stories, runs each story in an isolated Git worktree, and checks the project's verification command, review result, and final commit before recording a pass. Visual acceptance criteria can require Playwright screenshots or video.
+
+I built it after finding that prompt-level instructions were useful guidance but a weak enforcement boundary for unattended work. The readable methodology lives in versioned Markdown; the enforcement lives in the runner.
+
+Try it:
+
+    npm install -g @hecer/yoke
+    yoke new my-app
+
+Source: https://github.com/HECer/yoke
+
+I am looking for developers willing to try it on an existing repository and report the first confusing or unnecessary step.
+
+## 7. Indie Hackers
+
+### Title
+
+I built a coding-agent harness, then learned that “it is just Markdown” was the right criticism to answer
+
+### Post
+
+I recently shared Yoke, an open-source harness for autonomous coding agents, and received a blunt question: why not encode the workflow in one skill or even one sentence?
+
+That criticism exposed a problem in how I described the project. The interesting part is not the workflow advice. Agents can read instructions telling them to plan, test, review, and commit.
+
+The product decision is who controls the pass condition.
+
+Yoke puts that condition in a TypeScript runner. It creates isolated worktrees, executes the configured verification command, requests review, checks the commit, and persists story state. The agent produces the change, but it cannot mark its own story as passed merely by saying the work is complete.
+
+The skills and policies are Markdown because users should be able to read and change them. If someone only needs those instructions, a skill is enough and Yoke is unnecessary.
+
+I also learned that WorkOS Case already takes a closely related approach. Case focuses on moving an issue through a multi-agent pipeline into a reviewed pull request. Yoke focuses on creating or retrofitting projects, turning PRDs into stories, and running them across Claude Code, Codex CLI, or Gemini CLI. I now describe that overlap directly instead of pretending the category is empty.
+
+The project is MIT-licensed: https://github.com/HECer/yoke
+
+My question for other builders is about scope. Would you keep the product narrow around enforced story completion, or is cross-agent project setup a meaningful part of the value?