DEV Community: FlowSkill

FlowSkill launches on Product Hunt — November 3

FlowSkill — Wed, 28 Oct 2026 04:45:15 +0000

Tagline: Stop your AI agent from faking 'done'

I have watched an AI coding agent finish a task, report it as done, and leave behind code that did not actually do what was asked. The report looked confident. The work was not finished. That gap — between a claim of "done" and work that holds up — is what FlowSkill exists to close.

What FlowSkill is

FlowSkill is an open-source gated build harness for AI coding agents. It wraps your agent in a six-gate pipeline. Every stage must pass before work advances — and a kill is a valid outcome. If a stage cannot pass, the work stops there instead of moving on with a polished-looking result.

Two kinds of gate do the checking:

A mechanical gate (flow.sh) — checks that can be run and verified, not just asserted.
A semantic gate (SKILL.md) — checks whether the work actually matches what was asked.

Either gate can stop the pipeline. That is the point: a stage that fails should fail loudly, early, rather than surfacing later as a bug someone else has to untangle.

Receipts, not claims

FlowSkill produces receipts: a record of what passed, what failed, and what was killed, so you can inspect the run instead of taking the agent's word for it. You can see the receipts approach on the project site at https://flowskill.io.vn, along with a 75-second demo.

What it works with

Per the launch description, FlowSkill offers one-command install and works with Claude Code, Codex, and Cursor.

What it does not promise

A gate can only check what it is built to check. FlowSkill does not guarantee that gated work is correct in every sense, and it does not replace reading the code, running it yourself, or reviewing what an agent produced. A passing gate means the stage met its checks — nothing more. If you try it and a gate blocks work you believe is fine, that friction is part of the design, and it is worth reporting as an issue so the checks can improve.

FlowSkill is version 1.0.0. The repository is public at https://github.com/manhquydev/flow-skill — you can read the code, the gates, and the receipts format before deciding whether it fits how you work.

Launch day — November 3

FlowSkill launches on Product Hunt on Tuesday, November 3. If you have ever been burned by a confident "done" that was not done, I would like to hear about it: what is the worst "done" your agent ever faked?

You can follow the project on dev.to at @flowskill, and find the launch on Product Hunt on November 3. Feedback — especially cases where a gate got it wrong — is welcome.

21 harnesses, one hole

FlowSkill — Sun, 25 Oct 2026 03:31:25 +0000

I read the intake evaluations for 21 agent harnesses. All of them solve the same problem: running an agent. None of them solve the problem of verifying one.

That is the hole. Every harness on the market can launch a loop, fetch context, and emit code. None of them define "done" as something you can check. The survey that collected these 21 candidates is blunt about it: support must be mechanical, or it is theater.

The 21, in three tiers

The survey sorts the candidates by how Flow's discipline layer would actually integrate with them — not by marketing claims, but by mechanism. Four criteria from the qualification SOP drive the tiers: mechanical enforcement (does the host honor a gate?), context hygiene (does the context arrive intact?), runtime portability (does the runner work there?), and shell awareness (can the agent parse an exit code?).

Tier 1 — Native fit (3): Cursor (~/.cursor/skills), Zed Agent (~/.agents/skills), Trae (Dual A/B). The host already has a skills directory. The runner drops in. Friction is low.

Tier 2 — Project rule fit (16): Roo Code / Cline (.roomodes / .clinerules), Windsurf (Cascade), Aider (test hook), OpenHands (Docker), Copilot VSCode Agent, Goose (.goosehints), Amazon Q Developer /dev, Devin (DEVIN.md, cloud sandbox), SWE-agent (Docker/ACI), GitLab Duo Workflow, Sourcegraph Cody, Augment Code, Tabnine Chat, Plandex, PearAI, AutoCodeRover. Each has a plausible hook point — a rules file, a hooks mechanism, a container boundary. Each hook point needs verification.

Tier 3 — Deferred halves + historical: Copilot CLI, Zed Inline, Amazon Q CLI, GitLab Duo Chat, Tabnine Inline — deferred halves of 5 candidates already counted in Tier 1/Tier 2 (Zed, Copilot, Amazon Q, GitLab Duo, Tabnine), not counted again. And two historical: Void (deprecated), Mentat (archived). The archived ones are in the survey anyway, because forgetting what died is how you repeat it.

Tiers describe integration friction, not quality. The tier just answers one question: what does it cost to make this harness honor a gate?

The one hole: exit codes

Here is the mechanism the survey proposes, and the hole it exposes. Real support means the host agent actually invokes the runner — bash skills/flow/runner/flow.sh <command> — parses the exit code, and halts when a gate fails (exit ≠ 0).

The illusion version is simpler and far more common: drop a prompt file that says "follow Flow" into the repo, and the agent nods along. The agent has no bash execution. Or it has bash, runs the gate, gets exit code 1, and hallucinates that the gates passed. The file exists. The enforcement does not.

Prompt file ≠ enforcement. That sentence is the entire article.

Take Devin, candidate 10. Devin's sandbox is isolated in the cloud. The global path ~/.claude/skills/flow does not exist inside it — hypothesized ENOENT. So the runner must be vendored in the repo at skills/flow/runner/flow.sh. Whether Devin honors exit codes and halts its autonomous loop on a gate failure is a hypothesis. The survey flags it "Live Host Trials Pending." Nobody has run it yet.

The hole is not a bug in any one harness. It is the gap between "I gave the agent the rules" and "the rules can stop the agent." One is a document. The other is a mechanism. Twenty-one harnesses, and the survey's honest read is that none of them ship verification as a first-class concept.

Support Thật vs Illusion

The survey's framing, restated:

	Thật (real support)	Illusion (marketing theater)
Invocation	Agent calls the runner directly	A prompt file sits in the repo
Exit code	Parsed; non-zero halts the loop	Ignored or never read
Gate failure	Work stops	Agent declares success anyway
Evidence	Receipts written to disk	Vibes

If your harness integration cannot produce row 1's behaviors, you do not have an integration. You have a README suggestion.

Try it yourself

The runner is one command, no setup:

npx @manhquy/flow-skill@latest

Source: github.com/manhquydev/flow-skill (MIT). A 75-second demo with English narration and subtitles in 5 languages is on flowskill.io.vn.

Honest limitations

Three things this article cannot claim:

This is desk research. Every verdict above comes from intake evaluations, not live trials. The survey repeats "Live Host Trials Pending," "hypothesized," and "unverified" throughout. I will not launder that into certainty.
No candidate is designated "Verified Supported." That designation requires passing the Four-Point Live Verification Protocol in the survey's section 1.3. None have been run yet.
FlowSkill is a discipline layer, not an agent runtime. Per ADR-0001 in the survey: "Flow owns the gates and the receipts, never the runtime." We do not replace your harness. We stand next to it with a kill switch and a paper trail.

Provisional verdicts are still useful — they tell you where to spend trial time first. Tier 1 first, Tier 2 with hypotheses, Tier 3 after something changes. But provisional is the honest word, and it stays until the trials run.

Why this matters now

Agents are getting better at producing code that looks finished. That is exactly why verification matters more, not less. The better the output looks, the easier it is to accept without checking. Every harness vendor is racing on generation. Almost nobody is racing on gates.

I write about this weekly in Proof over vibes, the FlowSkill newsletter — verification debt, gate design, and what the live trials find once they run. If "done" should mean something you can check: https://flowskillharnes.substack.com

Numbers in this article: 21 candidates: 3 Tier 1 + 16 Tier 2 + 2 historical; 5 Tier 3 entries are deferred halves of candidates already counted, from market-harness-survey.md (2026-10-14); 0.34.2 changelog entry (2026-10-15); tier criteria from docs/harness-qualification-process.md. Source repo: github.com/manhquydev/flow-skill.

I stopped trusting my AI coding agent's "done" — so I built gates

FlowSkill — Sat, 17 Oct 2026 16:36:28 +0000

My coding agent kept telling me "done." The build was broken. The tests it claimed to pass didn't exist. I started calling these hollow completes: the agent reports success, but nothing was actually verified.

The problem isn't the model. It's that "done" was never defined as something checkable. So I defined it.

What I built

FlowSkill is a small open-source harness that sits between your coding agent and the word "done." Two kinds of gates:

Mechanical gates (flow.sh) — does it build? Do the tests pass? Does the linter stay quiet? Things a script can check without judgment.
Semantic gates (SKILL.md) — does the change actually do what was asked? This is the harder one, and it's where most harnesses give up and let the agent grade its own homework.

The key rule: a kill at a gate is a valid outcome. If the work doesn't pass, it doesn't ship — no partial credit, no "mostly done."

Why existing tools didn't solve it

I looked at 21 agent harnesses. Every single one let the agent evaluate its own work. That's like letting students write their own report cards. The failure mode is structural, not a prompt engineering problem.

Benchmarks have the same disease from the other direction: agents score 90+ on examples they've memorized, then collapse to single digits on unseen tests. Memorized answers, not capability.

How it works in practice

npx @manhquy/flow-skill@latest

You describe the task. The agent works. Before anything is called "done," it runs /flow check: mechanical gates first (fast, deterministic), then semantic review against the task definition. If a gate fails, the attempt dies there and the failure gets logged to DEBT.md — a record of what didn't work, so you stop paying for the same dead ideas twice.

There's also /flow doctor (12 environment checks — the machine checks the machine before the model judges anything).

Honest limitations

The semantic gate is only as good as the task definition you write. Vague task in, vague verdict out.
It adds minutes to each run. If you're prototyping something throwaway, the gates are overhead you don't need.
9 stars on GitHub. This is early, and the edges are rough.

Why I'm writing this

Not to sell you a tool. To name the problem: every AI-written line is a loan against future debugging time. Someone — you, your teammate, future-you at 2 AM — pays it back with interest. Gates are just a way to pay some of it upfront, when it's cheap.

Repo: github.com/manhquydev/flow-skill · MIT licensed. If you've been burned by hollow completes, I'd like to hear how you verify your agents' work.

This is the first in a series on gated build harnesses. Next: "21 harnesses, one hole." For release notes and longer essays, subscribe to the newsletter (link in profile).