You have an idea for a new feature. Here's how to turn it into tracked, reviewable work using kill9's workflow.
Step 1: Create the initiative
Press Mod+3 to open Plan. Click the create button and choose Feature. Give it a title and description. Be specific — "Add dark mode" is better than "Improve UI."
The initiative starts in the backlog state.
Step 2: Move to design
Click the initiative to open its detail view. You'll see the workflow states at the top: backlog, design, planning, ready, in_progress, review, done. Click design to move the initiative into the design phase.
This is where the product and architecture are defined. kpm (the product manager agent) will lead product discovery, closing requirements with you one at a time.
In Work (Mod+2), you'll see a chat session with kpm. kpm reads your initiative description and mirrors its understanding back to you:
Here's what I understood: You want a dark mode toggle that respects system preferences and persists across sessions. Confirm or correct me, then tell me the most important thing I'm missing.This mirroring is deliberate. kpm does not assume it understands your goal. It proposes, you confirm or correct, and only then does it move forward. This prevents the common failure where an agent builds the wrong thing because it misunderstood early.
Step 3: Close requirements
kpm closes requirements one at a time. For each one, it proposes a specific question:
Based on the initiative description, I think the toggle should be in the Settings page. Confirm?You reply yes, no, or with a correction. kpm iterates until the requirement is closed. Then it moves to the next one.
This is slow by design. Rushing through requirements produces PRDs that don't match what you actually want.
Step 4: Draft the PRD
Once all requirements are closed, kpm drafts a PRD in Docs (Mod+4). The PRD contains only decisions you confirmed. No open questions, no "options to consider," no TBDs.
Open Docs, find the PRD, and review it. If something is wrong, tell kpm. It will revise and resubmit.
Step 5: Draft the ADR
After the PRD is approved, karch (the architect agent) reads it and drafts an ADR. The ADR describes the technical approach: component boundaries, data model, API shapes, and how it fits existing code patterns.
The ADR is implementation-ready. A developer should be able to read it and build the feature without re-deriving decisions.
Review the ADR in Docs. Approve it or request changes.
Step 6: Break into stories
With PRD and ADR approved, the design gate is satisfied. The initiative can move to planning.
klead (the tech lead agent) breaks the initiative into epics and stories. Each epic covers a major component. Each story is a vertical slice — independently demo-able end-to-end.
Every story names the specific files to touch, cites the relevant ADR section, and lists measurable acceptance criteria. "Returns 401 on invalid token" not "handles auth correctly."
ktest reviews each acceptance criterion for testability. If an AC is vague, ktest rewrites it.
Step 7: Implementation
With at least one epic and one story with acceptance criteria, the planning gates are satisfied. Move the initiative to in_progress.
kdev implements the stories. For each one, it reads the story description, the cited ADR section, and the named files. It implements the change and verifies each acceptance criterion with concrete proof.
You can watch progress in Plan (Mod+3) or chat with kdev in Work (Mod+2) if you have questions.
Step 8: Review
When all epics are complete, the review gate is satisfied. The initiative moves to review.
kreviewer and ktest run in parallel. kreviewer checks the code against the PRD and ADR. ktest runs the full test suite and linter.
If issues are found, the agents iterate until resolved. You confirm before marking done.
Next step
Open Plan (Mod+3) and create your first feature initiative. Or read Fix a bug to see the bug fix flow.