Decompose an architecture/design document and its PRD into an iterative, shippable roadmap. Produces ROADMAP.md plus docs/iterations/NN-name/ plans with iteration overviews and nested vertical-slice feature specs. Use when the user has an architecture, design, or spec and wants buildable work: roadmap, iterations, feature breakdown, delivery plan, or team implementation plan. This is the third kmaz pipeline stage after PRD and architecture; its iteration output feeds kmaz-plan-iteration.
Audit the pedagogy of an educational product, course, lesson set, curriculum, or tutor against learning-science best practices, then propose and apply fixes. Reviews objectives, knowledge components, mastery thresholds, misconceptions, practice, assessments, sequencing, scaffolding, retrieval, spacing, interleaving, cognitive load, and tutor scripts. Use when the user asks to audit curriculum, lessons, pedagogy, instructional design, mastery thresholds, misconceptions, scaffolding, retention, or whether learners will actually learn. This is a learning-science lens, not a code-quality lens; if a pedagogy fix requires engine work, detect the stack and use the matching implementation agent.
Audit an existing frontend/UI for visual design, UX, design-system consistency, and accessibility, then fix the findings. Reviews hierarchy, layout, spacing, typography, color, depth, component consistency, interaction states, and WCAG issues; drives the running UI for evidence and validates with build/lint/a11y checks. Use when the user asks whether a UI looks good or usable, wants UI/UX polish, design-system cleanup, spacing/typography/color review, accessibility review, or a more professional interface. For designing a new UI from scratch, use frontend-design instead.
Audit infrastructure and platform concerns, then fix safe code/config findings. Covers IaC, containers, orchestration, CI/CD, secrets/config, observability, reliability, failure modes, and cloud security posture. Use when the user asks to audit Terraform, Dockerfiles, Kubernetes, CI, deployment pipelines, IAM/secrets, SLOs, health checks, graceful shutdown, production readiness, or platform operability. This is the platform/operations lens, distinct from application-code auditors. Never apply destructive infrastructure changes; keep those behind explicit human approval.
Audit an existing Go codebase for idiom, design, concurrency, error handling, package structure, API shape, tests, and correctness problems, then fix the findings. Use when the user asks to review, audit, clean up, or refactor Go; find non-idiomatic code; check interfaces, goroutines, errors, package names, cmd/main wiring, or code quality. Run build/vet/race/test validation after fixes. Not for greenfield product planning or adding a new feature.
Add one feature to an existing project end to end using a compressed kmaz pipeline: clarify scope, study the codebase, lock requirements and architecture decisions with one human gate, write a feature plan under docs/, implement autonomously, validate, and record assumptions, decisions, and blockers. Use when the user asks to add, build, or implement a feature, capability, endpoint, screen, or change in an existing codebase. Not for whole-product greenfield planning; use kmaz-prd, kmaz-prd-to-architecture, and kmaz-architecture-to-roadmap for that.
Turn a vague problem, idea, brief, RFP, take-home, or scattered thinking into an executable Product Requirements Document through a senior-PM-style interview. Produces docs/PRD.md: a numbered, technology-agnostic, behavior-focused spec a coding agent can execute. Use as the first kmaz pipeline stage when the user wants to figure out what to build, scope an idea, write a PRD, define requirements, or lock product intent and constraints. Hands off to kmaz-prd-to-architecture once the PRD is locked.
Turn a locked PRD into a defensible system architecture. Walk through technology and design tradeoffs, produce ADR-style ARCHITECTURE.md and docs/adrs/, and make every stack/system decision explicit. Use when the user has a PRD, brief, or spec and asks to design the system, choose the stack, decide architecture, or turn requirements into a technical design. Prefer kmaz-prd first when WHAT/WHY is not locked. Hands off to kmaz-architecture-to-roadmap after the design is locked.