dotmaz

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.

Audit an existing Python codebase for idiom, design, typing, public APIs, structure/imports, error handling, resource handling, tests, and correctness problems, then fix the findings. Use when the user asks to review, audit, clean up, or refactor Python; find non-Pythonic code; improve type hints; check stdlib usage, mutable defaults, bare excepts, modules, or code quality. Run format/lint/type/test validation after fixes. Not for greenfield product planning or adding a new feature.

Audit an existing Rails app for convention, SOLID, best-practice, layer, and correctness problems, then fix the findings. Reviews models, controllers/routes, service objects, jobs, views/helpers, config, scopes, tests, and Rails idiom. Use when the user asks to review, audit, clean up, or refactor Rails; find convention violations; thin controllers; improve code quality; or check over-mocked tests. Run test/lint/security validation after fixes. Not for greenfield product planning or adding a feature.

Audit an existing Rust codebase for ownership, safety, idiom, API design, allocation, lifetimes, traits, concurrency/async, error handling, unsafe soundness, panics, and correctness problems, then fix the findings. Use when the user asks to review, audit, clean up, or refactor Rust; remove unwraps or unnecessary clones; check unsafe, Send/Sync, async, or illegal states; or improve code quality. Run build/clippy/test validation after fixes. Not for greenfield planning or adding a feature.

Audit a codebase in any language for defensive security vulnerabilities, then fix confirmed findings. Traces untrusted input from source to sink and reviews injection, access control, auth/sessions, secrets/crypto, XSS, CSRF, SSRF, deserialization, data handling, dependencies, and config. Use when the user asks for a security review, vulnerability audit, OWASP-style pass, authz check, secret scan, hardening before launch, or similar authorized review of their own code. Not for producing exploits against systems the user does not own.

Audit an existing Swift, iOS, macOS, watchOS, or visionOS codebase for idiom, safety, concurrency, design, SwiftUI/UIKit correctness, and code-quality problems, then fix the findings. Use when the user asks to review, audit, clean up, or refactor Swift; remove force unwraps or retain cycles; fix data races; modernize to async/await and actors; improve SwiftUI state/view identity or UIKit controller memory; or make illegal states unrepresentable. Run build/test validation after fixes. Not for greenfield planning or adding a feature.

Audit an existing TypeScript codebase for type safety, idiom, design, framework correctness, and code quality, then fix the findings. Detects pure TS, React, and Node concerns; reviews `any`, type models, illegal states, hooks/effects/re-renders, async/error handling, streams, tests, and build health. Use when the user asks to review, audit, clean up, or refactor TypeScript or improve TS/React/Node code quality without adding a feature. Run typecheck/lint/test/build validation after fixes. Not for greenfield planning or adding a feature.

Safely land a completed feature branch into main with linear history, then clean up: rebase the branch onto local main, resolve only trivial conflicts (escalate real ones), protect any unrelated dirty state on main, fast-forward merge to keep history linear, then delete the branch and its git worktree. Use this skill whenever the user wants to merge/land/integrate a finished branch, "merge this into main", "land the feature", "ff-merge and clean up", "rebase and merge then delete the worktree", or otherwise finish and tidy up a development branch after the work and review are done. It is the natural follow-on to kmaz-feature (which can end at an open, rebased PR). Trigger even if the user doesn't name this skill, as long as they're asking to merge a branch into main and tidy up afterward.

Address the comments, questions, or feedback on the open Pull Request or Merge Request, then propagate any durable lessons back into the project's architecture, ADRs, roadmap, or build conventions so the next feature inherits them. Use when there is an open PR/MR with review feedback to work through.

Create a visual representation of a software architecture