You've seen the symptoms

Work starts and then stalls while somebody chases down what it actually means. The demo turns into an argument about what was asked for. A tester reads the story and can't tell what passing looks like. The same requirement gets built twice — once wrong, once right.

None of that is a talent problem. Your team isn't bad at requirements. Your requirements never had anywhere to get good. And nobody knew when a requirement was actually ready.

The structural cause

A GitHub Project starts at Todo. An idea shows up, lands in Todo, and Todo means "somebody could start this" — whether or not anybody understands it yet. There is no stage between "someone had a thought" and "the team is on the hook for it."

So "ready" is a vibe. Every team member carries their own private definition of it, and you discover the differences at the worst possible time: after the work started.

What Honest Cheetah installs — if you want it to

A refinement flow — Proposed → Not Ready → Ready — installed in front of Todo. One click, on a brand-new project or the board you already have. These are real status values on your real GitHub Project, so they're visible in GitHub too, not just in HC.

Now an idea has a path. Proposed means "somebody thought of it." Not Ready means "we looked, and it needs work — and we can say why." Ready means it cleared your bar. Intake becomes something you can see and count, instead of a pile of Todo items of wildly different quality.

Wait — do our requirements suck?

Depends who you ask. As a developer, requirements suck when there isn't enough detail to build from. As a tester, requirements suck when you can't tell what to verify. As a leader, requirements — maybe your whole backlog — suck when the titles read like tech jargon instead of a story about business value.

The first two complaints have a shared name: acceptance criteria. When a story says what "done" looks like in checkable terms, the developer knows what to build and the tester knows what passing means. When it doesn't, everyone improvises — separately, and at the same time.

So: click a button and find out. HC's AI reviews a story for verifiability — does it have acceptance criteria a tester could actually check? — and states its findings consequence-first: what's missing, and what it'll cost you if it stays missing. There's a scores view across the whole backlog, so "how bad is it?" gets an actual answer instead of a feeling.

And let's say you, uh, find out they're not all that great. Three buttons: This feels too big, This needs acceptance criteria, This reads like a task, not a story. Each one gets you a draft — a split, a rewrite, a reframe — in an editor, for you to confirm or close. The review names the problem. The fix is optional. You're still the author. The review and the buttons, in detail →

Or skip the blank page entirely

Have an idea for a requirement but you don't know how to write it — or even what to call it? Type a couple of paragraphs into HC, click a button, and you get a structured requirement back. Tweak it. Or don't. Click save and it's stored in GitHub.

Want a second opinion about what you should even consider next? Click a button and HC reads your project's description and README and suggests candidate backlog items. Select the ones you like. Click save. Done.

The honest part

This doesn't replace talking to your customers, your stakeholders, and your team. Nothing does. Requirements get better in conversations.

What the refinement flow does is give those conversations a place to happen and a visible outcome — so "we should refine our backlog" stops being a wish and starts being a status change somebody made on purpose. If you choose to add it, the dreaded "requirements problems" stop being a mystery and start being a queue you can see.

Sign in with GitHub