Specs in your language
The planner reads your product's information model first, so specs use the product's own terms. A spec holds requirements only: no tasks, file names or code.
For product owners
Get what you approved, and know it without asking.
AI agents build whatever the ticket text lets them. KiwiPow holds them to the spec you approved: every behaviour one sentence a single test can prove, built against the revision you signed, and handed back to you where the code forced a change.
Sound familiar?
- You write a story, the developer interprets it, the tester invents criteria for it, and nobody can say which version shipped.
- One spec runs from your ask to the tester's sign-off. Every behaviour keeps a stable id through every revision, so a proof and a verdict always point at the rule you approved.
- AI writes plausible stories from a ticket, and they read well and are quietly wrong.
- The planner writes from your own documents and cites the section each behaviour came from. Where the documents settle nothing, it asks you instead of inventing.
- The answer you gave last month is lost, and two features end up contradicting each other.
- What a planning conversation settles for the whole product is kept as a standing decision, and the planner plans by it on every feature after.
- Progress means a status meeting.
- A behaviour counts as built only when a named test proves it, and the board updates as the developer works.
Your part in the loop
You decide. Everyone else builds against your decision.
-
Ask in your own words
Write the feature as you would explain it. The planner first proposes what it is, what it is not and where it could go two ways.
-
Settle the questions
What only you can answer is asked during planning. An unanswered question is named, and a spec with an open question cannot be approved.
-
Approve a revision
Review in rounds, strike what should not be built, then approve. Approval fixes a numbered revision that claims, proofs and verdicts all name.
-
Rule on what the code teaches
Where the code disagrees with your spec, the developer's ruling reaches your feedback queue with proposals. Accept it, pick another, or send it back.
-
Accept, if you have no tester
Judge each behaviour against the tests that prove it. Accepted is final, and becomes the record of what the product does.
What you get
Struck stays struck
A behaviour you removed is never quietly reintroduced under another name. Every review comment is answered before approval.
Progress per behaviour
Not built, built, changed, reopened or accepted, worked out from the spec and the proofs every time it is read.
Nothing reaches the tester unanswered
A feature with a decision nobody has ruled on cannot be handed over for acceptance.
Ideas parked, not bolted on
Work a conversation turns up that is not this ask is recorded for later instead of widening the spec.
Withdrawn, not deleted
An ask that will not be built stays on record with its motivation, so the same idea is recognised next time.
See a feature go from ask to accepted
The demo product arrives with features already planned, built and accepted, and needs no model to explore.