メニュー
Create a visual representation of a software architecture
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | kmaz-create-diagram |
| description | Create a visual representation of a software architecture |
Create a highly visual HTML visualizer to explain my architecture. create a separate one for module, data flows and calls. Include a hover over and click interactions to explain more detail. The initial presentation should be high level with details in the interactions. Explain in high clarity, and high visual clarity. Do it in the style of a mckinsey consultant. Spawn 5 subagents to do various versions of it
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.
