Agents

kill9 has twenty agents. Each has a specialty, a set of tools, and a mode that determines how you interact with it. Understanding the modes matters — it changes how you use them.

Primary vs subagent

Agents come in two modes. This is about design intent, not a hard restriction — you can mention any agent in Work. The mode tells you what an agent is built for.

Primary agents are designed for coordination and broad context. They manage handoffs, track state, and delegate to specialists. k9, kdev, kpm, karch, klead, and khelp are primary.

Subagents are designed for focused, narrow tasks. They have deep expertise in one area and are most useful when you know exactly what you need. ktest, kreviewer, ksec, kui, kdoc, and kresearch are subagents.

You can talk to any of them directly:

Use ktest to add regression tests for the login bug.

Use kreviewer to review the auth changes.

The mode distinction matters for complex work. If you are implementing a feature that needs planning, coding, testing, and review, a primary agent like kdev or k9 coordinates the pipeline. If you just need tests written, talking to ktest directly is fine — and often faster.

The orchestrator: k9

k9 is the only agent whose entire purpose is delegation. It does not write code, design systems, or write tests. It reads the current state of your initiatives, decides what needs to happen next, and dispatches the right specialist.

Use k9 when work spans phases:

Use k9 to plan and implement a user settings page. Include tests and review.

k9 will:

1. Check the initiative state
2. Dispatch kpm for requirements if the PRD does not exist
3. Dispatch karch for architecture if the ADR does not exist
4. Dispatch klead for story breakdown
5. Dispatch kdev for implementation
6. Dispatch ktest for verification
7. Dispatch kreviewer for code review

You do not manage this handoff. k9 does. You get progress reports and answer questions when specialists need clarification.

k9 has access to workflow management tools that other agents do not. It can check entity status, validate state transitions, and query workflow queues. It is the only agent that can move initiatives between states.

The four primary agents you will use most

kdev — Developer

kdev implements code. It reads your codebase, understands existing patterns, and writes changes that fit. It also runs commands, writes tests, and verifies that things work.

kdev is a primary agent because implementation is where most user interaction happens. You review its changes, ask questions about its approach, and request revisions.

What kdev does:

• Reads files and directories to understand the codebase
• Edits and writes files
• Runs bash commands (tests, builds, linting)
• Uses LSP for navigation and analysis
• Verifies acceptance criteria with concrete proof

What kdev does not do:

• Write PRDs or define requirements (that is kpm)
• Make architectural decisions (that is karch)
• Break work into stories (that is klead)

Example prompts:

Use kdev to add email validation to the signup form in src/auth.tsx.

Use kdev to implement the password reset flow. The ADR is in Docs under FEAT-0012.

kpm — Product Manager

kpm defines what to build. It reads initiative descriptions, asks clarifying questions, and produces PRDs with acceptance criteria. It is the primary agent for the design phase of any feature.

kpm's defining trait is iteration. It does not produce a full PRD in one shot. It closes requirements one at a time — proposing, confirming, correcting — until each requirement is agreed upon. This prevents the common failure of building the wrong thing because requirements were misunderstood early.

What kpm does:

• Reads initiative descriptions and mirrors understanding back
• Asks structured questions via questionnaire
• Delegates to karch for feasibility, kui for UI implications, kresearch for external data
• Produces PRDs with measurable acceptance criteria
• Reviews and revises based on feedback

Example prompt:

Use kpm to define requirements for dark mode. Include system preference detection and persistence.

karch — Architect

karch makes technical decisions. It reads approved PRDs, evaluates approaches, and produces ADRs that developers can execute without re-deriving decisions.

karch's defining trait is depth. An ADR from karch includes component boundaries, data models, API shapes, and how the change fits existing patterns. It is not a high-level sketch. It is implementation-ready architecture.

What karch does:

• Reads approved PRDs before proposing any architecture
• Evaluates multiple approaches with trade-offs
• Produces ADRs with specific file references and patterns
• Maps each architecture decision to PRD requirement IDs

What karch does not do:

• Write code (delegates to kdev)
• Define product requirements (reads kpm's PRD)

Example prompt:

Use karch to write an ADR for switching from REST to GraphQL. The PRD is approved in FEAT-0023.

klead — Tech Lead

klead breaks approved designs into implementation-ready stories. It reads PRDs and ADRs, then produces a story tree with epics, stories, and acceptance criteria.

klead's defining trait is structure. A story from klead names specific files to touch, cites ADR sections, and lists what is in and out of scope. A developer should be able to read the story and the cited ADR section and have everything needed to implement.

What klead does:

• Reads PRDs and ADRs before creating stories
• Creates epics and stories as nested entities in one operation
• Ensures stories are vertical slices (independently demo-able)
• Writes measurable acceptance criteria

Example prompt:

Use klead to break FEAT-0023 into epics and stories. The PRD and ADR are both approved.

The subagents

These agents are designed for focused tasks. You can use them directly or let a primary agent bring them in as part of a workflow.

ktest — Tester

ktest verifies code. It reviews acceptance criteria for testability, writes tests, and runs them.

Use ktest directly when you need tests for something specific:

Use ktest to add regression tests for the login timeout bug.

Or let kdev or k9 bring ktest in automatically after implementation.

ktest mutates acceptance criteria directly. If an AC says "handles auth correctly," ktest rewrites it to "returns 401 on invalid token." This is not a suggestion — ktest updates the entity so the criterion is verifiable.

kreviewer — Code Reviewer

kreviewer finds problems in code changes. It reviews in the context of your full codebase, not just the diff.

Use kreviewer directly for a second opinion:

Use kreviewer to review the auth changes. Look for security issues and missed edge cases.

Or let k9 run kreviewer in parallel with ktest during the review phase.

ksec — Security

ksec reviews code for security issues. It checks for OWASP compliance, traces sensitive data flows, and audits dependencies.

Use ksec directly when you want a focused security review:

Use ksec to audit the new payment flow for PCI compliance.

k9 also auto-dispatches ksec when security-relevant paths are touched in a workflow.

kui — UI Designer

kui creates visual designs and mockups. It generates HTML mockups that render in the Mockups preview pane.

Use kui directly when you need a design:

Use kui to create two variants of a settings page.

Or let kpm bring kui in during the design phase of a feature.

kdoc — Documentation

kdoc writes technical documentation — READMEs, API docs, user guides.

Use kdoc directly when you need docs written:

Use kdoc to write API docs for the new authentication endpoints.

kresearch — Research

kresearch investigates external information. It searches the web, analyzes competitors, and fetches documentation.

Use kresearch directly when you need external data:

Use kresearch to find the best React table library. Compare features, bundle size, and maintenance status.

Specialist agents

The remaining agents cover specific domains. You use them directly when your work falls outside the core dev/test/review pipeline:

• kinfra — Infrastructure and DevOps. Deployment pipelines, scaling, cloud resources, monitoring.
• krm — Release management. Git workflow, branch management, merging strategies, changelogs.
• kml — Machine learning. Model development, training pipelines, evaluation.
• kmobile — Mobile development. iOS, Android, React Native, mobile architecture.
• kanalytics — Data analysis. Metrics, dashboards, reporting, business intelligence.
• kcompliance — Compliance and governance. GDPR, SOC2, HIPAA, regulatory auditing.
• kceo — Business strategy. Market analysis, ROI assessment, competitive positioning.
• kdevex — Developer experience. Tooling, workflows, CI/CD improvements, onboarding.
• khelp — Product support. Answers questions about how kill9 works.

How to use an agent

In Work (Mod+2), mention the agent by name:

Use kdev to implement the password reset flow.

Or let k9 coordinate:

Use k9 to handle this feature from planning through review.

Browse and customize agents

Press Cmd/Ctrl+Shift+A to open the Agents browser. You can see all agents, read their descriptions, and customize their colors or default models. You can also create custom agents with specific tool access and behavioral rules.

Related pages

• Plan a feature — how k9 and specialists work together
• Fix a bug — kdev and ktest in action
• Review changes — using kreviewer