pma-d2
D2 Diagram Author
Generate idiomatic .d2 source files — diagrams encoded as declarative text, rendered by the official d2 CLI to SVG / PNG / PDF / GIF. The output is human-readable, diffable, and embeds anywhere D2 embeds (GitHub, Notion, VS Code, docs sites, Oxide's play.d2lang.com).
Keep this entry file small. Load only the reference packs that match the current diagram.
Always-On Rules
- Output is
.d2text, nothing else. The skill never invokes a renderer; the user runsd2 input.d2 out.svgor opens play.d2lang.com. Quality must be enforceable by reading the source. - Idiomatic D2 over clever D2. Prefer declarative node names (
api -> db) over IDs + labels when the name reads naturally. Reach forlabel:only when the natural name would be awkward or duplicated. - Shape type matches concept. A database is
shape: cylinder, a queue isshape: queue, an actor isshape: person. Never default everything torectangle. Full catalog inreferences/shapes.md. - Direction declared up front. Set
direction: down | right | up | lefton the root (and per container if needed). Layout direction is a communication choice, not an incidental default. - Semantic edge style, not ornamental.
stroke-dashfor async / weak dependency;animated: truefor streams;strokecolor to encode criticality / failure paths. Catalog inreferences/connections.md. - Group by container, not by proximity. If nodes belong to one domain (a subsystem, a cloud, a bounded context), nest them in a container map. Containers are D2's native grouping — use them instead of manual placement.
- One concept per diagram. If a diagram answers two questions, split into two
layers:or two files. Don't compress. - Classes for repetition. ≥ 2 nodes share styling → define a class in
classes: {}and apply with.class: nameor a glob. - No invented shapes. All
shape:values must come fromreferences/shapes.md. D2 silently falls back to rectangle on typos, which is the worst failure mode: it looks right but isn't. - Commit-ready source. File ends with a newline, uses 2-space indentation, no trailing whitespace, comments explain intent not mechanics. D2 is git-friendly — keep it that way.
More from zzci/skills
pma
Project development lifecycle management with a strict three-phase workflow (investigate, proposal, implement), file-based plan tracking in docs/plan/, task tracking in docs/task/, and claim-before-work multi-agent coordination. Use when handling feature development, bug fixes, refactors, planning, progress tracking, or multi-agent execution in an existing codebase. English-first for repository docs and remote-visible metadata; use Chinese docs only when the user explicitly requests a specific document in Chinese.
136pma-web
Frontend implementation guide for PMA-managed React 19 + TypeScript + Vite 8 SPA projects. Defaults to a single-app layout (the right choice for a Rust/Go service that ships a UI); promotes to a Bun monorepo only when multiple apps or shared packages exist. UI is hard-locked to shadcn/ui (base-nova) + `@base-ui/react` — Radix and other UI ecosystems (MUI / Mantine / Chakra / Ant Design / Headless UI / Ariakit / NextUI / …) are forbidden. Covers required quality gates, file-based type-safe routing with TanStack Router, state conventions (TanStack Query + Zustand), Tailwind CSS v4 patterns, Vitest 4 testing, dual-channel theming, i18n, nsl-based dev integration with backend services, and delivery rules for frontend applications.
128pma-rust
Production-grade Rust acceptance baseline for PMA-managed Rust services and CLIs. Use with /pma when creating, reviewing, or upgrading Rust workspaces, Axum/Tokio services, CLI binaries, CI pipelines, release packaging, lint policy, dependency choices, testing, observability, security, or supply-chain controls. Defines hard locks for pure-Rust dependencies, rustls TLS, forbid unsafe code, edition 2024, workspace lint inheritance, MSRV, nextest, cargo-deny, cargo-shear, typos, and portable release builds.
115bkd
Operate a BKD kanban board over its REST API. Use when the user wants to manage BKD projects, issue execution workflows, cron jobs, or execution capacity through a reachable BKD server.
113pma-cr
Stack-aware review for local diffs, pull requests, and repository-wide audits. Routes review across shared policy plus language packs for TypeScript frontend, TypeScript backend/Bun, Go, Rust, and Python. Use after implementation, before merge, or when auditing an existing codebase.
112pma-bun
Bun implementation guide for PMA-managed backend services. Defaults to a single-API-project layout; promotes to a Bun monorepo only when multiple deployable apps or shared packages exist. Covers API modules under `src/modules`, strict linting with ESLint + @antfu/eslint-config, Drizzle over SQLite-first storage, OpenAPIHono on top of `Bun.serve()`, validated env config, nsl-based dev URL routing (paired with `pma-web`), standalone binary compilation with embedded assets and migrations, and CI quality gates.
110